JavaScript variable evasion when quote is escaped, but not newline

Question

I'm searching a way to properly evade from a JavaScript variable to perform XSS. A normal user input will give var a='<b>user input</b>'.

a isn't eval anywhere and is not usable. Howewer, I've find something interesting. An input like %0a%0dalert(1);// will render as:

var a='<b>
alert(1);//</b>'

My browser is warning me about an illegal token error. This is normal, and due to var a not being closed.

Is there a way to get this to work? Executing the alert function ignoring the previous error. ' is escaped as \' and \ as \\. Others basics HTML characters are also encoded in a normal manner (" < > &)

Answer 1

To cause injection in this context you need to either:

Close the script tag:

e.g.

</script><script>alert('xss');

OR close the single quote string context:

e.g.

'; alert('xss');

However, as the first option would result in <, etc, and the second option would result in \' characters being output (and not possible to escape \ either because of \\), I would say XSS isn't possible in this case.

The only hope is that if the charset is UTF-7 or could be changed to such for UTF-7 XSS.

The only security flaw here otherwise is that an attacker could maybe cause a Denial of Service by preventing other JavaScript code running and preventing the application from functioning as intended.

Answer 2

I'm going to have to concur with SilverlightFox's assessment that successful exploitation of this "possible" attack vector will be severely hindered (as is the intent of encoding in the first place).

There doesn't appear to be any way to "consume" (i.e. overwrite) characters under UTF-8, and the characters you need to break out of are already being escaped. Your question essentially parallels what has already been asked here: How can sanitation that escapes single quotes be defeated by SQL injection in SQL Server?

The short answer is "There are a few (emphasis) cases where the escape function will fail:"

• Context does not employ surrounding single quotes (which yours is, so this doesn't apply)
• If a substring is filtered; this one is fairly nasty in that the attacker attempts to use your encoding/filtering routines against your application. If, for example, your filtering rules makes a single pass, removing all occurrences of "onclick" in user input, but then your attacker passes "ononclickclick," your filtering results in "onclick" being written to the page. This of course requires you to manaully fuzz your filters to ensure it's not leaving behind characters that might escape your encoding routine.
• Unicode attacks where supported (i.e. database accepts GBK, etc)

Source: https://stackoverflow.com/a/15596300/901156