Session Control: document.cookie vs. Window.sessionStorage

I noticed two different types of session control: Plug.Session.ETS, and Plug.Session.COOKIE

So, I’m assuming one is a document.cookie. But the other method is memory on the server?

The use of document.cookie for session control is discouraged among some people, and they suggested Window.sessionStorage instead:

Thoughts on how Window.sessionStorage could be used instead of a cookie or server memory?

Both use cookies, the point is what will that cookie contain:

  • Plug.Session.COOKIE will store all informations about session will be stored directly in cookie
  • Plug.Session.ETS will create local ETS table that will contain informations about session and cookie will contain only pointer to session in that table.

DO NOT LISTEN TO THEM, cookie is the best and most secure way to store session ID, especially when you set :http_only flag. This will cause your cookie to be not available via document.cookie, which will make it completely secure against leaking session via XSS.

It should not be used. Window.sessonStorage has exactly the same problems as Window.localStorage and should never be used to store confidential data. These mechanisms are thought as a cache mechanisms that are user-controlled.

7 Likes

So you basically telling me that client side storage is only useful as cache. Regardless if its temporary or not.

1 Like

You cannot trust anything that is stored on user machine, so yes, it is useful only as a cache.

is there a way to pass this in this web server config:

<httpCookies httpOnlyCookies="true" />

so that all cookies set are httpOnly?
how about applying the secure flag too, if its using a tls/ssl?

use Plug.Session, http_only: true

In your pipeline.

2 Likes

Thank you @ hauleth

This will work for me because I’m using sockets. Since the flag is a logical switch on the client side, there is still the issue using xhr/soap/xhttp/whater you want to call it has the cookie sent unencrypted in the header of every put,post,get,head and delete headers. Granted, a normal web user wouldn’t have access to that, but it doesn’t mean that there are not people potentially packet inspecting the connection either…

Why would the cookie be sent unencrypted if you’re using TLS/HTTPS?

Edit: oh, it was the header you were concerned about. :slight_smile:

Headers are sent encrypted as well in HTTPS connections, so that would is no problem. Additionally, even if you would store token in Window.sessionStorage or Window.localSotrage you would send the token/sessionID via header anyway.

1 Like

FYI: Firewalls may also act as man-in-the-middle in order to perform deep packet inspection (example).