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

[Niv Steingarten <[e-mail]>]

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,
to finally receive an access token/authorization code in the
redirection.


> CAPTCHA and password entry are two completely difference measures and are rarely interchangeable. CAPTCHA does nothing more than increase the likelihood that the entity on the other side is a human. Any attack prevented by CAPTCHA must be one in which automation and speed are crucial. I still don't understand what it *solves*.

CAPTCHAs are used for human testing and passwords for identity
testing, but in this case they both serve the same purpose of
decreasing the likelihood that the flow is automated.


> Two-factor authentication is good, but completely impractical for most web authorization scenario. You need to remember that the authorization page is used for both the initial grant, but also for delegated login (by far a more frequent use). An access token can be issued almost automatically if the client has been previously authorized.

You're right, sometimes there's a trade-off between better security
and user experience. I think it should eventually be up to the
implementer to choose what is right for their applications' security
requirements. I think it is in the scope of the specification to bring
this issue up for developers to consider.


> I don't understand this "family of attacks".

I don't know how to put it any differently than I already have; simply
a class of attacks (the three scenarios described in this thread are
examples thereof) in which a malicious client takes the role of both
the client and the resource owner.

-- Niv