> -----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. > and launch it using the same HTTP framework/WebKit, > simulating the "Allow" button. This is still just a CSRF attack. In order to automate the approval action, they attacker has to get the user-agent (embedded or not) to make a cross site request which will include some session state (cookies or otherwise). If the authorization page is CSRF protected, they attacker will not be able to construct such a link. The nature of the client does not matter. In either case, the client has to gain access somehow to the authorization server state stored in the browser. EHL _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
