OAuth2 Cross Site Request Forgery, and state parameter

Question

http://tools.ietf.org/html/draft-ietf-oauth-v2-30#section-10.12 says:

The client MUST implement CSRF protection [...] typically accomplished by requiring any request sent to the redirection URI endpoint to include a value that binds the request to the user-agent's authenticated state (e.g. a hash of the session cookie [...]

It doesn't say much about the implementation, though. It only puts some light on how the CSRF works:

A CSRF attack against the client's redirection URI allows an attacker to inject their own authorization code or access token, which can result in the client using an access token associated with the attacker's protected resources rather than the victim's (e.g. save the victim's bank account information to a protected resource controlled by the attacker)

But use of the word "rather" rather makes the statement worthless.

I am thinking how to implement the "state" in GAE (using Webapp2). It would be easiest starting at how a hacker could use a CSRF against OAuth2. I found only one good article about the matter: http://blog.springsource.org/2011/11/30/10317/

Unfortunately, while this blog post is well written, there's not much info beyond OAuth2 process explained, examples don't work, and I don't know Spring. Still, I found one interesting recommendation there: server connecting to OAuth2 provider, should store "state" as a random session key (e.g. "this_is_the_random_state":"this_doesn't_matter"), not a value under static key (e.g. "state":"random_state_string")

---

My question is, what's the sane implementation of the "state".

• Should the randomly generated state be hashed or can same value be stored and sent to OAuth2 provider?
• Is there a difference here, if session back-end is secure-cookies or a server-side storage (in GAE Memcache or database)?
• Should state be stored as a key as suggested?
• Should state has validity period, or session (if there is one) lifetime is enough?

Answer 1

I will simplify this problem. Cross-Site Request Forgery and Clikjacking attacks are useful because it can force a victim's browser into performing actions against the user's will.

The mention of 10.12. Cross-Site Request Forgery and 10.13. Clickjacking in the OAuth v2 RFC have fundamentally the same concern. If an attacker can force a victim's browser into authenticating, the it is a useful step in forcing the victim's browser into performing other actions.

   in a clickjacking attack, an attacker registers a legitimate client
   and then constructs a malicious site in which it loads the
   authorization server's authorization endpoint web page in a
   transparent iframe overlaid on top of a set of dummy buttons, which
   are carefully constructed to be placed directly under important
   buttons on the authorization page.  When an end-user clicks a
   misleading visible button, the end-user is actually clicking an
   invisible button on the authorization page (such as an "Authorize"
   button).  This allows an attacker to trick a resource owner into
   granting its client access without their knowledge.

Source:10.13. Clickjacking

For example, StackOverflow uses OAuth and is vulnerable to this attack. If you visit StackOverflow and you are currently logged into your OAuth provider you will be automatically logged in to StackOverflow. Therefor an attacker could automatically login a victim by loading stackoveflow within an iframe. If StackOverflow also had a CSRF vulnerability (and it has had them!). Then an attacker could automatically authenticate a victim's browser and carry out a CSRF (Session Riding) or Clickjacking or XSS attack against StackOverflow.com in a Chained Attack.