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

[Niv Steingarten <[e-mail]>]

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 and launch it
using the same HTTP framework/WebKit, simulating the "Allow" button.

>
> [1] http://www.ibras.dk/montypython/episode34.htm
>

+1 for more Monty Python references.

-- Niv