3 ms·

Please Stop Using Local Storage

29 points by synergy20 6y ago

temporallobe 6y ago
I am one of the guilty parties here. I love local/session storage and I have used it frequently in web app development, and while I came to the same conclusions expressed in the article, I have come up with quite a few ways to mitigate these. First, I’ve written several private utilities that handle session/local storage in much more graceful and intelligent ways than you would by using it “raw”. Perhaps I should publish one of these one day, but they basically do the following: 1) Store everything in base-64 encoded JSON so you can interact with the storage API using regular JavaScript objects. 2) Use ambiguous keys, and 3) implement async support. I have used this with great success to do things like caching large API responses as well as store non-sensitive user data. On the other hand, even though the information is encoded, it could easily be decoded, so I would not ever store PII data this way. But even if you wanted to store sensitive data, it wouldn’t be a far stretch to implement some kind of encryption. Sorry for the awful formatting, I am writing this in mobile.
- SahAssar 6y ago
  > implement async support How can that be possible? The underlying API is blocking and the localStorage interface is not available in web-workers. > But even if you wanted to store sensitive data, it wouldn’t be a far stretch to implement some kind of encryption. Since any other JS runs in the same environment and thread with access to the same resources how would encryption help with the issues in the article?
  - Anunayj 6y ago
    Encrypting all sensitive information that gets stored with a public key received from server. That saves bandwidth compared to cookies, any rouge plugins/javascript won't be able to decrypt the data. (and the client too won't be able to, kinda a bummer). The server will be able to decrypt it obviously since it should have the corresponding private key.
    - SahAssar 6y ago
      Any other JS could still read the encrypted data and exfiltrate it, and use it in the same way as the "real" client since they can both see and use the same data. What you are describing is very similar to how JWT already works (at least in the JWE variant which is encrypted, not only signed). If you want to save bandwidth the easiest way is to have a separate subdomain for API requests or asset requests so you don't send the cookie with asset requests. I don't think that is worth it for 99% of sites though.
brundolf 6y ago
What it all comes down to is: > If an attacker can run JavaScript on your website, they can retrieve all the data you’ve stored in local storage and send it off to their own domain. This means anything sensitive you’ve got in local storage (like a user’s session data) can be compromised. Buddy, if malicious JS gets to run on your domain then it's game-over for security anyway. It can read and modify all of your HTML, read and modify all of your cookies, check the state of all your password fields. Change your passwords by editing and submitting forms. I hardly see what's special about localStorage here. It's domain-scoped; that's pretty much the best any web feature can do.
- SahAssar 6y ago
  The article addresses part of this, if you set the cookie as httpOnly then JS cannot read the cookie. So it is harder for XSS to lead to token exfiltration if using a properly configured cookie than it is with localStorage.

29 points by synergy20 6y ago

I am one of the guilty parties here. I love local/session storage and I have used it frequently in web app development, and while I came to the same conclusions expressed in the article, I have come up with quite a few ways to mitigate these. First, I’ve written several private utilities that handle session/local storage in much more graceful and intelligent ways than you would by using it “raw”. Perhaps I should publish one of these one day, but they basically do the following: 1) Store everything in base-64 encoded JSON so you can interact with the storage API using regular JavaScript objects. 2) Use ambiguous keys, and 3) implement async support. I have used this with great success to do things like caching large API responses as well as store non-sensitive user data. On the other hand, even though the information is encoded, it could easily be decoded, so I would not ever store PII data this way. But even if you wanted to store sensitive data, it wouldn’t be a far stretch to implement some kind of encryption. Sorry for the awful formatting, I am writing this in mobile.

SahAssar 6y ago
> implement async support How can that be possible? The underlying API is blocking and the localStorage interface is not available in web-workers. > But even if you wanted to store sensitive data, it wouldn’t be a far stretch to implement some kind of encryption. Since any other JS runs in the same environment and thread with access to the same resources how would encryption help with the issues in the article?
- Anunayj 6y ago
  Encrypting all sensitive information that gets stored with a public key received from server. That saves bandwidth compared to cookies, any rouge plugins/javascript won't be able to decrypt the data. (and the client too won't be able to, kinda a bummer). The server will be able to decrypt it obviously since it should have the corresponding private key.
  - SahAssar 6y ago
    Any other JS could still read the encrypted data and exfiltrate it, and use it in the same way as the "real" client since they can both see and use the same data. What you are describing is very similar to how JWT already works (at least in the JWE variant which is encrypted, not only signed). If you want to save bandwidth the easiest way is to have a separate subdomain for API requests or asset requests so you don't send the cookie with asset requests. I don't think that is worth it for 99% of sites though.

brundolf 6y ago

What it all comes down to is: > If an attacker can run JavaScript on your website, they can retrieve all the data you’ve stored in local storage and send it off to their own domain. This means anything sensitive you’ve got in local storage (like a user’s session data) can be compromised. Buddy, if malicious JS gets to run on your domain then it's game-over for security anyway. It can read and modify all of your HTML, read and modify all of your cookies, check the state of all your password fields. Change your passwords by editing and submitting forms. I hardly see what's special about localStorage here. It's domain-scoped; that's pretty much the best any web feature can do.

SahAssar 6y ago
The article addresses part of this, if you set the cookie as httpOnly then JS cannot read the cookie. So it is harder for XSS to lead to token exfiltration if using a properly configured cookie than it is with localStorage.