14

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?

Improve this question
4
  • 1
    Related: stackoverflow.com/questions/4201239/… Commented Mar 31, 2016 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. Commented Mar 31, 2016 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 Commented Mar 31, 2016 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. Commented Mar 31, 2016 at 23:15

1 Answer 1

Reset to default
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)
Improve this answer
1
  • 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? Commented Apr 15, 2016 at 19:40

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.