Demonstrating reflected XSS with GET Parameter and URL encoding

Question

A client is developing a website which is vulnerable to reflected XSS through a GET parameter:

https://example.com/vulnerable-url?")||true)alert("XSS");</script>

I would like to demonstrate this vulnerability by providing a link like the above but the text contains characters (such as the ") which are URL encoded by a browser, resulting in an invalid, unexecuted script.
I've also found that using a form within HTML to perform a GET request also results in URL encoding of the payload string.

I can however use the BurpSuite proxy to make the request without URL encoding, resulting in the script execution.

I would like to demonstrate script using only a browser available in the client environment. Any ideas on how this could be achieved?

Answer 1

A few possibilities:

• Internet Explorer doesn't automatically hex-encode characters in the query string. Up to your client whether that browser still has enough market share to matter to them.
• Apostrophes (single quotes) don't get encoded in Edge, and maybe some other browsers. If there's a string you can inject into delimited by those, there you go.
• Backslashes don't get encoded in any common browser. If you have two injection points and the first one is immediately followed by a string-terminating character, you can escape that character and may be able to get everything up until the second injection point was due to start treated as text, in which case the second injection point will be treated as code.
• <> are encoded in all major browsers other than IE, but if you can inject them, you don't need any special dancing about with quotation marks; just terminate the script block (even in the middle of a string!) and inject your own HTML.
• Make sure you can't restructure the request as a POST, and insert your payload in the body. No auto-escaping there!
• Check if the payload can be put in a parameter body, rather than its name; some browsers might do less escaping there.
• Check if there's anywhere in the site that reflects input unsafely after decoding it in some way (URL, HTML, JS literal, etc.). It's actually pretty weird for a web app to reflect parameters without decoding them first.