3

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?

Community
  • 1
makerofthings7
  • 50,090
  • 54
  • 250
  • 536

1 Answers1

2

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

makerofthings7
  • 50,090
  • 54
  • 250
  • 536