Information Security Stack Exchange is a question and answer site for information security professionals. It only takes a minute to sign up.
Sign up to join this community
So I am testing an application and I almost got an XSS vulnerability but only if I can comment on the rest of the code. e.g. Originally this is how the target returns the user-entered input:
I've been able to get this to this far:
Request
Response
Now when I try to comment on the "});", the comments are escaped as follows:
So is there any way I can bypass this?
If the server is "correctly" escaping forward slashes, then no, there's no way to specifically bypass that to insert a single-line comment in JS.
You could try using escaped characters, to see if the backslash-escaping happens before or after URL-decoding. If it happens before URL decoding, use %2f in the URL to get a slash. Of course, if that works, you can probably just use %22 to get a quotation mark, and forget about slashes / comments entirely.
In general, you have no specific need for a comment there. Instead of focusing on "how can I get a comment?", focus on "how can I make the remaining text not cause a syntax error?". However, most of the options you would normally have are stymied by the escaping of slashes.
A good option would normally be to close the script block early. If you can inject a simple </script> into your JS, this will cause everything after it to be interpreted as HTML, not as JS. You could even then start a new script tag if you want. Unfortunately, </script> contains a /, and <\/script> doesn't do the desired thing. Alternatively, if you can start a new string, or whole new block, without causing a syntax error, that works too... but then you have a loose \ or two in your non-string code, and that will also cause an error.
You could also see if there's another injection point further down the page. If you end your injection at the top with ` (a backtick), that starts a multi-line string template until the next backtick is found. If you can inject a second backtick further down the same script block, congratulations, you have converted the entire unwanted remaining characters into a giant string.
Mind you, there is still a vulnerability here worth reporting. Even if the current behavior of browsers regarding what is and isn't a syntax error, and how to handle them, prevents actual execution of an XSS payload today... That's luck, and a dependency on factors outside their control. Essentially, they are depending on undefined behaviors to keep them safe. Any browser that handles such errors slightly differently, or any change to the JS spec that introduces another way to terminate processing of a line, and they're completely vulnerable. At a minimum, they need to correctly escape all JS metacharacters, not just " and / (weird ones to pick, honestly; the latter has no meaning inside of a string), so that you can't break out of the string. Ideally, they shouldn't be reflecting user-supplied input into the DOM at all, certainly not into a script block.
