I'm using my proposed text in -21. EHL
> -----Original Message----- > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf > Of Eran Hammer-Lahav > Sent: Saturday, August 13, 2011 8:14 AM > To: Torsten Lodderstedt > Cc: OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] Auth Code Swap Attack > > Again, the idea that you can produce a comprehensive description of security > threat is impractical if you are going to include every browser-based attack > and its remedies. OAuth use of browser redirection imports almost every > possible attack vector on the web. That's my point. > People constantly bring up these attack vectors, and in multiple flavors and > variations, as if *anyone* can produce a complete list of these issues. > > Now, this doesn't mean we should not try to be comprehensive but this can > go on forever. > > The changes to 10.12 seem reasonable with the exception of the new > MUSTs. > I disagree that we should mandate clients to use the state parameter as the > only CSRF protection vector, especially in an evolving web environment. We > can still include a MUST for verifying that the user redirected to the > authorization server is the same user coming back, and highlight the state > parameter as one way to accomplish that. > > How about: > > > state: OPTIONAL. An opaque value used by the client to maintain state > between the request and redirection. The authorization server includes this > value when redirecting the user-agent back to the client. Use of the "state" > parameter is RECOMMENDED for preventing cross-site request forgery as > described in Section 10.12. > > > > > Section 10.12 Cross-Site Request Forgery > > > Cross-site request forgery (CSRF) is a web-based attack whereby HTTP > requests are transmitted from the user-agent of an end-user the server > trusts or has authenticated. CSRF attacks enable the attacker to intermix the > attacker's security context with that of the resource owner resulting in a > compromise of either the resource server or of the client application itself. > > In the OAuth context, such attacks allow an attacker to inject their own > authorization code or access token into the client, which can result in the > client associating the attacker's protected resources to the victim's account > on the client. Depending on the nature of the client and the protected > resources, this can have undesirable and damaging effects. In order to > prevent such attacks, the client MUST employ CSRF protection. > > It is strongly RECOMMENDED for the client to utilize the "state" request > parameter with authorization requests to the authorization server. When > used for CSRF prevention, the "state" request parameter MUST contain a > non-guessable value, which the client MUST also store with the resource > owner's user-agent in a location accessible only to the client or the resource > owner's user-agent (i.e., protected by same-origin policy). For example, the > client can using a DOM variable, HTTP cookie, or HTML5 client-side storage. > > > When redirecting the resource owner's user-agent back to the client, the > authorization server includes the value of the "state" parameter. Upon > receiving the redirection request, the client MUST confirm that returned > value of the "state" parameter matches the value stored with the resource > owner's user-agent. > > > EHL > > > > > From: Torsten Lodderstedt <tors...@lodderstedt.net> > Date: Fri, 12 Aug 2011 23:58:02 -0700 > To: Eran Hammer-lahav <e...@hueniverse.com> > Cc: Anthony Nadalin <tony...@microsoft.com>, "OAuth WG > (oauth@ietf.org)" > <oauth@ietf.org> > Subject: Re: [OAUTH-WG] Auth Code Swap Attack > > > > > > > > > > > > > > > > > > Am 12.08.2011 23:52, schrieb Eran Hammer-Lahav: > > > > This is really just a flavor of CSRF attacks. I have no > > objections to better documenting it (though I feel the current > > text is already sufficient), but we can't realistically expect > > to identify and close every possible browser-based attack. A new > > one is invented every other week. > > > > > > The problem with this text is that developers who do no > > understand CSRF attacks are not likely to implement it correctly > > with this information. Those who understand it do not need the > > extra verbiage which is more confusing than helpful. > > > > > > > > We are constantly facing the fact that a comprehensive description > > of security threats needs more space than we have in the core draft. > > That's the reason why the security document has 63 pages and that's > > also the reason why we decided to let the core spec refer to this > > document for in-depth explanations. This holds true for this threat > > as well. > > > > regards, > > Torsten. > > > > > > > > > > As for the new requirements, they are insufficient to > > actually accomplish what the authors propose without additional > > requirements on state local storage and verification to complete > > the flow. Also, the proposed text needs clarifications as noted > > below. > > > > > > > > > > > > From: Anthony Nadalin <tony...@microsoft.com> > > Date: Fri, 12 Aug 2011 > > 12:06:36 -0700 > > To: "OAuth WG (oauth@ietf.org)" > > <oauth@ietf.org> > > Subject: [OAUTH-WG] > > Auth Code Swap Attack > > > > > > > > > > >> > >> > >> > > > > > > > > > > > > > > > > >> > >> > >> > >> Recommended > >> Changes to draft-ietf-oauth-v2 > >> > >> In section 4, request options (e.g. > >> 4.1.1) featuring "state" should change from: > >> > >> state > >> OPTIONAL. > >> An opaque value used by the client to maintain state > >> between the request and callback. The authorization > >> server includes this value when redirecting the > >> user-agent back to the client. > >> > >> to: > >> > >> state > >> REQUIRED. > >> An opaque value used by the client to maintain state > >> between the request and callback. The authorization > >> server includes this value when redirecting the > >> user-agent back to the client. The encoded value > >> SHOULD enable the client application to determine > >> the user-context that was active at the time of the > >> request (see section 10.12). The value MUST NOT be > >> guessable or predictable, and MUST be kept > >> confidential. > >> > >> > >> > >> > >> > > > > > > > > Making the parameter required without making its usage > > required (I.e. "value SHOULD enable") accomplishes nothing. > > Also, what does "MUST be kept confidential" mean? Confidential > > from what? Why specify an "encoded value"? > > > > > > > > > > > > > > >> > >> > >> > >> Section 10.12 Cross-Site Request > >> Forgery > >> > >> Change to: > >> > >> Cross-site > >> request forgery (CSRF) is a web-based attack whereby > >> HTTP requests are transmitted from the user-agent of > >> an end-user the server trusts or has authenticated. > >> CSRF attacks enable the attacker to intermix the > >> attacker's security context with that of > >> the resource owner resulting in a compromise of > >> either the resource server or of the client > >> application itself. In the OAuth context, > >> such attacks allow an attacker to inject their own > >> authorization code or access token into a client, > >> which can result in the client using an access token > >> associated with the attacker's account rather than > >> the victim's. Depending on the nature of the client > >> and the protected resources, this can have > >> undesirable and damaging effects. > >> > >> In order to prevent such attacks, the client > >> application MUST encode a non-guessable, > >> confidential end-user artifact and submit as the > >> "state" parameter to authorization and access token > >> requests to the authorization server. The client > >> MUST keep the state value in a location accessible > >> only by the client or the user-agent (i.e., > >> protected by same-origin policy), for example, using > >> a DOM variable, HTTP cookie, or HTML5 client-side > >> storage. > >> > >> The authorization server includes the value of the > >> "state" parameter when redirecting the user-agent > >> back to the client. Upon receiving a redirect, the > >> client application MUST confirm that returned value > >> of "state" corresponds to the state value of the > >> user-agent's user session. If the end-user session > >> represents an authenticated user-identity, the > >> client MUST ensure that the user-identity has NOT > >> changed. > >> > >> > >> > >> > >> > > > > > > > > The above text uses 'user-context' and this 'user-identity'. > > Neither term is defined. > > > > > > EHL > > > > > > > > _______________________________________________ > >OAuth mailing list > >OAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth > > > > > > > > _______________________________________________ > 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
