I suppose you're talking about this: http://www.ietf.org/mail-archive/web/oauth/current/msg07275.html
It is indeed more complete w.r.t. CSRF attacks on the client's redirection URI, but it does not address CSRF attacks on the authorization server. I believe something along the lines of the text I proposed could be combined in whichever text is eventually decided upon. -- Niv On Fri, Aug 19, 2011 at 02:46, William J. Mills <wmi...@yahoo-inc.com> wrote: > I proposed text that I think is more complete in a previous message... > ________________________________ > From: Niv Steingarten <nivst...@gmail.com> > To: Eran Hammer-Lahav <e...@hueniverse.com> > Cc: "oauth@ietf.org" <oauth@ietf.org> > Sent: Thursday, August 18, 2011 4:33 PM > Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner > Impersonation) > > How about add something like this as the second paragraph in 10.12: > > The authorization server SHOULD employ measures to prevent CSRF > attacks on the authorization endpoint. A non-guessable token SHOULD > be included in requests and form submissions within the authorization > server's internal authorization flow. This token MUST NOT be > accessible by the client. In addition, the authorization server may > make use of HTTP referrer headers in order to verify the origin of > requests made during the authorization flow. > > In addition, I think that: > > The "state" request parameter SHOULD be used to mitigate against CSRF > attacks, ... > > should be changed to: > > The "state" request parameter SHOULD be used to mitigate against CSRF > attacks against the client's redirection URI, ... > > so that the fact that the 'state' parameter protects against CSRF > attacks on the *client*, as opposed to CSRF on the *authorization > server*, is made explicit. > > -- Niv > > > On Fri, Aug 19, 2011 at 00:13, Eran Hammer-Lahav <e...@hueniverse.com> > wrote: >> >> >>> -----Original Message----- >>> From: Niv Steingarten [mailto:nivst...@gmail.com] >>> Sent: Thursday, August 18, 2011 1:04 PM >>> To: Eran Hammer-Lahav >>> Cc: Torsten Lodderstedt; oauth@ietf.org >>> Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner >>> Impersonation) >>> >>> On Thu, Aug 18, 2011 at 22:19, Eran Hammer-Lahav <e...@hueniverse.com> >>> wrote: >>> > >>> > >>> >> -----Original Message----- >>> >> From: Niv Steingarten [mailto:nivst...@gmail.com] >>> >> Sent: Thursday, August 18, 2011 12:12 PM >>> >> To: Eran Hammer-Lahav >>> >> Cc: Torsten Lodderstedt; oauth@ietf.org >>> >> Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner >>> >> Impersonation) >>> >> >>> >> On Thu, Aug 18, 2011 at 21:17, Eran Hammer-Lahav >>> >> <e...@hueniverse.com> >>> >> wrote: >>> >> > >>> >> > >>> >> >> -----Original Message----- >>> >> >> From: Niv Steingarten [mailto:nivst...@gmail.com] >>> >> >> Sent: Thursday, August 18, 2011 11:08 AM >>> >> >> To: Eran Hammer-Lahav >>> >> >> Cc: Torsten Lodderstedt; oauth@ietf.org >>> >> >> Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner >>> >> >> Impersonation) >>> >> >> >>> >> >> On Thu, Aug 18, 2011 at 20:31, Eran Hammer-Lahav >>> >> >> <e...@hueniverse.com> >>> >> >> wrote: >>> >> >> > >>> >> >> > >>> >> >> >> -----Original Message----- >>> >> >> >> From: Niv Steingarten [mailto:nivst...@gmail.com] >>> >> >> >> Sent: Thursday, August 18, 2011 10:16 AM >>> >> >> >> To: Eran Hammer-Lahav >>> >> >> >> Cc: Torsten Lodderstedt; oauth@ietf.org >>> >> >> >> Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource >>> >> >> >> Owner >>> >> >> >> Impersonation) >>> >> >> >> >>> >> >> > Can you provide another example with the same level of detail as >>> >> >> > you >>> >> >> provided below? >>> >> >> >>> >> >> The malicious client sends a request to the authorization endpoint >>> >> >> with the appropriate parameters, and in return receives the markup >>> >> >> of the web-page which should be displayed to the user in order to >>> >> >> get consent. In addition, since the request is launched not via a >>> >> >> sandboxed user-agent, the client also has access to any >>> >> >> 'Set-Cookie' >>> >> >> HTTP headers. >>> >> >> >>> >> >> Instead of displaying the page to the user, the client extracts >>> >> >> the web-form data (including the hidden nonce/token) which would >>> >> >> be submitted when 'Allow' is clicked. It then forges the >>> >> >> appropriate POST request with the cookies, form data and referrer, >>> >> >> and dispatches it, >>> >> > >>> >> > SCENE MISSING [1] >>> >> > >>> >> >> to finally receive an access token/authorization code in the >>> >> >> redirection. >>> >> > >>> >> > You skipped the best part! >>> >> > >>> >> > What do you mean by "dispatches it"? How is the resource owner >>> >> > tricked >>> >> or abused to grant authorization unknowingly? I understand how your >>> >> proposal "fixes" the first half, but not what kind of attack is >>> >> happening in the second half. >>> >> > >>> >> >>> >> I might have accidentally skipped the part where the user is already >>> >> logged in at the authorization endpoint, so no log-in is required but >>> >> rather just allowing/denying access (correction: the first request is >>> >> sent using an HTTP framework/WebKit, so no access to cookies). Once >>> >> it extracts the data from the web-form, the client has all the >>> >> information it needs in order to create an HTTP request >>> > >>> > No - the attacker does not have access to the session cookie. It still >>> > needs >>> to find a way to make a CSS call. >>> > >>> >>> That's what I said -- "no access to cookies". >> >> You only said that about the first request. >> >>> But since both requests (the one >>> requesting the auth endpoint and the one simulating the >>> "allow") are sent from the same user-agent, the cookies are handled by >>> the >>> user-agent itself. The client just POSTs the request with the appropriate >>> parameters to the action endpoint of the form. >> >> That's not exactly right. >> >> This entire attack is based on: >> >> 1. The presence of some session cookie or other user-agent state to bypass >> active authentication, and >> 2. The ability of the malicious client to make CSS calls using #1. >> >> Everything else is a red herring because the ability to automate this >> attack and make it more powerful is completely beside the point. If you >> deploy an effective CSRF protection, everything else is a non-issue. >> >> This is why the client type does not matter when it comes to not using >> CORS. The authorization server MUST NOT allow CSS calls on the authorization >> endpoint because that's the actual attack you described - using local state >> (session cookie) to make a CSS call. If the client makes direct calls to the >> authorization endpoint, it cannot impersonate the resource owner. >> >>> >> and launch it using the same HTTP framework/WebKit, simulating the >>> >> "Allow" button. >>> > >>> > This is still just a CSRF attack. >>> > >>> >>> I think you may be right. I still believe this particular style of attack >>> on the >>> authorization server is worth mentioning, be it in its own separate >>> section or >>> under the existing CSRF section (as you suggested). >> >> This is not a style of attack but techniques to enhance other exploits, in >> this case, CSRF. If you lack CSRF protection, then yes, lack of resource >> owner forced interaction will make it easier to execute. But that's just a >> tiny speed bump considering the actual exploit. >> >> I don't see any reason to include this new text based on this threat >> analysis. >> >> However, this doesn't mean this discussion wasn't useful. We did identify >> the need to explicitly discuss CSRF attacks on the authorization endpoint. >> We need to explicitly separate the two target of CSRF attacks (client, >> server) because while the solution is the same, the implementation is very >> different (due to the use of redirections in one). >> >> EHL >> >> >> >> >> >> > _______________________________________________ > 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
