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

http://homakov.blogspot.com/2012/08/saferweb-oauth2a-or-lets...

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.

And nobody listened to him. And he was right.

The lead author and editor, Eran Hammer.

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 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.

Billy Rios (discovered GIFAR) http://xs-sniper.com/blog/

Michal Zalewski (one of the top security researchers in the world, wrote "The Tangled Web", a must-read) http://lcamtuf.blogspot.com

Neal Poole: https://nealpoole.com/blog/

Nir Goldshlager: http://www.nirgoldshlager.com/

Michael Brooks: https://sitewatch.me/en/Blog

Nils Jünemann: http://www.nilsjuenemann.de/

Stefano di Paola (Minded Security): http://blog.mindedsecurity.com/

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.

1. I have web site

2. I do not have FB app

3. I have FB page

4. I enable for users "Login with your FB account"

5. I have FB Like button on the web site

Am I vulnerable and if yes, what's the vector/consequences?

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)