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:nivst...@gmail.com] > Sent: Thursday, August 18, 2011 5:49 AM > To: Eran Hammer-Lahav > Cc: Torsten Lodderstedt; oauth@ietf.org > 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...@hueniverse.com> > 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: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On > >> Behalf Of Torsten Lodderstedt > >> Sent: Friday, August 12, 2011 7:56 AM > >> To: oauth@ietf.org > >> 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 > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
