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

[Niv Steingarten <[e-mail]>]

On Thu, Aug 18, 2011 at 22:19, Eran Hammer-Lahav <[e-mail]> wrote:
>
>
>> -----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.
>

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