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: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
