Covert Redirect Vulnerability with OAuth 2
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.
There’s a couple of defending arguments that this isn’t a flaw in OAuth itself.
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.
When 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=xyzPeople 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 http://malicious.example/#access_token=xyz.
Now, the fragment isn’t sent to the malicious site over the wire as part of an HTTP request, but once the browser gets to the page it’s game over — the site can grab the token using JavaScript via location.hash pretty easily.
Having said that, the right answer to this threat would be:
- Strict validation on redirect_uri
- 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.