if the following conditions are met:
all pages are static (eg, templates to be filled in via websocket data)
all pages are public
session id and status communicated through websocket
client session state stored via sessionStorage and/or localStorage
is there still a need for cookies?
The localStorage/sessionStore can indeed replace cookie Storage. Both are on the client.
The neat thing about cookies is that they are auto appended to any HTTP request. There is absolutely nothing to do from a coding standpoint. But since you want to use websockets, it doesn't apply - you will still need to do wiring with the sessionid stored in the localStorage.
So the answer to your question is "No" you don't need cookies in your scenario
If the pages are 100% static then there is no state, so the question becomes moot, since no mechanism at all is required for preserving state across requests.
However, if any part of the pages are dynamic then cookies may still be necessary for preserving state across multiple sessions. Since cookies are stored client side but passed to the server with every request they are a mechanism for synchronizing client and server state. Of course, you could implement this via an AJAX request and localStorage yourself if you wanted to.
Related
Background: I have two apps frontend and backend. Backend is django with django rest framework. For auth I use token. Client gets the token when it logs in via post. Client sets this token to header and keeps token in localStorage. I save the token to localStorage to prevent second request after reopening the site. But I have written a lot of articles where were wrote that localsStorage is vulnerable and it is susceptible to xss attacks. And now I thing about cookies. But I don't want to rewrite my backend logic. And I'm thinking about writing the token to a cookie via js.
My question: Should I write token to the cookies? Or should I rewrite my backend application and use sessions? Or mb don't rewrite it?
Both cookies and local storage are similarly susceptible to being tampered with on the client-side: the client can see and modify both, and so can any (possibly malicious) extensions they have. But if the connection to your site is over HTTPS and their browser/OS/hardware doesn't have something malicious snooping on things, then there shouldn't be an issue with either cookies or local storage.
The main difference between them is that cookies get sent to the server with every network request, whereas local storage stays on the user's hard drive and doesn't get sent to the server.
Cookies are arguably a little bit more vulnerable than local storage because if a cookie gets sent over an unencrypted connection, it can be intercepted - but local storage stays on the client's machine, so there's less chance of it being intercepted by something malicious. But if the connection is encrypted, which it should be, using cookies will be fine.
If your script requires the token to be sent with requests to the server, you should probably use cookies so you can examine them on your back-end. (If you use local storage instead, you'll have to manually send the token with every request, which is still possible, but a bit inelegant given that cookies can do the same thing without requiring manual intervention on your part.)
If your script doesn't require the token to be sent with every request, then feel free to use local storage instead if you want. If the server never needs to see the token after it's been generated, then don't use cookies, since it'll be unnecessary overhead for no reason.
The same general logic above applies to any data on the client-side. If the server often or sometimes needs to see it, cookies are a good choice, if the data isn't too large. If the server never needs to see it, cookies are the wrong choice.
I am storing some basic information to use in order to display information per user. I am currently using cookies to store and retrieve them, however I would like to employ a more secure tactic. I read that using local storage would be more secure and better to use, however, they don't seem to have any expiration date (like cookies) and unless you use a session storage, they will be stored indefinitely, which I don't want. However I don't mind using local storage if the information is encrypted, however with current encryption libraries, I have no idea how to use them.
Storing:
username
login attempts
whether the user is locked out or not
Some things to note: what I am storing is not being used for authentication, only to display error messages. I am using tomcat 8 to handle authentication and running the server (along with lockouts). Even though its not being used for authentication, I don't want to store the username unsecured or without expiration (1-2 days max).
Also, I'm not using an sql database (or other type) but plan to implement later, so don't suggest or ask about it.
I'm looking for the most secure method possible with relative ease, we have other security measures implemented, but don't want to leave any security holes open.
There is no such thing as secure that is purely client-side with two-way encryption. If you are able to decrypt something on the client-side, so can others.
Also, there are no particular security differences between session storage, local storage, and cookies. They're all client-side and able to be read by JavaScript on the same domain.
If you really want things to be secure, you have to store in on the server side, and transfer it only over HTTPS. Anything else is merely security through obfuscation, at best, which isn't real security.
As far as expiration, there is no automatic expiration with either local storage or session storage (other than the session storage will be cleared when the session ends). You could implement some with JavaScript, but that would only involve throwing away values when they are too old, and wouldn't happen until they visited your page.
The best you could do that is almost pure client-side would be to store some kind of key on the server, and when you go to decrypt, it needs to request the key (over HTTPS) from your server and use that to decrypt. That way, they can't decrypt it without having some kind of proper authentication onto your server.
However, if you're doing that, you might as well just store the info on the server in the first place.
Lets rewind to the days of cookies, ok not that far as they are old but still relevant. You can set them and read them with PHP; despite the fact they are a client side technology, you can also use JavaScript, fully client side.
Coming forward in to the future, HTML5 Local Storage, also a Client Side technology can not be set by PHP, you are solely reliant on JavaScript.
It seams as though this is the reverse way of doing it (taking away not adding). Surely to have the ability to set this data with PHP is helpful and possible somehow considering Cookies can be.
So why isn't it possible? What was the reasoning in not designing a way to do this?
Update Correct me if I am wrong, but localStorage is a replacement of Cookies, so does this not mean you are losing functionality?
Lets rewind to the days of cookies...You can set them and read them with PHP; despite the fact they are a client side technology...
No, they aren't. Cookies are primarily a client/server technology. They were specifically designed to allow the server to send information to the client that the client will then send back to the server. From the spec:
This document defines the HTTP Cookie and Set-Cookie header fields.
These header fields can be used by HTTP servers to store state
(called cookies) at HTTP user agents, letting the servers maintain a
stateful session over the mostly stateless HTTP protocol.
Although you can access them via client-side JavaScript, that isn't what they were created for, nor is it their sole purpose.
Web Storage (what you've called "HTML5 Local Storage") is client-side only. If you want to send that information to the server, you do it via ajax or by sending a form.
Why? That takes us into the land of speculation, but we already have cookies, whereas we didn't have a client-only way to store data prior to web storage. A client-only solution is very useful, not least because we can store a large amount of information without it being unnecessarily added to each and every HTTP request that client then makes to your server, which is a waste of bandwidth if the information is only needed client-side.
cookies … can set them and read them with PHP; despite the fact they are a client side technology
They aren't a client side technology. They are an HTTP technology. The are embedded in the communication protocol used between the client and the server.
Local Storage is a purely client side alternative to sessions and databases, which were already available on the server side.
It's purpose is for storing data that is too big for cookies. If you could edit it on the server, then the contents would have to be sent in every request, which would be very expensive. It would also turn Local Storage into "Cookies without the restriction on size".
Is the newly introduced localStorage facility in html5 a replacement for cookies? Does localStorage help in making the http from stateless to stateful. Or is the localStorage an addition to the cookies. Do you still need to use cookies to track the user or even that can be done ny localStorage?
Local Storage allows client-side javascript to save state on a local machine (if LocalStorage is supported). That is one thing that client-side javascript might use cookies for, but cookies are also used for other things that LocalStorage cannot replace.
For example, LocalStorage is never seen by a server so if a server wants to keep track of some client state itself or track something across multiple pages on a domain, then the server can't use LocalStorage for that and will likely still use cookies. Cookies for a domain are sent to the server with each request on that domain (thus enabling things like authenticated login across all pages in a site). This is something that LocalStorage cannot do.
LocalStorage has nothing to do with HTTP; it's a purely client-side feature.
The client gets it's secret for HMAC encryption after it's first login on the server - but what's the best way to store the secret on the (java-script) client? cookie, localStorage?
thx
Well the answer is, it depends. localStorage and cookies are not equivalent. Although they both can be used to store information on the client, they serve very specific goals. localStorage is meant to store application's data locally. It cannot be set directly from the server and is not sent to the server through HTTP headers either.
You may also have a look at sessionStorage.
However, cookies are typically created from the server (even if there's a JS API) through HTTP headers and they contain expiry information. Once set, they will be part of every client request's HTTP headers, allowing the server to access the information.
Both ways are probably equally secure since they both cannot be accessed from another domain. However if you are transmitting secure information you should probably do it through HTTPS as well.
The best way is pretty subjective.
If you must store it on the client (you must, I assume), then it can't be secure, it just can't.
Putting that aside, the best way depends on your situation.
Are you trying to target older browsers? Then you can't use local storage.
Since we've already removed security from the equation, your most far-reaching, cross-browser-compatible solution is to store it in a cookie.
That's also probably one of the easiest solutions, though certainly the least secure (since your only form of security here is obscurity, and cookies are... not obscure).