4

I have a two part question here.

I have a javascript webapp accessing privileged REST endpoints. I would like to protect against CSRF.

Currently, I have a login system built which returns a login cookie containing an encrypted payload (encrypt-then-MAC). I am reasonably sure the cookie contents cannot be tampered with or forged without my knowledge.

I know that using said cookie to protect my endpoints is vulnerable to CSRF, since the cookie is automatically submitted by the browser with any request. I also believe that the Double Submit Cookie pattern is discouraged because it requires setting the cookie HTTPOnly value to False, which elevates the risk of certain attacks.

What I would like to do is set the auth cookie (used for persisting logins over the medium term) to HTTPOnly and Secure. Then, I would like the javascript client to make an XHR GET request to a token endpoint where the cookie can be validated and a short-term token (which contains a handle pointing at information I have stashed in my DB) can be issued directly back to the client, without User Agent redirection. The javascript client would then use the short-term token to authorize calls to my REST endpoints.

My first question is, are there any obvious flaws with this flow? It seems like a reasonable adaptation of the Synchronizer Token Pattern for REST, but I would like to know if there are serious flaws or if there are other best practices around the procedure.

I have considered implementing the OAuth 2.0 Implicit Grant flow but I would like the auth cookie to be present so I can persist logins for a moderate amount of time.

The second question is: will the HTTPOnly cookie be submitted to the token endpoint by the browser with my XHR if I set withCredentials=True? I know HTTPOnly restricts the ability of the javascript to read the cookie, but will the cookie tag along in the request, invisibly to the client?

I have scoured google for the answer, and my google-fu has failed me. All I could find were numerous articles about reading HTTPOnly cookies, but not submitting them.

Thanks in advance for any help or advice!

  • Have you tried F12 developer tools to answer this question? Have you tried Fiddler? – Ben Mar 14 '14 at 10:56
  • Thanks for the pointer to fiddler- that looks extremely useful. In hindsight I should have tried myself first, although I am a bit wary of that in general because of the seemingly wide range of security implementations between browsers.In the absence of any standards-driven authoritative answer though I'll gladly do my own research. Thanks! – Hao Cheng Mar 14 '14 at 20:07
3

I also believe that the Double Submit Cookie pattern is discouraged because it requires setting the cookie HTTPOnly value to False

It doesn't require setting HTTPOnly to false. This is only if you have some JavaScript code that will set the hidden form field value to the same as the cookie. It is possible to do this without JavaScript by simply outputting the cookie value to the page server side (correctly encoding it of course to avoid XSS).

My first question is, are there any obvious flaws with this flow?

This seems fine because the GET request cannot be read by an attacker due to the Same Origin Policy. However, if your information is highly secure it may be a good idea to guard against JSON Hijacking. This hasn't been an issue for a long time (think Firefox 3) but in case any flaws are reintroduced into any browsers you could take basic steps to protect your site at little cost. For example, changing this to a POST and adding an unparsable cruft to the response. This goes against REST principles somewhat, but that is something you'll have to weigh up for yourself.

The second question is: will the HTTPOnly cookie be submitted to the token endpoint by the browser with my XHR if I set withCredentials=True?

Yes it will. HTTPOnly protects from JavaScript itself on the client, it doesn't affect HTTP requests.

1

Yes, they are submitted. See the W3C spec.

HTTPOnly is intended to mitigate attacks like XSS, but if an attacker has an XSS in your site, they don't need a CSRF. Have you considered the Encrypted Token Pattern?

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.