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 10:16 AM
> To: Eran Hammer-Lahav
> Cc: Torsten Lodderstedt; [e-mail]
> Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner
> Impersonation)
> 
> (thanks for the typo correction)
> 
> Yes, the example I provided is a very lightweight one which does take the
> form of CSRF, but it is only the simplest example of a family of automated
> authorization flow attacks. Indeed, a nonce (or hidden token, both serve the
> same purpose in this case) would be enough here.

Great. So we need to add explicit text about preventing CSRF attacks at the authorization endpoint.

> If the client is not user-agent based, a full-fledged forgery of the whole
> process is possible, one in which CORS and sandboxes have no meaning. In a
> native client, unless some kind of human test is performed, the whole flow
> could be spoofed.

Can you provide another example with the same level of detail as you provided below?

> A CAPTCHA and/or password entry are not bullet-proof,
> but they provide a steep obstacle for the attacker.

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*.

> Another option would be,
> for example, to email the resource owner an OTP, with the following
> message "The application [...] requests access to [...]. Please use the number
> XXXX to allow it access etc..." (similar to Google's and Facebook's two-step
> sign-in).

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.

> The first attack described in my previous message takes the form of CSRF,
> while the above one may be bypassed by an attacker with the help of some
> sort of clickjacking or similar. Eventually this threat description is for a family
> of attacks which mimic the behavior of the resource owner in order to gain
> access to protected resources, and some possible countermeasures.

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

EHL