(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.
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. A CAPTCHA and/or password entry are not bullet-proof, but they provide a steep obstacle for the attacker. 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). 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. -- Niv On Thu, Aug 18, 2011 at 19:23, Eran Hammer-Lahav <e...@hueniverse.com> wrote: > 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
