4

My Application structure as follows

1)API server running in api.mydomain.com

2)Frontend VUejs application running in www.mydomain.com

So i implemented authentication via httponly cookie.

But little confused with CSRF token implementation

Mysolution

1).CSRF token from the url like /getCSRF.

2) Store it in localstorage.

3) Send with every request.

But i don't think its the good way does anyone have suggestion?

shamon shamsudeen
  • 5,466
  • 17
  • 64
  • 129
  • Just don't use cookie-based authentication for a SPA. Use JWT or OAuth or your own token algorithm. No cookies - no CSRF. – Dmitry Jan 31 '18 at 09:45
  • Can you give a little more explanation?? as i understand store the auth token in httponly cookie and validate every request with token?? – shamon shamsudeen Jan 31 '18 at 09:48
  • Do you understand how the [CSRF attack](https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)) works? Do you know why you need the CSRF token? – Dmitry Jan 31 '18 at 09:55
  • As far as i know CSRF token ensure that the request is originates from our server so that other evil websites can't make request to our website – shamon shamsudeen Jan 31 '18 at 10:01
  • 2
    @Dmitry coming to your point if i change cookie based auth to token based the storage of token stills a problem the most secure way is to store it in httponly cookie but again am i vulnarable to CSRF?? because cookies are passed every request without consider the origin of the request – shamon shamsudeen Jan 31 '18 at 10:34
  • If the token expires in an hour or so (or with a sliding window) the same way as a session cookie does then I see no problem. – Dmitry Jan 31 '18 at 10:39
  • My question am i still vulnerable even if the token stored in http only cookie?? – shamon shamsudeen Jan 31 '18 at 10:41
  • 1
    Yes, all cookies are sent with every request. `httponly` part means that JavaScript has no access to it. You still will need CSRF tokens. – Dmitry Jan 31 '18 at 10:46
  • i don't thin token expiration is better method bcz whenever the token is valid i am still vulnerable to CSRF – shamon shamsudeen Jan 31 '18 at 10:49
  • If you don't use cookies you are not vulnerable to CSRF attack by definition. – Dmitry Jan 31 '18 at 10:51
  • if i don't use cookies where can i store tokens its in locastorage?? but its not a good approach by default loaclstorage is accessible via javascript so an XSS attack leads to easily exposed my auth token – shamon shamsudeen Jan 31 '18 at 10:53
  • Do you load content from untrusted sources into your SPA? If not what XSS are you talking about? – Dmitry Jan 31 '18 at 11:05
  • yes load content from untrusted sources – shamon shamsudeen Jan 31 '18 at 11:11
  • https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet – Dmitry Jan 31 '18 at 11:16

1 Answers1

4

First things first: Feel free to use session-based authentication in combination with the httpOnly (prevents your session cookie to be hijacked via XSS attack) cookie. Nothing wrong with that.

After a certain action (e.g. login), generate a CSRF token and store it in a cookie (make it accessible to JavaScript). You can HMAC the token with server secret so that attacker cannot recreate a CSRF.

Sure that CSRF will be sent as a cookie in each request, but the trick is to send it and expect it in a custom header (e.g. X-CSRF-HEADER). The final step is to check its validity.

The key idea is that attacker cannot attach custom headers while performing a CSRF attack.

Branislav Lazic
  • 14,388
  • 8
  • 60
  • 85