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>

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;)

  • What does happen with a? Does it get set somewhere in the DOM with innerHTML or something? If so, it's vulnerable to <img src="http://..." onload="EVIL">. Commented May 27, 2016 at 21:07
  • As I said, a isn't eval anywhere and is not usable.
    – Xavier59
    Commented May 27, 2016 at 21:10
  • Well in that case, if HTML is also encoded, a variation of the old multi-byte trick for SQL injection might be possible? Commented May 27, 2016 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
    Commented May 27, 2016 at 21:39
  • Should I move this question to stack overflow ?
    – Xavier59
    Commented Jun 4, 2016 at 10:25

2 Answers 2


To cause injection in this context you need to either:

Close the script tag:



OR close the single quote string context:


'; 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.

  • This is correct. If you cause a syntax error, then the whole <script>...</script> will not run. In that case you need a new script (ability to insert </script without any encoding), or to break out of the string cleanly. (being able to insert \ or ' without them being converted to \\ or \' respectively) Commented Jul 12, 2016 at 19:17

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

You must log in to answer this question.

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