from Hacker News

Web Storage: the lesser evil for session tokens

by kkl on 5/31/16, 2:20 PM with 69 comments

• by tptacek on 5/31/16, 6:45 PM

  I'm worried that people are confusing what Kettle is saying in this post.

  He's not saying that XSS protections don't matter because attackers "prefer" CSRF over XSS. They do not.

  What he's saying is that pages that are vulnerable to XSS attacks --- or, properly: pages that are vulnerable to Javascript injection and DOM corruption --- open up a wide vista of exploits, and "stealing session tokens" is just the most naive of them.

  Many of the more sophisticated exploits for Javascript injection resemble CSRF. But I think it's a little confusing to overload the term that way: Javascript-injectors have more latitude than conventional "blind" CSRF attackers do.

  Long story short: once you've lost control of the Javascript on a page in your same-origin, you're almost always toast. Attackers can hijack sessions. That they don't store and retain the token is irrelevant; the token is just an artifact.

  I don't know anybody who works full-time in software security who thinks HttpOnly is a meaningful defense, but, if you're out there, chime in and make a case for it. :)

• by avolcano on 5/31/16, 5:15 PM

  It's funny, I got started with web development relatively recently (2012 or so) and immediately started working on single-page/client-side applications, so I used localStorage from the start. It seemed easy enough to make a little Ajax wrapper for all my requests to tack the authentication token on (whether as a URL param, form data, or header data).

  Imagine my surprise when I later learned how cookie storage worked! There was a brief moment of "oh, I guess not having to manually append this to my requests would be nice," only to read about CSRFs and other horrors cookies enabled.

  Since then, I've fixed multiple existing CSRF exploits in production (or near-production) applications, and continued to avoid cookies wherever possible.

• by zoomzoom on 5/31/16, 5:24 PM

  The overall gist here seems to be that XSS is not anything to worry about because if there was an exploit the attacker will always choose CSRF. However, there are well-understood and proven mitigation strategies for almost all versions of CSRF attacks. For XSS you are reliant on a CDN or your own code review of your hosted JS to prevent all XSS. I'm not willing to bet I'll never make a mistake like that. An XSS can expose a lot of users very quickly in that scenario, and the mitigating factor usually offered is some time-expiring attribute of the tokens stored locally, but for usability reasons such expiration is usually long enough that an attacker will have plenty of time to use the tokens. Http-only secure cookies provide strong mitigation here that covers more scenarios.

  In general, it's annoying because local/session storage are so close to being ready for prime-time, and as outlined here there are various advantages. But the XSS mitigations are too important to abandon if you really want the most security available, IMO.

• by dcosson on 5/31/16, 7:18 PM

  These are all good points, but ultimately it seems like a well-configured cookie-based storage is equally secure as a similarly well-configured web storage session. There are more hacks required with cookies, but you hopefully only have to configure them in one place and there are libraries to help with the tricky parts like CSRF mitigation.

  OTOH, there are some usability issues with web storage. Mobile safari in private mode (which can be a not-insignificant percentage of iOS traffic) doesn't support localstorage. Also, if you have any server-rendered pages, say, you have both a single-page web app and some admin pages with server-rendered html content, you need cookies anyway for the server-rendered pages (unless you want to make all your non-ajax forms to submit via ajax to use the local storage token, which is a pain because you'll end up fighting against most web frameworks and re-inventing the wheel).

  Given this, my takeaway is that cookies basically cover a super-set of the scenarios that local storage tokens do, so it seems preferable to stick with cookies everywhere vs. using two separate auth flows, even though I agree that web storage is conceptually a nicer model with a smaller attack surface.

• by somlor on 5/31/16, 4:33 PM

  For single-page apps I use two session tokens. One in localStorage (csrf_token), one in a secure, HttpOnly cookie (auth_token). Both tokens are required for the API to authenticate a request.

• by omgitstom on 5/31/16, 6:30 PM

  As a developer, I feel like I have more control over mitigating CSRF then XSS.

  But where I have more issues is that OWASP clearly advises not to use web storage for identities:

  + A single Cross Site Scripting can be used to steal all the data in these objects, so again it's recommended not to store sensitive information in local storage. + A single Cross Site Scripting can be used to load malicious data into these objects too, so don't consider objects in these to be trusted. + Pay extra attention to “localStorage.getItem” and “setItem” calls implemented in HTML5 page. It helps in detecting when developers build solutions that put sensitive information in local storage, which is a bad practice. + Do not store session identifiers in local storage as the data is always accessible by JavaScript. Cookies can mitigate this risk using the httpOnly flag.

  https://www.owasp.org/index.php/HTML5_Security_Cheat_Sheet

• by sly010 on 5/31/16, 5:27 PM

  It absolutely makes sense for large single page applications where you are doing multiple roundtrips to load the application anyway and you will keep the tab open (e.g gmail / trello / etc).

• by albinowax_ on 5/31/16, 3:01 PM

  Let me know if you think it's all wrong :)

• by vladgur on 5/31/16, 7:08 PM

  I would agree that Session storage is an ideal way for handling your session token if it wasnt for the fact that its only visible in a current window/tab.

  I do want my users to be able to keep their session across tabs and not be forced to sign in again and as far as I know the only way to do this is to use cookie storage

  Does anyone have a strategy use one of Web Storage APIs AND keep your session across tabs/windows?

• by advisedwang on 5/31/16, 5:15 PM

  My concern with a Web Storage based token is additional latency. With this system, a page has to be served, javascript executed, and an XHR sent before an authenticated response can be sent. With Cookies, the very weakness the author points out - sending it on the first HTTP resonse - is a massive asset for reducing latency.

  Is there a way to mitigate this?

• by therealmarv on 5/31/16, 5:15 PM

  Very newbie question but is this always true? "Another distinction is that sessionStorage will expire when you close the tab rather than when you close the browser" So I cannot use session tokens in the same way as (secured) cookies for letting the user e.g. logged in when all tabs closed?

• by hoodoof on 5/31/16, 10:11 PM

  OK so I am just about to write some code for storing tokens.

  What is the definitive answer for where I should store them? Based on this blog post, the answer seems to be "Web Storage"

• by andersonmvd on 5/31/16, 5:13 PM

  Although it's true that tokens in localstorage doesn't expire, the token itself can expire if you set it to expire when using Json Web Tokens (JWT) for example.

• by ninjakeyboard on 5/31/16, 5:19 PM

  isn't this sort of a use-case-specific choice? for unsecure data you can sign it and put it in a token as a cookie eg JWT. Different use cases will support different approaches and have benefits and draw backs. The more state you put in the browser, the less you have in your app. That can be better or worse for many reasons - simplicity, performance, scalability etc are all impacted.

• by awinograd on 5/31/16, 4:31 PM

  I definitely agree with the premise that cookies are inherently insecure. With sessionStorage it's unclear to me if there's a clean way to send the secret with every http request. Does that mean binding to every link / button click event?

  Also you mentioned this, but disappearing on tab-close makes it less of a drop-in replacement for cookies since that breaks existing behavior.

  Interesting idea though! Enjoyed the read.

• by pfooti on 6/1/16, 3:45 AM

  I've been doing a fair bit of web app development (single-page, CMS like stuff with user-generated content in the vein of a wiki, forum, or adjacent use space). I keep my session tokens in localstorage, websql, or indexeddb (depending on the platform, [0] is a really nice polyfill / shim to give you good key-value stores on many different browsers).

  My session tokens are just 48 characters of base64 randomness, because that way I don't have to worry about dealing with JWT - it's a neat idea, but there have been enough bugs in the implementation that I'm still leery. Plus: this way I can expire tokens on the server side.

  I keep session tokens stored in redis, and do an expire on them by default. Each time the token is fetched, it gets expired again (so the token actually expires N days after the last time the user visits). So yeah, each API request is burdened with two redis calls - one to verify the token and another to reset exipiry. It doesn't seem to weigh on my overall server perf - the actual API call is where most of the cpu goes (relatively speaking, it's still straightforward indexed sql queries most of the time).

  The token is attached as a bearer token in the header of all my XHR requests.

  The big problem is images. I work with teachers, who may want to post images of students or student work (to share with colleagues in a research project, behind security is okay, but not if those images can leak to the broader world). You can't (AFAIK) set browser-wide headers on the request that gets generated when the browser encounters an img src="url" tag. That's unfortunate, and I've played with a few options. One is: don't protect images at all - if the images aren't sensitive, then leaking them to twitter or pinterest when a user right clicks isn't the end of the world. One is: use a cookie that's only good for authenticating on the image server, and set it at app init time. One is: fetch the image data in an XHR, set the image up as a blob in the page, and set the img src attribute to the blob's dataurl.

  None are particularly satisfying. You can crash the chrome tab (at least in chrome, I didn't test in safari / ff once I knew I was crashing chrome) if you go with the blob direction if the blob image is too large (goes OOM, then goes "aww snap"). Unfortunately, the blob approach is probably the best one if you're really worried about leaking images due to user foolishness - any user could download and re-upload an image anywhere, but you want to prevent someone from right-click, copy-image-url, tweeting the image. The blob approach prevents the image url from leaking in that situation, whereas the special-cookie approach doesn't.

  Ultimately: we decided that we would allow images to leak if they had to - we're training users that they need to not embed potentially sensitive images inline at all. It's annoying, but there we are. Here's where session storage doesn't work as well as cookies.

  0: https://mozilla.github.io/localForage/