Hacker News Reader

Comment by gdeglin | Hacker News Reader

This is clever. The Chrome team likely made a major oversight when they made the decision to introduce the 1;mode=block value for the X-XSS-Protection header.

Interesting to see that Facebook responded by disabling the XSS protection header altogether.

Most likely the reason Facebook didn't just set it to X-XSS-Protection: 1 is because a similar technique could then be used to defeat Javascript based clickjacking protection.

View on HN

It seems strange that you can use a browser bug to get into a site. Since the browser's outside of FB's control (i.e. theoretically anyone could write their own, including one which said it was Chrome but had been created for malicious purposes) any security protocol should not rely on browser implementations.

It's only strange at first sight. If your site depends upon browser-specific features as the sole source of a security mechanism, it stands to reason that it will turn into pain for you.

This is another solid example of the lesson: if the user controls it, the input is malicious. Always.

This isn't unprecedented. IE6 has been used to attack websites in the past. http://www.theregister.co.uk/2010/02/01/ie6_microsoft_uk_gov...

Max Butler is famous for using the HTML application in IE to harvest credit card information way back in 1999.

The way I understood the article is that this relies on harvesting data from users on your site. As you cannot control which browser your users have, the point here is that this exploit relies on a vulnerability in a mass-adopted browser.

I'm not sure what you're suggesting when you suggest not relying on browser implementation. This sounds impossible as the browser is the client and the client will have access to user credentials.

Yes, I recommended to use 0; because 1; has flaws too (slicing framebrakers).

Reply on news.ycombinator.com