Full Report
XSS auditor was a Chrome feature that allows for the header X-XSS-Protection: 1 to block XSS attacks. If an XSS attack is found, then Chrome will clear the entire page. The author of this post decided to look at this feature for potential security issues. XSS auditor attempted to find reflected XSS attacks. This was done by reading the request body and seeing if DOM-tree was created directly from input in the URL. This paper discusses some transforms that try to comply with, such as PHP magic quotes and Unicode normalizations. Any larger transformations cannot be caught. The post linked in this report is all about creating an oracle based on whether the XSS auditor is present or not to leak data off the page. Since the number of iframes on a page can be read across windows, this can be used in conjunction with the removal of the iframe as an oracle. The page isn't IN the iframe, but the iframe serves as an oracle to determine whether the page is loaded correctly or not. Their first idea was to read a user ID character by character by using fake XSS payloads. First, they include a fake XSS payload that looks something like uid = 1337; in the URL. This is what the page normally looks like, though. Now, you put the data that you want to check into the URL. For instance, uid = 1;. Since this is NOT on the page, nothing happens. You can iterate on the UID over and over again until the XSS auditor finds the string match and blocks. Another mechanism this was on was form actions. By having a named parameter in an HTML form, such as x=123456, the form can be injected as the "fake input" to search through this character by character. XSS auditor ignores 0's for some reason. So, some extra logic that assumes that something is a zero if no matches are found is used instead. Knowledge about the value being used, such as its length and character, can also be helpful. If the page isn't framable, then this becomes harder to do using new windows. It just requires checking load times and doing some timeout checks. The history of this fix is pretty funny, according to this article. Initially, only the dangerous scripts were removed. But, this was insecure because security features may be deactivated this way, so the whole page was blocked. Then, to fix the bug in this report, it was reverted back to blocking only the dangerous scripts again. Besides the security leak mentioned in this post, the same idea of a fake payload was used to remove arbitrary scripts from the page by placing the information in the URL with the deactivation setting. Eventually, the feature was removed from Chrome altogether because of the issues it created that were unsolvable. Overall, an interesting feature with a lot of awesome bypasses!
Analysis Summary