1

I’m using an HttpOnly cookie to store authentication token client-side. To mitigate some of the risks of CSRF attacks, I’m employing the Double Submit Cookie pattern. The same token is saved client-side as a separate header with the same value, and both get sent for subsequent requests when the user is logged in.

My question: Obviously the attacker will send the HttpOnly cookie when performing a CSRF attack, but can they set a separate authorization header whose value is identical to the HttpOnly cookie, even though he can’t read the cookie’s value?

Note: I’m aware of the limitations and workarounds pertaining to DSC.

Improve this question

1 Answer 1

Reset to default
1

I think you're asking the wrong question. Here is my question for you:

What's the point in creating an HTTP-only cookie if you're also storing the cookie contents outside of the secure cookie?

The whole point of making a cookie HTTP-only is that it secures the cookie contents from theft. In the event of an XSS attack, an attacker can make requests on behalf of the user, but they can't outright steal the credentials - limiting the scope and timescale of the attack (in particular, the attacker will likely lose access as soon as the user navigates to a different page).

If you also are sending your cookie contents down to the app to store in a separate way, then the HTTP-only flag on your cookie is now pointless because in the event of an XSS attack, the attacker can steal the user's access credentials in from wherever else you are storing it, since only HTTP-only cookies provide any protection against credential theft in an XSS attack.

There are many effective methods to stop CSRF attacks. As a result, if you are considering a method that also weakens another layer of security, then the answer is, quite simply, you're doing it the wrong way.

Is there a reason you aren't considering CSRF tokens or custom headers? The former are the norm and are perfectly secure, so unless you have a compelling reason not to use them, then just do it that way. If for some reason that isn't possible for you then you can fall back on custom headers, although that isn't ideal.

Improve this answer
11
  • You are right, of course. This probably means I should be tracking two values in the backend. Are there any resources regarding the recommended expiration time for both credentials (CSRF token & cookies)?
    – zerohedge
    Oct 14, 2019 at 15:15
  • 1
    @zerohedge The recommendation on cookies varies wildly depending on your use case and needs. For CSRF tokens though there is a more clear answer. You can technically get away with creating one on login and never refreshing it until the next login. Personally though I prefer refreshing them after each use. However, they don't need to have an expiration time.
    – Conor Mancone
    Oct 14, 2019 at 15:19
  • 1
    @zerohedge security.stackexchange.com/questions/22903/…
    – Conor Mancone
    Oct 14, 2019 at 15:21
  • Yeah. That’s what my backend (Django REST) does by default - it creates a CSRF valid for one year. I’ll see what I can do to use it since it’s disabled by default once you use REST (because of the horrible advice to use LocalStorage)
    – zerohedge
    Oct 14, 2019 at 15:21
  • I’m now confused on whether what I’m doing is actually wrong after reading this: stackoverflow.com/questions/49298250/…
    – zerohedge
    Oct 14, 2019 at 15:43

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .