> -----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. EHL [1] http://www.ibras.dk/montypython/episode34.htm _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
