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):
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.
/* other code goes here*/
var searchedTerm = "reflection-here"; var mediaType = "reflection-here";
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 ...
/* other code goes here*/
var searchedTerm = "\"; var mediaType = "; confirm`1`;//";
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.