[OAUTH-WG] Auth Code Swap Attack

[Anthony Nadalin <[e-mail]>]

Here is an attack that Yaron, Torsten, Phil and I have documented which shows that there is a protocol flaw that needs to be corrected; the proposed text changes are also included.

Auth Code Swap Attack
This attack describes a phishing attempt where an attacker "gives" away access to a resource controlled by the attacker in order to compromise a client application.

Dramatis personae
Plaxo - An OAuth client. It asks its users to use OAuth to give Plaxo permission to access their address books in various services like Live. It uses the permissions to synch address books in remote services like Live's with the central address book kept in Plaxo.

Live - A resource server. It accepts authorization requests from clients to allow them access to protected resources. Those protected resources are address books owned by Live's users.

Gene - Gene is a user of both Plaxo and Live. Gene wants to use Plaxo to keep his address book at Live up to date.

Basil - Basil is an evil doer. His desire is to steal the contents of Live user's address books for marketing and other purposes.

Attack setup
Basil creates an account at Live.
Basil creates a website called 'Silly Fun Times'

The actual attack
1.            Basil sends spam to various victims trying to get them to come to his 'Silly Fun Times' website.
2.            Gene opens the spam mail and clicks on the link.
3.            The server running Basil's website initiates an authorization request to Live. The request uses Plaxo's redirection URI. The code running on Basil's server uses Basil's Live credentials to login to Live and to grant the authorization request. Live responds with a redirect containing an authorization code. Basil's server swallows the redirect and creates a web page containing the authorization code and sends the web page down to Gene's browser. [Note: Normally the actions in step 3 would be performed by a human at a browser but in the attack Basil has automated the process so his attack server can do everything automatically.]
4.            The web page, from 'Silly Fun Times', running on Gene's browser now completes the redirect sending Gene, using the authorization code that Live issues in response to Basil's request, to Plaxo.
5.            Gene is already logged into Plaxo so he isn't even asked anything before Plaxo accepts the redirect with the authorization code.
6.            Plaxo's server then uses the authorization code to get an access token and refresh token.
7.            Plaxo uses the access token to synchronize the address book on Basil's Live account with Gene's Plaxo server.

The outcome of step 7 is two separate attacks. One attack is that Plaxo will now push all of Gene's address book information into Basil's Live account. So Basil has now successfully stolen all of Gene's address book data. The other attack is that if Plaxo is doing bi-directional synch then Basil could put false contacts (perhaps with bad URLs to launch various types of attacks) and related information into Gene's central address book at Plaxo.

Variations:
1a. Basil could buy ads on search services like Bing and Google and use those as a way to lure people to the 'Silly Fun Times' website.
5a. Gene might not be logged into Plaxo but if 'Silly Fun Times' sets things up right it could fool Gene into thinking he is supposed to see Plaxo and so will handle the login.

There is an obvious variation of this attack for auth tokens rather than auth codes.

Pretty picture
The numbers in the picture are keyed to the steps in the use case above.

[Description: Description: Description: cid:image002.png@01CC5131.B0C50110]
Recommended Changes to draft-ietf-oauth-v2

In section 4, request options (e.g. 4.1.1) featuring "state" should change from:

state
OPTIONAL. An opaque value used by the client to maintain state between the request and callback. The authorization server includes this value when redirecting the user-agent back to the client.

to:

state
REQUIRED. An opaque value used by the client to maintain state between the request and callback. The authorization server includes this value when redirecting the user-agent back to the client. The encoded value SHOULD enable the client application to determine the user-context that was active at the time of the  request (see section 10.12). The value MUST NOT be guessable or predictable, and MUST be kept confidential.

Section 10.12 Cross-Site Request Forgery

Change to:

Cross-site request forgery (CSRF) is a web-based attack whereby HTTP requests are transmitted from the user-agent of an end-user the server trusts or has authenticated. CSRF attacks enable the attacker to intermix the attacker's security context with that of the resource owner resulting in a compromise of either the resource server or of the client application itself. In the OAuth context, such attacks allow an attacker to inject their own authorization code or access token into a client, which can result in the client using an access token associated with the attacker's account rather than the victim's. Depending on the nature of the client and the protected resources, this can have undesirable and damaging effects.

In order to prevent such attacks, the client application MUST encode a non-guessable, confidential end-user artifact and submit as the "state" parameter to authorization and access token requests to the authorization server. The client MUST keep the state value in a location accessible only by the client or the user-agent (i.e., protected by same-origin policy), for example, using a DOM variable, HTTP cookie, or HTML5 client-side storage.

The authorization server includes the value of the "state" parameter when redirecting the user-agent back to the client. Upon receiving a redirect, the client application MUST confirm that returned value of "state" corresponds to the state value of the user-agent's user session. If the end-user session represents an authenticated user-identity, the client MUST ensure that the user-identity has NOT changed.

Yaron, Torsten, Phil and Tony