Eran Hammer-Lahav <e...@hueniverse.com> 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.
>
>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.
>
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?
>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.
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
>
>
>
>
>
>From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net]
>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,
>
>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 <e...@hueniverse.com> schrieb:
>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: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] 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
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
