2

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 (&quot; &lt; &gt; &amp;)

Xavier59
  • 2,874
  • 3
  • 17
  • 34
  • What does happen with `a`? Does it get set somewhere in the DOM with `innerHTML` or something? If so, it's vulnerable to ``. – Alexander O'Mara May 27 '16 at 21:07
  • As I said, `a` isn't eval anywhere and is not usable. – Xavier59 May 27 '16 at 21:10
  • Well in that case, if HTML is also encoded, a variation of the old [multi-byte trick for SQL injection](http://security.stackexchange.com/questions/9908/multibyte-character-exploits-php-mysql) might be possible? – Alexander O'Mara May 27 '16 at 21:30
  • I'm not sure to understand, but **0xE0** seems to consume characters after this one. The problem remain, `a` isn't closed at any time. – Xavier59 May 27 '16 at 21:39
  • Should I move this question to stack overflow ? – Xavier59 Jun 04 '16 at 10:25

2 Answers2

4

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 &lt;, 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.

Community
  • 1
SilverlightFox
  • 33,408
  • 6
  • 67
  • 178
  • This is correct. If you cause a syntax error, then the whole `` will not run. In that case you need a new script (ability to insert ` – 700 Software Jul 12 '16 at 19:17
0

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

Community
  • 1
Matt Borja
  • 267
  • 1
  • 10