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.<p>Interesting to see that Facebook responded by disabling the XSS protection header altogether.<p>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.
For people interested in "reducing OAuth2's attack surface", as Egor proposes, you should check out his post for suggestions on improving the spec (which he calls "OAuth 2.a"):<p><a href="http://homakov.blogspot.com/2012/08/saferweb-oauth2a-or-lets-just-fix-it.html" rel="nofollow">http://homakov.blogspot.com/2012/08/saferweb-oauth2a-or-lets...</a><p>His two most important suggestions are (1) make redirect_uri an exact whitelist instead of allowing pattern-matching and a single domain, and (2) scopes should be set by the user via the provider.<p>These are both very reasonable adjustments, and could likely be accommodated without too much headache by existing providers. However, they are technically spec-breaking, so this would be more like OAuth 3 than 2.a.
I'm rather surprised Egor is still an indie. Is this by his choice? He seems quite talented.<p>edit: Ahh, I should've looked more closely. This is just his hobby: <a href="http://homakov.blogspot.com/p/service.html" rel="nofollow">http://homakov.blogspot.com/p/service.html</a>
Interesting to see Homakov having a pretty solid run with some very interesting exploits after the GitHub exploit, I thought that he may have been burned by the experience and put off from active research. Apparently you can't keep a good security researcher down.<p>Definitely interesting with OAuth2 having a 'huge attack surface', I'd love to hear some more about that given how many companies have started using it for securing API access amongst other things.
The chief problem with OAuth2 is that you can do almost anything and call it "OAuth2" -- the spec is ridiculously flexible, and allows all kinds of options that are explicitly stated within the spec as not advised.<p>I'm fairly sure most of the flexibility is there to help migrating enterprise and legacy apps to OAuth2. It's not a great approach, though -- enough security disasters and the problems of migrating will simply go away, because the poor rep of the mechanism will mean no migrations are happening.<p>I'm using OAuth2 for an API, but a small subset of it that doesn't seem to permit the abuse Egor covers -- though I'm going over it with a fine-toothed comb now. XSS vulnerabilities are more subtle than most other hacks, and so the dangers aren't as obvious in a simple review.
Seems like homakov is making a name for himself, it's always interesting to see what he finds out. Can anybody recommend me other blogs with even more info about security holes in known platforms?
Cute.<p>I'm really looking forward to the next article. I've heard talk of OAuth2 as an enterprise authentication mechanism and it's stuff like this that helps keep everyone honest.<p>That being said I'd much rather be the guy who has 10000 folks banging away at his stack than the one who is never tested. It's hard to know which buckets are leaking until you fill them.
This is why you shouldn't rely on third-party auth. Everyone using their own auth may be more trouble for the user, but SSO through a private third-party that the largest portion of users already use, is just asking for it. Don't get me wrong, SSO is not bad. But, the bigger the subject, the more resources will try to hack it. This can make the subject stronger and more secure over the long-term, potentially, but in the meantime, you have to live with being hacked much more frequently. Why not learn from others' mistakes rather than be their victim, when it comes to security?
"In "real world" exploit we would use 100-200 most popular Facebook applications and just gather all the available tokens. It would be awesome."<p>Highly entertaining (and illuminating) article.
Can someone explain in plain language to a non-developer:<p>1. I have web site<p>2. I do not have FB app<p>3. I have FB page<p>4. I enable for users "Login with your FB account"<p>5. I have FB Like button on the web site<p>Am I vulnerable and if yes, what's the vector/consequences?<p>Edit: formatting