2

I've just learned the theory behind XSS attacks and now I would like to test my knowledge in a legal way.

I wanted to "hack" OWASP Juice shop by following steps from this book section "Perform a reflected XSS attack". When I use iframe src="javascript:alert(1)"> as a XSS payload it works as expected (I get alert 1). But when I change it to <script>alert(1)</script> nothing happens, no alert is displayed.

enter image description here

I checked using Chrome Developer tools that payload was injected to the DOM but for some reason script was not executed. Do you have any idea why? Any idea how can I inject more sophisticated payload to OWASP Juice shop?

guntbert
  • 1,825
  • 2
  • 18
  • 21
Paweł Adamski
  • 123
  • 1
  • 5

3 Answers3

8

I went ahead and tried to determine what endpoint in the OWASP Juice Shop application you are injecting your payload into. Please correct me if I am wrong, but it appears that the payload is injected via the search field.

This appears to be DOM-based XSS and not reflected XSS. This is important to note since the payload is passed on to the innerHTML method:

<div *ngIf="searchValue"><span>{{"TITLE_SEARCH_RESULTS" | translate}} - 
</span> <span [innerHTML]="searchValue"></span></div>

<script>alert(1)</script> does not execute when injected via innerHTML as stated here:

script elements inserted using innerHTML do not execute when they are inserted.

Instead, I would recommend using payloads such as <iframe src=javascript:alert(1)> and <img src=x onerror=alert(1)>.

EdOverflow
  • 1,246
  • 8
  • 21
0

It sounds like the browser’s XSS filter is catching the script. This is a common defense mechanism, but there are still ways around it (like loading a script from an iframe!).

I’d recommend you do some research on XSS filters and evading them in order to understand what’s going on here a bit better. OWASP’s XSS filter evasion cheat sheet is a really good place to start.

securityOrange
  • 913
  • 4
  • 12
  • The screenshot provided in the question indicates that Paweł Adamski is using Google Chrome. Chrome's auditor highlights payloads that it detects, so in this case it is not the auditor preventing the payload from firing. On top of that, this is DOM-based XSS and not reflected XSS, which "bypasses" the auditor by design. – EdOverflow Dec 16 '18 at 12:52
  • I agree with you, I think my answer is wrong. Editing to correct. Thanks Ed! – securityOrange Dec 16 '18 at 15:49
0

Hymmm, I don't know how you exactly want to perform this attack but I think that you can try to inject this script in different manner. Instead of putting raw js script you can use jsfuck.com which will translate your java script into the same code but using only certain charterers like [, etc... It might help because it would not be treated by browser as js code because it will look like garbage in input but it actually will execute. I hope it will help you.

Pankejk
  • 1