5

I'm learning DOM XSS and I have this code :

<html>
 <body>
     Select your language:
     <select>
        <script>
        document.write("<OPTION value=1>"+document.location.href.substring(document.location.href.indexOf("default=")+8)+"</OPTION>");
        document.write("<OPTION value=2>English</OPTION>");
         </script>
     </select>
 </body>
</html> 

but I don't understand why this payload doesn't trigger any XSS :

t.html?default=test</option><img src=x onerror=alert(1)/>

It looks like the symbols are encoded and I don't understand why...

I took the script from https://www.owasp.org/index.php/DOM_Based_XSS so I guess it's vulnerable but I don't know how to exploit it...

1 Answer 1

13

It doesn't work because the payload is URL-encoded.

If you navigate to

https://example.com/?foo=<>"

you will see the literal characters <>" in your URL bar, but the browser has actually requested

https://example.com/?foo=%3C%3E%22

. That is, your browser always URL-encodes some characters in the query string, including quotes and angle brackets.

So, if you access location.href via JS, the payload in your example will be returned as

test%3C/option%3E%3Cimg%20src=x%20onerror=alert(1)/%3E

. This does not produce any HTML tags unless you URL-decode it first.

Note: As far as I know, all modern browsers now behave that way, but historically, some implementations have implicitly URL-decoded values for the location interface. In these browsers, your attack would have worked.

2
  • Oh I see... Ok ! Thank you so much ! So this webpage is not vulnerable anymore ?
    – Neolex
    Commented Mar 25, 2019 at 5:53
  • 2
    There may still be browsers that let you sneak literal quotes and angle brackets somewhere in the URL where they don't get URL-encoded. But I believe your example isn't vulnerable in modern Chrome and Firefox.
    – Arminius
    Commented Mar 25, 2019 at 5:58

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .