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

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

Thanks. You have a typo in #1 (the authorization endpoint belongs to the authorization server, not client).

This is a textbook CSRF attack on the authorization endpoint.

The right solution is for the authorization server to set or maintain a session cookie (or other same-origin-protected state in the browser) in #1 as well as some hidden CSRF token in the Accept form and not allow CORS calls to that endpoint. I don't see how the measures proposed in the new section are relevant here.

EHL


> -----Original Message-----
> From: Niv Steingarten [mailto:[e-mail]]
> Sent: Thursday, August 18, 2011 5:49 AM
> To: Eran Hammer-Lahav
> Cc: Torsten Lodderstedt; [e-mail]
> Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner
> Impersonation)
> 
> Here are two very simple examples. They are very naive ones, but get the
> point across and I would not be suprised if they could be found in the
> wild:
> 
> Say a client has its authorization endpoint at
> 
>   (1) http://www.domain.com/auth.php
> 
> A client requests access to protected resources by redirecting the user-agent
> to:
> 
>   (2)
> http://www.domain.com/auth.php?response_type=code&client_id=1234&
>       redirect_uri=SOMEURI&scope=SOMESCOPE
> 
> One possible design choice for the developer, if a bad one, is to have the
> 'Allow' button point to:
> 
>   (3) http://www.domain.com/auth.php?[..previous query
> params..]&allow=1
> 
> In this case, a malicious client who knows the structure of this auth flow, can
> simply skip (2) and redirect the user-agent to (3) in order to gain access to the
> protected resources.
> 
> Another possible design choice for the developer (again, a very bad
> one) would be to issue some kind of session cookie after (2) in order to keep
> a state. Then, the 'Allow' button could possibly point to:
> 
>   (4) http://www.domain.com/allow.php
> 
> without any parameters (since the state is maintained by a cookie).
> 
> Here, an attacker could launch a request to (2) just to issue the state cookie,
> and immediately redirect the user-agent to (4) in order to gain access to the
> protected resources.
> 
> These are two very naive scenarios which can be averted using a nonce for
> example (+ better design choices, for that matter).
> 
> In non-user-agent based clients, a client might also be able to actually scrape
> the contents of the authorization HTML page, and simulate the click
> programmatically. In this case a nonce would be useless, but a CAPTCHA or a
> PIN code/password would solve the problem.
> 
> -- Niv
> 
> 
> 
> On Thu, Aug 18, 2011 at 08:58, Eran Hammer-Lahav <[e-mail]>
> wrote:
> > I've read the thread leading to this, and the proposed text and I do not
> understand the attack. Can you provide a step-by-step scenario of how an
> attacker gains access?
> >
> > Also, it is unlikely that any major provider is going to require CAPCHA as
> part of the authorization flow. This is especially true in the case of using
> OAuth for login which has to be practically transparent (one click). I would
> hate to recommend a solution that no one is going to take seriously.
> >
> > I'm keeping this proposed text out until we resolve this questions.
> >
> > EHL
> >
> >
> >> -----Original Message-----
> >> From: [e-mail] [mailto:[e-mail]] On
> >> Behalf Of Torsten Lodderstedt
> >> Sent: Friday, August 12, 2011 7:56 AM
> >> To: [e-mail]
> >> Subject: [OAUTH-WG] Draft 20 last call comment (Resource Owner
> >> Impersonation)
> >>
> >> Hi all,
> >>
> >> I think the impersonation issue as raised by Niv on the list should
> >> be covered by the core spec. It directly aims at the trustworthiness
> >> of the user consent, which in my opinion is one of the core
> >> principles of OAuth. I therefore suggest to add a description to section 10.
> >>
> >> Please find below the text Niv and I prepared. In comparison to
> >> Niv's original proposal, it covers resource owner impersonation for all
> client categories.
> >>
> >> regards,
> >> Torsten.
> >>
> >> proposed text:
> >>
> >> 10.<to be determined> Resource Owner Impersonation
> >>
> >> When a client requests access to protected resources, the
> >> authorization flow normally involves the resource owner's explicit
> >> response to the access request, either granting or denying access to the
> protected resources.
> >>
> >> A malicious client can exploit knowledge of the structure of this
> >> flow in order to gain authorization without the resource owner's
> >> consent, by transmitting the necessary requests programmatically, and
> >> simulating the flow against the authorization server. An
> >> suthorization server will be vulnerable to this threat, if it uses
> >> non-interactive authentication mechanisms or split the authorization flow
> across multiple pages.
> >>
> >> It is RECOMMENDED that the authorization server takes measures to
> >> ensure that the authorization flow cannot be simulated.
> >> Attacks performed by scripts running within a trusted user-agent can
> >> be detected by verifying the source of the request using HTTP referrer
> headers.
> >> In order to prevent such an attack, the authorization server may
> >> force a user interaction based on non-predictable input values as
> >> part of the user consent approval.
> >>
> >> The authorization server could combine password authentication and
> >> user consent in a single form, make use of CAPTCHAs or one-time secrets.
> >>
> >> Alternatively, the authorization server could notify the resource
> >> owner of any approval by appropriate means, e.g. text message or e-Mail.
> >>
> >> _______________________________________________
> >> OAuth mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/oauth
> > _______________________________________________
> > OAuth mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/oauth
> >