CODEWITHSUNDEEP
securityreverse-proxybearer-token
Ian N
Ian N

Reputation: 55

Session token in page body

Scenario: When using a cache like Varnish, JS can be used to update the page data so that user specific data is available. This requires the AJAX request to send an authentication token, which was given to the JS application at login, and stored in the browser’s session storage. On a non-varnish website the session cookie and xsrf token are available for each request, but these are not available on a varnish cached page, hence the need to retrieve it at login and store it somewhere for the duration of the session. JS cannot access the contents of the encrypted cookie, so the session authentication token needs to be passed in the header or body of the login response, so that JS can grab it, store it, and return it on subsequent requests. The whole cycle happens over https.

Questions:

  1. Is the users session now more vulnerable than using the standard session cookies in a non-Varnish environment?
  2. Is the use of session storage for storing the token a vulnerability?
  3. Is there a better solution?

Upvotes: 1

Views: 537

Answers (1)

Shiva Kishore
Shiva Kishore

Reputation: 1701

In short your setup is great.

Is the users session now more vulnerable than using the standard session cookies in a non-Varnish environment?

Nope, your implementation is better than the standard session cookies. because it is not advisable to store session data in cookies since it sends the cookie in each request even though the request request originated from different origin. this can cause XSRF vulnerability. To mitigate this you should add xsrf token to each of your request. But if you are setting xsrf token also as cookie there is a possibility of having XSRF vulnerability.

It is best to store Session data and XSRF token in session storage or local storage (depending on the usecase).

Is the use of session storage for storing the token a vulnerability?

No, as far as you do not store the token in cookie then you should be good to go.

Is there a better solution?

it depends on the use-case. for the scenario that you provided this is perfect. and it would be better if you send the session token in body of the request. like how Oauth implements it.
for authentication you can return a response as JSON data with the session token and the xsrf token for further usage.

Upvotes: 1

Related Questions