Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

This answer describes a situation where CSRF can be used to trick an end user to enter a credit card into another person's Paypal account. It also highlights the fact that state-changing GET requests are just as bad a POST requests.

This is pretty simple to understand when dealing with a single forms based authentication. But if we introduce an authentication system based on GETs and POSTs to different domains that we don't "own", I'm not sure how to prevent CSRF in that situation.

If I were to extend this to OpenID, does this mean that a user could inject their OpenID credentials into my session?

What is the right way to address this problem?

share|improve this question

1 Answer 1

up vote 2 down vote accepted

I'll answer my own question since I haven't seen this practice be encouraged in various SDKs and code samples. Here is my theory:

Upon clicking the "sign in" button on the Relying Party (RP), two things should happen:

  1. Write a random value to a SECURE HTTPOnly domain cookie

  2. Then have the IDP redirect back to https://www.host.com/account/signin?csrf=myrandom where "myrandom" equals the value within the cookie.

  3. When the OpenID process signs you in, then it will POST to the above URL, you can then grab the CSRF string, and compare that to the cookie.

Let me know if you see any flaws in this approach

share|improve this answer
    
"a SECURE HTTPOnly domain cookie" What is the point of the "secure" part? –  curiousguy Nov 9 '11 at 21:31
    
@curiousguy it is an optional feature for this specific scenario, but in general, all pages after initial authentication should be HTTPS only. If I'm following that best practice I don't see any reason to explicitly omit it. –  makerofthings7 Nov 9 '11 at 22:38
    
Then why is the www.host.com site not in HTTPS also? –  curiousguy Nov 9 '11 at 22:52
    
@curiousguy Wow! I just fixed that horrible typo. Thanks for the catch –  makerofthings7 Nov 9 '11 at 23:13
1  
@makerofthings Your approach is correct, see e.g. this white paper seclab.stanford.edu/websec/csrf/csrf.pdf where authors propose just this for OpenID CSRF protection. –  Krzysztof Kotowicz Nov 10 '11 at 8:05

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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