A Close Call

Happy New Year

It is not about sugar all the time ... salt is also there. In this blog post, I will discuss a unsuccessful case of XSSing but in the process, I hope some of you may learn something. At the same time, may be some of you're already successful in that particular case and have found that type of XSS earlier in the wild. For me, it is still in the TO DO list ... at least I haven't found it myself in the wild (may be I should browse more sites). In my case, all the time, it was a close call. In short, this is the case where reflection is in script block in general and back-slash (\) is not escaped. The \ is often not escaped in script block and we will see how we can leverage it for our benefit somehow. Further you will see that in live example cases given below " are properly escaped or filtered while < is encoded or filtered. If in script context " or ' or < are not controlled then game is over for the site.

Please open the following URL (the two GET parameters i.e., q & mediatype hold our harmless probe string "xxxxxxxx'yyyyy</img): 

    

foxsports.ramp.com/search?q="xxxxxxxx%27yyyyy</img&mediatype="xxxxxxxx%27yyyyy</img 

The screen-shot given below shows the reflection of our interest i.e., inside script block. Please note that it is not common to control two GET parameters while at the same time getting reflection back in both cases. The screen-shot also shows " and < from the probe string were filtered so we can not use options like "; confirm(1); ", "-confirm(1)-" and </script><script>confirm(1)</script> respectively. 

As I said earlier, in this case, we can control two GET parameters and by keeping this thing in mind lets inject \ in the 1st GET parameter and 2nd GET parameter will have the value ; confirm`1`;//. I explain the injected values later. The screen shot shows injection and has a label of 1 and 2 for 1st and 2nd GET parameters respectively.

The URL looks like: http://foxsports.ramp.com/search?q=\&mediatype=;%20confirm`1`;// and the following screen-shot shows "Uncaught Syntax Error" you will get when you will open the URL. Why Uncaught Syntax Error? I think because of  \, the closing " in the variable declaration becomes special character (or asks for special treatment because it is now an escaped double quotes) and then browser tries to find the matching " which is not their or missing. It results in an Uncaught Syntax Error and for the browsers it becomes unparseable script. Please keep in mind we need " in pair for JavaScript string variable declaration,

This was a close call because we're unable to XSS it BUT what if in the JavaScript source code snippet as shown in the above screen shot, the "mediatype" variable declaration was in the same line (no line break) as "searchedTerm"? I mean something like ...

<script type="text/javascript">

/* other code goes here*/

 var searchedTerm = "reflection-here";   var mediaType = "reflection-here";

</script>

In that case our attack payload as can be seen in the URL http://foxsports.ramp.com/search?q=\&mediatype=;%20confirm`1`;// will work and the culprit will be \ (given " and < are either filtered or encoded as was the case here). Some of you might be thinking how and why? I try to explain it. In the source code, the attack payload looks like ...

<script type="text/javascript">

/* other code goes here*/

 var searchedTerm = "\";   var mediaType = "; confirm`1`;//";

</script>

Why the above JavaScript code works (some of you already have an idea) and why this time there is no Uncaught Syntax Error given everything was same except mediaType variable declaration was not in a new line?  The answer can be seen in the following screen-shot. 1) By injecting \ as a part of variable searchedTerm, we force browser to consider " as a special character or escape character because developers're using " for JavaScript string variable declaration in this case. The browser will digest this " because of  \ and will continue digesting stuff (it also includes ; which is a statement terminator) until it finds the closing ".  The browser will find the plain " after = symbol of variable mediaType. At the end of day, the value of searchedTerm variable will be "; var mediaType =. The next thing is ; which is a statement terminator because this ; is after the matching " and this will close the statement. The ; earlier as a part of variable searchedTerm was not treated as statement terminator because in reality it was enclosed in a pair of double quotes. 2) The next thing is a simple proof of concept JavaScript execution via confirm`1`;. 3) Finally we have single line comments (//) and their job in the attack payload is to neutralizes the effect of " at the end. The explanation above shows all stars have been aligned properly and that's why no Uncaught Syntax Error.

The \ is often not escaped or encoded in script context and even Google guys missed it on Google Developers site. The following URL results in an Uncaught Syntax Error: https://developers.google.com/s/results/?q=%5C. In this case, again it was a close call because as an attacker, we can not control the second parameter. When you're testing the web application, the other potential venue where you may leverage \ for XSS would be JSON. My quest for finding this particular XSS in the wild will continue ...

Acknowledgement: I would like to thank Joel Weinberger for some discussion on that.