On Aug 14, 2011, at 1:55 AM, Phillip Hunt wrote: > No. I don't think so. In the new variant the client has to check the returned > state to confirm it has not changed or associated with a different user. > > Previously the authz server had to do the checks.
In a CSRF attack, either of the two web servers (one is the OAuth "client" in this case) may be attacked with a CSRF. The defense against a CSRF is always for the recipient of the request to authenticate the requester in one way or another. One way to do that is with a CSRF token (see https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet). In OAuth, I think it's fair to say that an "OAuth CSRF attack" might be a special-case of a CSRF attack, but the typical defenses apply to both the OAuth "client" and the OAuth "resource server". - John > > Phil > > On 2011-08-13, at 21:16, "William J. Mills" <wmi...@yahoo-inc.com> wrote: > >> The defense is the same though, correct? >> >> From: Phil Hunt <phil.h...@oracle.com> >> To: Eran Hammer-Lahav <e...@hueniverse.com> >> Cc: "OAuth WG (oauth@ietf.org)" <oauth@ietf.org> >> Sent: Saturday, August 13, 2011 4:41 PM >> Subject: Re: [OAUTH-WG] Auth Code Swap Attack >> >> There are two CSRF variations scenarios that I see. >> >> I can attack you and give my client access to your resources (original >> attack on the "resource"). >> >> I can attack you and give your client access to my resource (new attack on >> the "client"). >> >> Attack on the client vs. attack on the resource may be misleading here. >> Draft 20 only referred to attacks on the "resource" in its original CSRF >> description. >> >> Phil >> >> @independentid >> www.independentid.com >> phil.h...@oracle.com >> >> >> >> >> >> On 2011-08-13, at 7:30 AM, Eran Hammer-Lahav wrote: >> >>> All OAuth CSRF attacks are on the client. >>> >>> EHL >>> >>> From: Phil Hunt <phil.h...@oracle.com> >>> Date: Sat, 13 Aug 2011 00:21:50 -0700 >>> To: Torsten Lodderstedt <tors...@lodderstedt.net> >>> Cc: Eran Hammer-lahav <e...@hueniverse.com>, "OAuth WG (oauth@ietf.org)" >>> <oauth@ietf.org> >>> Subject: Re: [OAUTH-WG] Auth Code Swap Attack >>> >>>> +1 (to putting more detail in the Threat Model document) >>>> >>>> Yes, this is another CSRF attack (hence the change to 10.2). >>>> >>>> What is *new* is this is an attack on the client application rather than >>>> the resource server. As such, I agree this new attack vector is well >>>> deserving of wider review and discussion before finalizing the draft. >>>> >>>> Phil >>>> >>>> @independentid >>>> www.independentid.com >>>> phil.h...@oracle.com >>>> >>>> >>>> >>>> >>>> >>>> On 2011-08-12, at 11:58 PM, Torsten Lodderstedt wrote: >>>> >>>>> >>>>> >>>>> 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. >>>>>>> > _______________________________________________ > 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
