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". 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. >> 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). -- Niv _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
