Its been a while since my last post so I decided to make it worthwhile :). I was recently checking a friend’s site for the classic Web application vulnerabilities, when I found a reflected XSS attack. While I was investigating the bug, I noticed that while the bug worked on Mozilla’s Firefox, it didn’t work on Google’s Chrome. As it turns out, Chrome uses an Anti-XSS filter, based on static analysis, which attempts to detect XSS. If it detects such an attempt, it filters out the injected code, and effectively stops the on-going attack.
In order to demonstrate this, I made a vulnerable page at http://securitee.tk/files/chrome_xss.php. This page simply reads two GET parameters, namely a and b, which it then prints out in the resulting page.
To show that injection is possible, I start by injecting some HTML which is indeed rendered as part of the HTML page.
And indeed, it worked!!! The multi-line comments mean nothing to the HTML but mean the world when they are placed in a script environment In summary, all you need to bypass the XSS filter is to have at least two variables under your control, and break up your injected script, with the help of multi-line comments, to use both.
Till next time
P.S. I have already told the Chrome folks about this, but their answer was that their filter is not meant to protect against this attack… I don’t know why… you can ask them
Update – January 19th 2012
Recently I noticed that the attack explained above stopped working. The developers of Chrome still say that if you control two variables you can bypass the Anti-XSS but at the same time they agree that the bypass that I had originally demonstrated is no longer working. So here is a bypass, for their filtering of my original bypass (tested in Linux Chrome 17.0.963.38 beta)
Now if you look at what’s happening here, all I am doing is adding a double-slash comment right at the end of the first controlled variable. This shouldn’t make any difference since we are already in comment-mode but apparently it does. If I would have to guess, I’d say that they have really hard-coded the multiline comment rule in their filters and any small deviation will still do the trick.
Update – October 25th 2012
Today one of the Master students who I supervise here at KU Leuven told me that my attack no longer works. After verifying that he was right, I tried out a modified bypass that I had discovered some months ago but “failed” to disclose. Works like a charm
(tested in Linux Chrome 23.0.1271.40 beta)