Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation)

[Eran Hammer-Lahav <[e-mail]>]

> -----Original Message-----
> From: Niv Steingarten [mailto:[e-mail]]
> Sent: Thursday, August 18, 2011 12:12 PM
> To: Eran Hammer-Lahav
> Cc: Torsten Lodderstedt; [e-mail]
> Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner
> Impersonation)
> 
> On Thu, Aug 18, 2011 at 21:17, Eran Hammer-Lahav <[e-mail]>
> wrote:
> >
> >
> >> -----Original Message-----
> >> From: Niv Steingarten [mailto:[e-mail]]
> >> Sent: Thursday, August 18, 2011 11:08 AM
> >> To: Eran Hammer-Lahav
> >> Cc: Torsten Lodderstedt; [e-mail]
> >> Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner
> >> Impersonation)
> >>
> >> On Thu, Aug 18, 2011 at 20:31, Eran Hammer-Lahav
> >> <[e-mail]>
> >> wrote:
> >> >
> >> >
> >> >> -----Original Message-----
> >> >> From: Niv Steingarten [mailto:[e-mail]]
> >> >> Sent: Thursday, August 18, 2011 10:16 AM
> >> >> To: Eran Hammer-Lahav
> >> >> Cc: Torsten Lodderstedt; [e-mail]
> >> >> 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