2

Google's "Using OAuth 2.0 for Client-side Application" article at https://developers.google.com/accounts/docs/OAuth2UserAgent states that the client MUST validate all access tokens to verify that it was the intended recipient of the access token, in order to avoid being vulnerable to the confused deputy problem.

I believe proper use of the OAuth "state" parameter can also prevent this vulnerability. "Proper use" being cryptographically and securely binding the state parameter value to the current browser session. This can be done by hashing a combination of the session ID and a nonce (I'm not sure if including the nonce is necessary).

I have two questions:

My primary question is: Can proper use of the OAuth "state" parameter, along with using TLS with server certificate validation, mitigate the confused deputy problem, without validating the audience of the access token, for some definition of "proper use" that mitigates cross site request forgery?

My secondary question is: Is cross site request forgery a type of confused deputy problem? And if "yes", then isn't the answer to my primary question also "yes" necessarily?

5

This is the problem you are trying to prevent by validating the token:

As a simplified example, imagine there are two apps: (1) FileStore, a legitimate file storage app, and (2) EvilApp. Both apps use Google's authentication process for client-side apps. Alice is an innocent end user, and her Google user ID is XYZ.

  1. Alice signs into FileStore using Google.
  2. After the auth process, FileStore creates an account for Alice and associates it with Google user ID XYZ.
  3. Alice uploads some files to her FileStore account. So far everything is fine.
  4. Later, Alice signs into EvilApp, which offers games that look kind of fun.
  5. As a result, EvilApp gains an access token that is associated with Google user ID XYZ.
  6. The owner of EvilApp can now construct the redirect URI for FileStore, inserting the access token it was issued for Alice's Google account.
  7. The attacker connects to FileStore, which will take the access token and check with Google to see what user it is for. Google will say that it is user XYZ.
  8. FileStore will give the attacker access to Alice's files because the attacker has an access token for Google user XYZ.

FileStore's mistake was not verifying with Google that the access token it was given was truly issued to FileStore; the token was really issued to EvilApp.


I believe proper use of the OAuth "state" parameter can also prevent this vulnerability. "Proper use" being cryptographically and securely binding the state parameter value to the current browser session. This can be done by hashing a combination of the session ID and a nonce (I'm not sure if including the nonce is necessary).

I have two questions:

My primary question is: Can proper use of the OAuth "state" parameter, along with using TLS with server certificate validation, mitigate the confused deputy problem, without validating the audience of the access token, for some definition of "proper use" that mitigates cross site request forgery?

No, you need to validate audience, not state, as per this article:

Some people believe that using the state parameter in OAuth protects against token substitution. The only binding a browser cookie to state protects against is Cross Site Scripting [think they mean CSRF]. In the attack I am proposing the client generates a legitimate request to a bad user agent that captures it and provides a response that includes state unchanged from the request. Their is nothing in the OAuth client-side flow that proves the issuer you sent the request to through the browser ever received it and is the one responding. Only the access_token parameter is generated by the Authorization server, all the other parameters are dropped or echoed back. The client has no way to tell who the authorization server thought it was issuing that access_token to.

Imagine that an attacker clicks a button on your app in order to give it access to her Google account in order to validate her identity (i.e. authentication). However, instead of following the redirect she instead grabs the state value and stores it somewhere. She then gets a token from her malicious app, and then replays it to your redirect_uri, substituting in the state that she has captured herself.

Your app will then authenticate the user as the one that gave access to her malicious app. Validating the audience instead is the secure approach because this is checked by Google when you validate the token server-side.

My secondary question is: Is cross site request forgery a type of confused deputy problem? And if "yes", then isn't the answer to my primary question also "yes" necessarily?

Yes, CSRF is another type of confused deputy problem.

state can be used for this, as this would validate that a malicious party has not enticed a user to their site and redirected them to your endpoint to authorise the attacker's account against your app. For example, if your app copies content from itself and syncs with a Google account, the attacker could redirect the user to your endpoint, you would then check server-side that the token matches, and then start syncing your content to the Google account - as this is the attacker's account, they have now gained access to your user's files. Hence why checking the state is a good mitigation against this.

  • I agree with your response to my secondary question- you're saying that once an access token is bound to a session cookie, the app would need CSRF protection against a malicious site taking advantage of the session cookie. – E Anwar Reddick Feb 12 '15 at 3:47
  • However, in regard to your response to my primary question, I don't see how the OAuth state parameter does not guard against a CSRF attack that uses an OAuth authorization response. Can you please elaborate on this? Can't proper use of the state parameter prevent a malicious site from redirecting Alice's browser to the app with a spoofed OAuth authorization response with a malicious access token? – E Anwar Reddick Feb 12 '15 at 3:51
  • I'm saying that CSRF is not the threat here - that is another type of confused deputy where the browser is the confused deputy. Here the app is the confused deputy. There is no need to redirect Alice's browser with a spoofed response - the attacker can access the good app from their own browser using the access token they have as the good app is not verifying it properly. – SilverlightFox Feb 12 '15 at 11:24
  • With a little effort, state can be captured and replayed, because state is exposed through the initial redirect Location header. It is intended to prevent CSRF and it does, but it does prevent other attacks. – Jacco Aug 17 '16 at 17:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.