Re: [OAUTH-WG] Auth Code Swap Attack

[John Kemp <[e-mail]>]

Hi Tony (et al),

On Aug 12, 2011, at 3:06 PM, Anthony Nadalin wrote:

[…]

> 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.

And why does Live believe that this is a valid authorization request? Has Basil forged a request to Live as if it came from Plaxo (Basil has at least the client_id for Plaxo's client)? Shouldn't Live protect its authorization endpoint by requiring some authentication of the requester?

> 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.

Although Plaxo never had a request initiated from anyone (Gene, or Basil) to sync Gene's contacts with Live? And shouldn't Plaxo ask Gene for explicit authorization before syncing his contacts to Live, regardless of whether he is already authenticated? 

Regards,

- John

>  
> 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.
>  
> <image001.png>
> 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
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth