3

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.

Anders
  • 64,406
  • 24
  • 178
  • 215
Panayotis
  • 133
  • 4
  • 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 03: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 06:34

2 Answers2

5

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).

CBHacking
  • 40,303
  • 3
  • 74
  • 98
  • 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
  • I believe that is up to the vendors, and not truly standardized, though I could be wrong. In general, it is "cookies bound for origins other than the one of the top-level document", but what constitutes the same origin is certainly up for some debate. In most cases, though, it is clear enough; sites that share no part of their domain name except the TLD, and possibly not even that, are definitely third-party. Mind you, all of this is somewhat off-topic. The face remains that some users (or browsers) block a subset of, or even all, cookies. Not many, these days, but some. – CBHacking Jun 21 '18 at 02:47
  • @CBHacking Indeed, you rely on the developer's willing of adding the `https` which is less secure. Plus, your variable might be read by some XSS breah while `http only + secure` cookie won't. Last, it might be read by some GreaseMonkey script or plugin while cookies can be locked in a vault by the browser and be inaccessible by plugins nor userscript (but this should be checked because I'm unsure: it's doable, but maybe not done) – Xenos Jun 21 '18 at 07:44
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).

symcbean
  • 18,278
  • 39
  • 73
  • "_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 09: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