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
