And an HTML injection on src parameter would be:
Now the victim should visit: http://demofaast.elevenpaths.com:9002/xssbypass/iframebypass.php?iframe=%22srcdoc=%22%3Cscript%3Ealert(‘Bypass%20message’)%3C/script%3E
and XSS filter will fail and let the script run.
Google derived this to Chromium, who does not treat this bypasses as a security problem, since XSSauditor is considered a second defense line.
The problem was reported in October, the 23rd. They fixed it two days later, making XSSAuditor catch reflected srcdoc properties even without an “IFRAME” tag injection. Chrome has just fixed it in recent 32.0.1700.76 version.
Some other bug
A few weeks ago, in this post, someone took our PoC as an inspiration and developed another way of bypassing the filter. This one is still not fixed. The trick is to inject an opening “script” tag inside a parameter that is written directly in the HTTP request output stream. This is, without filtering any character just as our case. In this writing there should be content inside scripts tags that belongs to the web itself.
The browser will include our injection (remember, without closing the tag), omit the “script” opening tag from the web itself, and now, use the closing one from the web to create a well formed script and execute it… this is the bypass.
So this is the effect in this PoC we uploaded: http://demofaast.elevenpaths.com:9002/xssbypass/scriptbypass.php?value=%3Cscript%3Ealert%28%22Bypass%20Message%22%29
Safari, still vulnerable
Safari for Mac and iPhone is vulnerable as well. They confirmed our email, and told us they were working on it. And seems that they still are, since the program is still vulnerable. Everytime we have tried to contact back with them again, they reply back telling there is no news, but they are working on it. Internet Explorer filters it with its own filter, and Firefox does not implement an XSS filter by itself.