To reiterate Berry's earlier point, we are not going to cover everything in the v2 spec. We need to agree on new language for the CSRF section, and add the potential attacks on both endpoints. But beyond that, it will probably be best to add it to the threat model document - but I will leave that up to the editors of that document.
EHL From: William J. Mills [mailto:wmi...@yahoo-inc.com] Sent: Thursday, August 18, 2011 9:21 PM To: Niv Steingarten Cc: Eran Hammer-Lahav; oauth@ietf.org Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) While I agree in principal, I think there are real world use cases that make this more complicated. If, for example, a user has previously approved access to a particular endpoint then we might be willing to re-issue credentials without user interaction. I don't know how we capture this in the right way in the spec. ________________________________ From: Niv Steingarten <nivst...@gmail.com<mailto:nivst...@gmail.com>> To: William J. Mills <wmi...@yahoo-inc.com<mailto:wmi...@yahoo-inc.com>> Cc: Eran Hammer-Lahav <e...@hueniverse.com<mailto:e...@hueniverse.com>>; "oauth@ietf.org<mailto:oauth@ietf.org>" <oauth@ietf.org<mailto:oauth@ietf.org>> Sent: Thursday, August 18, 2011 6:06 PM Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) 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<mailto:wmi...@yahoo-inc.com>> wrote: > I proposed text that I think is more complete in a previous message... > ________________________________ > From: Niv Steingarten <nivst...@gmail.com<mailto:nivst...@gmail.com>> > To: Eran Hammer-Lahav <e...@hueniverse.com<mailto:e...@hueniverse.com>> > Cc: "oauth@ietf.org<mailto:oauth@ietf.org>" > <oauth@ietf.org<mailto: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<mailto:e...@hueniverse.com>> > wrote: >> >> >>> -----Original Message----- >>> From: Niv Steingarten [mailto:nivst...@gmail.com<mailto:nivst...@gmail.com>] >>> Sent: Thursday, August 18, 2011 1:04 PM >>> To: Eran Hammer-Lahav >>> Cc: Torsten Lodderstedt; oauth@ietf.org<mailto: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<mailto:e...@hueniverse.com>> >>> wrote: >>> > >>> > >>> >> -----Original Message----- >>> >> From: Niv Steingarten >>> >> [mailto:nivst...@gmail.com<mailto:nivst...@gmail.com>] >>> >> Sent: Thursday, August 18, 2011 12:12 PM >>> >> To: Eran Hammer-Lahav >>> >> Cc: Torsten Lodderstedt; oauth@ietf.org<mailto: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<mailto:e...@hueniverse.com>> >>> >> wrote: >>> >> > >>> >> > >>> >> >> -----Original Message----- >>> >> >> From: Niv Steingarten >>> >> >> [mailto:nivst...@gmail.com<mailto:nivst...@gmail.com>] >>> >> >> Sent: Thursday, August 18, 2011 11:08 AM >>> >> >> To: Eran Hammer-Lahav >>> >> >> Cc: Torsten Lodderstedt; oauth@ietf.org<mailto: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<mailto:e...@hueniverse.com>> >>> >> >> wrote: >>> >> >> > >>> >> >> > >>> >> >> >> -----Original Message----- >>> >> >> >> From: Niv Steingarten >>> >> >> >> [mailto:nivst...@gmail.com<mailto:nivst...@gmail.com>] >>> >> >> >> Sent: Thursday, August 18, 2011 10:16 AM >>> >> >> >> To: Eran Hammer-Lahav >>> >> >> >> Cc: Torsten Lodderstedt; oauth@ietf.org<mailto: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<mailto:OAuth@ietf.org> > https://www.ietf.org/mailman/listinfo/oauth > > >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
