On Mon, May 2, 2011 at 11:33 AM, Freeman, Tim <tim.free...@hp.com> wrote:
> The issues around redirect_uri seem muddled to me. > Yeah. =/ It's unfortunate. I think the problem is that implementers disagree on what type of redirect uri validation to do, so the spec has papered over the inconsistencies with muddled language. Avoiding open redirectors on the authorization server is worth doing, but open redirectors on the relying party side are a very serious risk. Here is a concrete example of an attack that implementations need to prevent. User visits evil.com. evil.com redirects with client_id of "good.com" and a callback URL of " https://good.com/bounce?continue=https://evil.com"; Authorization server generates either an access token and sends redirect to "https://good.com/bounce?continue=https://evil.com#token=<token" good.com redirects to evil.com with token in URL. evil.com walks off with token. The right way to fix that is with fairly strict matching between client-ids and callback URLs. This is the approach that the SAML spec took for this problem. It's also the approach used by Google's OAuth2 implementation. There are several other approaches that have been discussed that don't actually work to defend against that attack. - you can't prevent this by requiring HMACs on data access requests The evil server can replay the victim's access token to the good server. The good server will then use it's own HMAC key to make data access requests using the victim's token. The victim's data is then returned to the attacker. - you can't prevent this by using https for callback URLs. Redirects are an application level leak. The browser is sending the token directly to the evil server. - you can't prevent this by telling good.com not to host any pages that redirect to third-party sites. good.com, like most other web sites, will have a need to host redirectors. Most sites ignore them. A few go to great lengths to close them, but the most common techniques for closing redirectors don't defend against this attack. Referer leaks are a related problem. The exploitation is a bit different, but the same mitigation (strict callback URL matching) still works. Cheers, Brian
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
