Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

The OAuth 2.0 specification's authorization code mechanism includes redirect URI checking from the site you redirect to. See steps D and E in section 4.1 of the spec. Also, section 4.1.3 describes in detail that the redirected-to client needs to transmit redirect_uri, and that it needs to match that of the initial authorization request.

I can't think of any attack vector that is mitigated by this being a part of the protocol. Why is this redirect_uri check necessary?

share|improve this question

2 Answers 2

By not validating the redirect_uri an OAuth provider can be used as an ideal phishing vector. The redirect_uri is an address used by OAuth providers as a location to deliver the access_token by means of a browser redirect. The popular OAuth provider Facebook has run into many vulnerabilities relating to OAuth redirection.

In this attack, the attacker presents the victim with a URL to an authentication portal that the victim trusts (like Facebook), and by using this authentication portal the victim's secret access token is delivered to an HTTP server controlled by the attacker.

Authentication is about intention, tricking a user into allowing access to an unintended resource is a vulnerability.

share|improve this answer
1  
But the redirection_uri in the Access Token Request (section 4.1.3 in the spec) mentioned by Steven Xu is only checked on the Authorization Server, the access_token is not redirected to this uri. So the code and the redirection_uri is checked before the access_token is returned to the client app... Me too, I can't think of a reason for the additional checking of the redirection_uri... –  pfust75 Oct 23 '13 at 6:02
    
Is it necessary to pass the redirect_uri when being authorized if the client provided it during the registration process? –  Kyle Hayes Jun 30 at 15:09

As Egor said, link 1:

all oauth exploits are based on tampering with the redirect_uri parameter.

and link 2:

Vector 2. If spec was implemented properly then tampering redirect_uri to other, "leaky", values is pointless. Because to obtain access token you must send redirect_uri value with client creds. If actual redirect_uri was "leaky" and not equal real redirect_uri Client will not be able to obtain access_token for this code.

redirect_uri is the callback for the Client to receive the Authorization Code. The Client treats anyone who brings the code as the Resource Owner.

Attacker may replace the redirect_uri with a malicious one in Step A to get the code. Then he can rebuild and trigger the uri to hijack the session belongs to the Resource Owner.

However, every code have a corresponding redirect_uri it was issued for, i.e., code will be calculated based on the polluted redirect_uri in Step C.

Note that the request in Step D is made by the Client. It will always use the right form of redirect_uri. Finally, Authorization Server turns out the code does not match the uri, therefor no token will be responded back in Step E.

share|improve this answer
    
Please check my answer. @pfust75 –  Anderson Feb 14 at 2:05

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.