Subject: Re: [OAUTH-WG] requirement of redirect_uri in access token requests

From: "Freeman, Tim" <[email-masked]>
Date: Mon, 2 May 2011 18:33:16 +0000

The issues around redirect_uri seem muddled to me.  Here's what I know right now:

Brian Eaton apparently said:
>This provides a defense against authorization codes which have leaked due to open redirectors.

I looked for "redirector" in

   http://tools.ietf.org/html//draft-lodderstedt-oauth-security-01

which is apparently the latest draft of the security considerations document.  The only mention is in section 4.2.4 under "Threat: Open redirector", which I can quote in full:

   An attacker could use the end-user authorization endpoint and the
   redirect_uri parameter to abuse the authorization server as
   redirector.

   Impact?

   Countermeasure
   o  don't redirect to redirect_uri, if client identity or redirect_uri
      could not be verified

I don't know what this means.  The word "abuse" is vague, and the "Impact" section is blank.  At least in the bearer token version of the protocol, I believe we do all of our redirecting before verifying the client identity, so I don't see how we can know whether the client identity can be verified when we're deciding whether to redirect.   It would help to have a specific sequence of events that is undesired.  I can't tell if this only mention of "redirector" in Torsten Lodderstedt's document matches what Brian was talking about.

I talked some about whether we need the redirect_uri at:

   http://www.ietf.org/mail-archive/web/oauth/current/msg05733.html

Judging by the "Next by thread" link on that page, nobody replied to this.  I do not think the failure scenario I described involves an open redirector, so I think the problem I described (if the redirect_uri is not checked) is different from Brian's.  I haven't read the security considerations document carefully enough to know whether the failure scenario I described appears in it.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Brian Eaton
Sent: Saturday, April 30, 2011 2:29 PM
To: Doug Tangren
Cc: [email-masked]
Subject: Re: [OAUTH-WG] requirement of redirect_uri in access token requests

On Fri, Apr 29, 2011 at 11:21 AM, Doug Tangren <[email-masked]<mailto:[email-masked]>> wrote:
Is this required or not? In the example http://tools.ietf.org/html/draft-ietf-oauth-v2-15#section-3.1 it's listed in the example but not itemized as optional or required. It's not in the example for refreshing tokens http://tools.ietf.org/html/draft-ietf-oauth-v2-15#section-6 though that section links back to section 3.1 which does use a redirect_uri in the example.

Should the redirect_uri be a requirement for client authentication or is it optional?

It should be required when exchanging an authorization code for a refresh token.  This provides a defense against authorization codes which have leaked due to open redirectors.

It should not be present under other circumstances.

---

From: Brian Eaton <[email-masked]>
Date: Mon, 2 May 2011 11:52:31 -0700

On Mon, May 2, 2011 at 11:33 AM, Freeman, Tim <[email-masked]> 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