2

I have decided to plunge deep into Angular-like technologies, where all pages are practically just one page that gets never reloaded. And at this point I had the idea, instead of using cookies (which I don't really need), why not authenticate with the server, get a key, and keep this key in ram as a Javascript variable, throwing away the cookie technology and the deadful "this site uses cookes to store etc." message.

In my mind this is more secure since nothing is written, everything is in RAM and is at least as safe as with the traditional cookie method.

But before I use it, I want to ask you if do you believe the same or if it is a bigger security issue than what I think.

  • Cookies span page refreshes, javascript variables don't. If you want a login to span multiple visits to the site, cookies are the easiest way. JS won't be able to do that. – Neil Smithline Jun 19 '18 at 3:47
  • you get some back and forth benefits with cookies that enable server optimizations and validations, but essentially they do the same thing as your variable: store a secret. The ram is slightly safer than cookies due to less exposure and more obscurity (every attacker looks at document.cookie) – dandavis Jun 19 '18 at 6:34
4

The primary security reason to avoid cookies would be to prevent CSRF attacks, which is a valid goal. Cookies were not well-thought-out from a security standpoint. On the other hand, there are well-established approaches to avoiding CSRF, so it's not a hugely valuable technique.

From a privacy standpoint, cookies (especially third-party cookies) are dangerous. For this reason, some users and/or browsers block them, which can provide developers with a functional reason to use something else.

However, even for a single-page application (SPA), you probably want to persist your session token. The standard way to do this from JS is to use local storage (either persistent or session storage), which is basically a way to store JS variables for a particular site across user visits, or at least page loads within a given session. All modern browsers support local storage.

The main security downside of local storage (or any other way of doing programmatic session management on the client, instead of relying on the automatic behavior of cookies), is that an attacker that gets XSS (Cross-Site Scripting) within your web app can steal the token and hijack the session to impersonate the victim, even after the victim closes the browser (by contrast, the typical session cookie is flagged as httponly, which prevents JS from reading it and restricts session hijacking to only as long as the victim leaves the web app open).

  • 1
    And by recoding cookies in JS var, you might end up sending the variable content to your server on a HTTP connection, while a cookie with Secure Only would prevent that. – Xenos Jun 19 '18 at 15:02
  • @Xenos Hopefully that wouldn't happen, because you have to construct the requests manually (unlike with cookies) and therefore are able to explicitly supply the scheme (HTTPS) to use. On the other hand, it is something you'd have to check for, yes (along with domain name typos), whereas with Secure-flagged cookies if you specified the wrong scheme or host you still wouldn't expose the cookies. – CBHacking Jun 20 '18 at 20:19
  • Block cookies but allow JS local storage? How would that makes sense? – curiousguy Jun 20 '18 at 20:38
  • @curiousguy Blocking third-party cookies is not a sufficient measure for tracking protection (and hasn't been one for a long time), but it is something that very nearly every browser - even my phone's browser - supports doing out-of-the-box, and it is still somewhat effective. As such, lots of people do it. Some browsers even default to it, or used to (Safari does something more complicated now, but they used to block third-party cookies by default). – CBHacking Jun 20 '18 at 21:00
  • @CBHacking Do we even know what "third party" is? A cookie that wouldn't be sent if SameSite "lax"? With which SameSite specification? – curiousguy Jun 20 '18 at 21:31
1

Your question is predicated on several flawed assumptions.

throwing away the cookie technology and the deadful "this site uses cookes to store etc." message

I don't know what jurisdiction you are referring to, but in the case the EU, it doesn't matter if you persist data in a cookie or in local storage, or elsewhere - it is the usage and content of the data which determines the information you must provide to the user and for which you need consent - not the storage substrate.

everything is in RAM

Not necessarily. Most browsers will persist state across sessions (of the browser, that is - seperate from all the other sessions going on in TCP, TLS, HTTP) including the Javascript state. OTOH, cookies have very well defined characteristics.

and is at least as safe as with the traditional cookie method

So you have a means of ensuring it is not exposed over non TLS connections implemented out-of-band from the content itself? (for example).

  • "implemented out-of-band from the content itself" hug? – curiousguy Jun 20 '18 at 20:39
  • Once set, a cookie with the secure flag will never be exposed over a non-TLS connection - this is enforced independently of the subsequent HTTP[S] exchanges (although admittedly it is set via HTTPS). OTOH the only things preventing javascript data from being sent over an unsecure connection is CORS - which is a lot more tricky to get right. – symcbean Jun 21 '18 at 9:16
  • AFAIK, nothing prevents a script from putting sensitive data in a plain text connection. – curiousguy Jun 21 '18 at 14:13
  • THAT'S WHAT I JUST SAID – symcbean Jun 21 '18 at 14:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.