15

I have a front/back applications that needs to be logged in to be used. When I log in (by means of the front-end app sending a request to the back end), what I do is not sending a cookie, but a JSON with a token in it. The latter will be stored by the front end app in a sessionstorage and each time it will interact with the back end it will send a request along with the token stored in the sessionstorage. The back end will verify the validity of the token.

Do you think this solution is CSRF safe? Do you see any other vulnerabilities I'm not considering/ignoring?

Robert Harvey
  • 198,589
  • 55
  • 464
  • 673
Bertuz
  • 417
  • 4
  • 10
  • 1
    Related: http://stackoverflow.com/questions/4201239/in-html5-is-the-localstorage-object-isolated-per-page-domain – Gort the Robot Mar 31 '16 at 22:31
  • 1
    Do you mean sending a one time generated token in every request ? Or it will updated too in every request ? The CSRF approach creating a new token which is a specific to a form/page in every request by backend. – FZE Mar 31 '16 at 22:56
  • 1
    One time generated would be preferred for a bunch of reasons I've omitted (this should be running on machine with very little resources and avoiding updating data on the DB would be preferrable). I would like to highlight the fact that the token I'm using is for authentication, not a CSRF-token – Bertuz Mar 31 '16 at 22:59
  • 1
    In fact local storage is accessible from the browser what you save on it client could read from it. I could suggest an approach don't make a direct request to your API from javascript. Place a middleware backend script which can make the request to the API adding `x-access-token` etc. And securing JS to middle backend it could be CORS and (timestamp + userIp + endpoint & request details) by hashing and you can use https here, and in middle backend application you can use session to write this things to diferantiate request from each other. – FZE Mar 31 '16 at 23:15

1 Answers1

12

It's certainly safer than using a cookie when it comes to CSRF, but it is less safe when it comes to XSS, because session storage can be read from javascript, while http-only cookies cannot.
So it depends on how confident you are about your protection against XSS.

If you do go for this approach, I would suggest using the Authorization header with the Bearer scheme. 

Authorization: Bearer <token>

Other things to keep in mind:

  • Session storage isn't shared between tabs.
  • You can't use this method for images that require authentication. For those you could still use a cookie (just make sure you ignore the cookie for all other endpoints and possibly limit the path of the cookie to a path under which only images are found)
Bart van Wissen
  • 176
  • 1
  • 2
  • 1
    Well answered. What about sending an http-only cookie along with a random string that will be stored into the localstorage? The client should send the cookie along with the string and they must match. In case of XSS attack, the token can be stolen, but each five minutes or so I'll send a renew request of my session, where a new random string will be sent. That way any attacker will have a potential slot of 5 minutes to get the string and try to get a CSRF attack with that. What do you think? – Bertuz Apr 15 '16 at 19:40