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.
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.
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.
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"):
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.
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.
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.
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.
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.
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.
but root of insecureness is OAuth2 spec, why would someone implement response_type as a parameter? Aha, spec says so! Why would anyone set redirect_uri dynamic, not static? Spec allows! Scope as a parameter, not a setting? Hi, spec!
I don't support alternative response_types; I don't support dynamic redirect_uri (at the moment, it's completely static; in future we may offer the list option), and the allowed scope for a given client is set during setup -- you can't then request a scope you aren't authorized for, given your client id.
I'm not breaking the spec -- it offers all of these paths as options. You don't have to implement all of the possibilities the spec covers.
The bad thing about the spec is that some of the possible paths are indeed less secure (it even says so in the spec in places...), so the security of your OAuth2 implementation is purely up to your judgement.
The nice thing about good specs is that you benefit from the presumably-better judgement of the folks designing the spec....
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?
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.
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?
Fair but sometimes it's unavoidable when you're trying to use third party APIs such as Facebook or Google. The only option is to allow some sort of external login (be it oauth or something similar)
I'll take a shot at this, but I only did a cursory reading of the article.
To begin with, I don't believe you are vulnerable through this exploit any more. Facebook has fixed this by changing the response in OAuth so that it would no longer trigger the block redirect. In particular:
"Facebook had '1; mode=block' header. Now it's 0; because of us"
Every site using Facebook's OAuth was vulnerable. I don't believe the basic FB like button actually uses OAuth, but using FB as a way to login to your site would.
The vulnerability takes advantage of Chrome's handling of the above response from the server. When it sees that response, it loads a separate page to prevent the request from going through. The problem is this particular page has details about the request, like OAuth credentials in the response, and allows a third party script to have access to details about the request. Once an attacker has access to OAuth credentials, they basically have access to the login credentials for that user (ie as if the user's username and password were compromised)
Any user that is logged in to FB can have their OAuth app credentials compromised if they visited a site running this malicious code.
If I'm not mistaken, #2 and #4 are mutually incompatible: you auth people through your app and then your website can make API calls. If the only one it makes is the "get basic info" call that's fine, but it's still an app.
We come up with these problems too and most of them aren't important. And how are these things solutions, when they're always broken? OAuth 1.0, OAuth 2.0, OpenID - all have their issues, none of them is a sensible solution, perhaps the problem they pretend to solve is only a result of other bad designs?
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.