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
