4 ms·

The big issue using localStorage for authentication token storage is that values are accessible by any JS from the same origin as the JS that sets the value. Ex

The big issue using localStorage for authentication token storage is that values are accessible by any JS from the same origin as the JS that sets the value. Example: I bundle my JS and it's dependencies into a single file (bundle.js) using webpack. One of the dependencies in the bundle has malicious JS that sends values in localStorage to a remote server, or uses the authentication token to make requests impersonating the user.

mderazon 10y ago
Isn't that true for cookies as well?
- jerf 10y ago
  No, you can set cookies to HTTP only, so Javascript can't access them. JS injected into a domain can do something with your permissions for that domain by making more requests to the target domain that have the cookie attached, but at the moment that's basically how the Web security model works, so that is in some sense not a hole. But the injected JS can't steal the cookie and send the contents somewhere else.
  - jondubois 10y ago
    Why would an XSS attacker need to steal a temporary session ID from a cookie (which will probably expire soon), if they can just highjack the session right there on the spot from the user's own browser?
    - drinchev 10y ago
      Because an actor might save the session to his/her server for reuse from his own machine anytime he/she wants ( spy purposes ). Sessions usually implement `touch` functionality, which will extend the session every time a request with it has been made.
      - jondubois 10y ago
        Not exactly 'anytime' because the session will expire as soon as the user logs out. Even if the user doesn't log out, the session will typically timeout on its own anyway (at least if the auth is implemented correctly).
deleted 10y ago
[deleted]
admax88q 10y ago
If you're shipping malicious JS on your origin, you're fucked anyways.
- jondubois 10y ago
  Exactly, they can still make requests to your back end by hijacking your session with your cookie; even if you use the httpOnly flag. The only advantage of the cookie (with httpOnly) in this scenario is that the malicious code can't access your session ID and use it for later (but they can still hijack the session in-place without knowing what your session id is)... Since sessions expire anyway, there is a sense of urgency; because of this, an effective XSS attack would typically be carried out in-place on the page (while the session is active). So in practice, there is very little added security value in the cookie approach. In my opinion, XSS mitigation is the last barrier of defence.

mderazon 10y ago

Isn't that true for cookies as well?

jerf 10y ago
No, you can set cookies to HTTP only, so Javascript can't access them. JS injected into a domain can do something with your permissions for that domain by making more requests to the target domain that have the cookie attached, but at the moment that's basically how the Web security model works, so that is in some sense not a hole. But the injected JS can't steal the cookie and send the contents somewhere else.
- jondubois 10y ago
  Why would an XSS attacker need to steal a temporary session ID from a cookie (which will probably expire soon), if they can just highjack the session right there on the spot from the user's own browser?
  - drinchev 10y ago
    Because an actor might save the session to his/her server for reuse from his own machine anytime he/she wants ( spy purposes ). Sessions usually implement `touch` functionality, which will extend the session every time a request with it has been made.
    - jondubois 10y ago
      Not exactly 'anytime' because the session will expire as soon as the user logs out. Even if the user doesn't log out, the session will typically timeout on its own anyway (at least if the auth is implemented correctly).

deleted 10y ago

[deleted]

admax88q 10y ago

If you're shipping malicious JS on your origin, you're fucked anyways.

jondubois 10y ago
Exactly, they can still make requests to your back end by hijacking your session with your cookie; even if you use the httpOnly flag. The only advantage of the cookie (with httpOnly) in this scenario is that the malicious code can't access your session ID and use it for later (but they can still hijack the session in-place without knowing what your session id is)... Since sessions expire anyway, there is a sense of urgency; because of this, an effective XSS attack would typically be carried out in-place on the page (while the session is active). So in practice, there is very little added security value in the cookie approach. In my opinion, XSS mitigation is the last barrier of defence.