Subject: Re: [OAUTH-WG] state parameter and XSRF detection

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 7 Jul 2011 01:37:48 -0700

Allowing any flexibly in the redirection URI is a bad thing and the latest draft (pre -17) clearly states that. The main fear is that by allowing the query to be changed dynamically, attackers can find open redirector loopholes to abuse. I really wanted to make registration of the absolute URI a MUST, but didn't go that far.

EHL

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Torsten Lodderstedt
> Sent: Monday, June 27, 2011 2:22 PM
> To: OAuth WG
> Subject: [OAUTH-WG] state parameter and XSRF detection
> 
> Hi all,
> 
> while working on a new revision of the OAuth security document, a question
> arose I would like to clarify on the list.
> 
> The "state" parameter is supposed to be used to link a certain authorization
> request and response. Therefore, the client stores a value in this parameter
> that is somehow bound to a value retained on the device (the user agent)
> originating the authorization request.
> 
> The question now is: Would it be compliant with the core spec to use any
> other URI query parameter encoded in the redirect_uri, instead of the
> "state" parameter, to achieve the same goal? Probably the client already has
> a working "legacy" implementation it does not want to change just for
> OAuth2 compliance.
> 
> According to section 2.2.1, the redirection uri could contain a dynamic
> portion:
> 
> "The authorization server SHOULD require the client to pre-register
>     their redirection URI or at least certain components such as the
>     scheme, host, port and path"
> 
> So this should be fine.
> 
> Any comments?
> 
> regards,
> Torsten.
> 
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Torsten Lodderstedt <[email-masked]>
Date: Fri, 08 Jul 2011 11:22:33 +0300

Hi Eran,

including dynamic values within redirect uris is standard practice today and is allowed by the spec's text so far. I don't mind to change it but the restricted behavior you prefer is a significant protocol change.

Moreover, I would like to understand the threat you have in mind and include it into our threat model. So would you please provide a more detailed description?

regards,
Torsten.

Eran Hammer-Lahav <[email-masked]> schrieb:

EHL

>_____________________________________________

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 8 Jul 2011 10:03:29 -0700

The security of the protocol relies fully (implicit grant) or partially (authorization code) on the validation of the redirection URI. This was well understood by many experts but until -17, we largely ignored by the specification.

Using dynamic values are still fully supported:

   3.1.2.2.  Registration Requirements

   The authorization server MUST require public clients to register
   their redirection URI, MUST require all clients to register their
   redirection URI prior to utilizing the implicit grant type, and
   SHOULD require all clients to register their redirection URI prior to
   utilizing the authorization code grant type.

   The authorization server SHOULD require the client to provide the
   complete redirection URI (the client MAY use the "state" request
   parameter to achieve per-request customization).  The authorization
   server MAY allow the client to register multiple redirection URIs.
   If requiring the registration of the complete redirection URI is not
   possible, the authorization server SHOULD require the registration of
   the URI scheme, authority, and path.

And 3.1.2.3.  Dynamic Configuration, adds:

   If the authorization server allows the client to dynamically change
   the query component of the redirection URI, the client MUST ensure
   that manipulation of the query component by an attacker cannot lead
   to an abuse of the redirection endpoint as an open redirector.

The rational for this is that comparing full URIs (using simple string comparison) provides for much less moving parts. We know from experience that URI normalization is hard and that attackers sometimes find ways to inject values into the redirection URI and still pass validation (based on the specific issues with the server’s normalization logic).

We were unable to come up with a useful set of rules for redirection URI validation based on individually registered URI components. This has also been an area of great confusion by OAuth 1.0 developers, as each provider has its own set of rules and methods for URI registration. Some implementations are outright idiotic. On the other hand, if we recommend developers to simply do string comparison (per RFC 3986 section 6) and not allow any changes, we know it is much more likely to be implemented securely.

Beyond the complexity of normalization and comparison: many existing platform allow for internal redirections and special handling using special query parameters. Most login pages support some form of automatic redirection to the referring resource. If an attacker can access such a parameter, it can manipulate the redirection URI to pass validation but produce very different results. The worst case scenario is finding a query parameter capable of triggering a redirection which will then send the credentials to the attacker.

The simplest form of this attack is the availability of an open redirector (which most large providers have, some with better safeguards then others). If example.com offers an open redirector, registration of the scheme and authority will accomplish nothing, as the open redirector endpoint will pass validation. Registration of the full path is *usually* sufficient, but not always, and relies of proper normalization that forces a query separator '?' between the fully registered path and the appended query (as well as enforce proper reserved characters encoding).

The typical sophistication of the authorization server developer is much greater than that of the client developer. It is better to encourage the server developer to enforce better policy, than hope that the client developer will be able to find and close every potential security hole in its entire system to render redirection URI validation trustworthy.

The specification provides and highlights the 'state' parameter as the proper way of accomplishing redirection URI customization. It is significantly simpler to restrict validation to simple string comparison, and protect the 'state' parameter on the client from being abused by an attacker.

If I had it my way, the specification would ban any type of dynamic redirection URI (other than selecting one out of multiple fully specified options). But this proposal was rejected (for no good reasons, just people stuck to their broken old ways), so the new text is the best I can do without making breaking changes.

EHL

From: Torsten Lodderstedt [mailto:[email-masked]] 
Sent: Friday, July 08, 2011 1:23 AM
To: Eran Hammer-Lahav; OAuth WG
Subject: RE: [OAUTH-WG] state parameter and XSRF detection

Hi Eran,

regards,
Torsten.

EHL

>     scheme, host, port and path"
________________________________________

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sun, 10 Jul 2011 12:17:16 +0300

Eran Hammer-Lahav <[email-masked]> schrieb:

>The security of the protocol relies fully (implicit grant) or partially
>(authorization code) on the validation of the redirection URI. This was
>well understood by many experts but until -17, we largely ignored by
>the specification.

what does "security of the protocol" mean? Wrt what threats?

I see detection/prevention of malicious clients. Anything else?

I personally think there are various features of the protocol contributing to the overall security level of the protocol protocol (for different threats). For example: user engagement and control plays an important role. We documented those relations in the security document.

Redirect uri validation is, in my opinion, not effective for native apps and useless if the attacker uses a native app (no matter whether the legitimate client is a web, user agent based or native app). Thus I consider relying on this mean exclusively is dangerous.

>   the URI scheme, authority, and path.

So what this text basically says is: You should enforce full uri registration & validation but you don't have to. Which also means my use case for XSRF prevention using other parameters is still supported. Am I wrong?

>The rational for this is that comparing full URIs (using simple string
>comparison) provides for much less moving parts. We know from
>experience that URI normalization is hard and that attackers sometimes
>find ways to inject values into the redirection URI and still pass
>validation (based on the specific issues with the server’s
>normalization logic).
>
>We were unable to come up with a useful set of rules for redirection
>URI validation based on individually registered URI components. This
>has also been an area of great confusion by OAuth 1.0 developers, as
>each provider has its own set of rules and methods for URI
>registration. Some implementations are outright idiotic. On the other
>hand, if we recommend developers to simply do string comparison (per
>RFC 3986 section 6) and not allow any changes, we know it is much more
>likely to be implemented securely.
>
>Beyond the complexity of normalization and comparison: many existing
>platform allow for internal redirections and special handling using
>special query parameters. Most login pages support some form of
>automatic redirection to the referring resource. If an attacker can
>access such a parameter, it can manipulate the redirection URI to pass
>validation but produce very different results. The worst case scenario
>is finding a query parameter capable of triggering a redirection which
>will then send the credentials to the attacker.
>
>The simplest form of this attack is the availability of an open
>redirector (which most large providers have, some with better
>safeguards then others). If example.com offers an open redirector,
>registration of the scheme and authority will accomplish nothing, as
>the open redirector endpoint will pass validation. Registration of the
>full path is *usually* sufficient, but not always, and relies of proper
>normalization that forces a query separator '?' between the fully
>registered path and the appended query (as well as enforce proper
>reserved characters encoding).
>
>The typical sophistication of the authorization server developer is
>much greater than that of the client developer. It is better to
>encourage the server developer to enforce better policy, than hope that
>the client developer will be able to find and close every potential
>security hole in its entire system to render redirection URI validation
>trustworthy.
>
>The specification provides and highlights the 'state' parameter as the
>proper way of accomplishing redirection URI customization. It is
>significantly simpler to restrict validation to simple string
>comparison, and protect the 'state' parameter on the client from being
>abused by an attacker.

Understood and afterwards
agreed. I would be happy to add this to the security document.

regards,
Torsten.

>
>If I had it my way, the specification would ban any type of dynamic
>redirection URI (other than selecting one out of multiple fully
>specified options). But this proposal was rejected (for no good
>reasons, just people stuck to their broken old ways), so the new text
>is the best I can do without making breaking changes.
>
>EHL
>
>
>
>
>
>including dynamic values within redirect uris is standard practice
>today and is allowed by the spec's text so far. I don't mind to change
>it but the restricted behavior you prefer is a significant protocol
>change.
>
>Moreover, I would like to understand the threat you have in mind and
>include it into our threat model. So would you please provide a more
>detailed description?
>
>regards,
>Torsten.
>
>
>
>Allowing any flexibly in the redirection URI is a bad thing and the
>latest draft (pre -17) clearly states that. The main fear is that by
>allowing the query to be changed dynamically, attackers can find open
>redirector loopholes to abuse. I really wanted to make registration of
>the absolute URI a MUST, but didn't go that far.
>
>EHL
>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Sun, 10 Jul 2011 10:45:29 -0700

> Sent: Sunday, July 10, 2011 2:17 AM

> what does "security of the protocol" mean? Wrt what threats?

s/security of the protocol/client identification

> I personally think there are various features of the protocol contributing to
> the overall security level of the protocol protocol (for different threats). For
> example: user engagement and control plays an important role. We
> documented those relations in the security document.

User engagement is nice in theory. In practice, it is more likely to enable attacks than prevent them (e.g. phishing).
 
> Redirect uri validation is, in my opinion, not effective for native apps and
> useless if the attacker uses a native app (no matter whether the legitimate
> client is a web, user agent based or native app). Thus I consider relying on
> this mean exclusively is dangerous.

There are no other practical means. Also, can you describe an attack involving a native application that is more problematic than the actual installation of a malicious native application?

> So what this text basically says is: You should enforce full uri registration &
> validation but you don't have to. Which also means my use case for XSRF
> prevention using other parameters is still supported. Am I wrong?

Full registration is recommended. Allowing changes should be limited to the query, and doing that comes with its own can of worms to look for. But yes, your use case is still supported. Personally, I will never deploy anything but full registration of redirection URI.

EHL