I have a question which is outline at Use different local storage between windows. The very high level question is "How can I keep tabs and windows sessions from clashing".


I want to be able to have separate "sessions" for each tab(s) or window(s).


The problem is if I store the data in cookies or in HTML Local Storage, it will be very difficult prevent the user from screwing up the data by opening s new window or tab and keeping the data separate.

Possible Solution:

Since Tabs and Windows share cookies and HTML Local Storage under the same instance. My question to here is, how safe is it to store a unique key in a hidden field to use to retrieve the cookies or HTML Local Storage? By doing it this way, if a new page is created (or Tab), this field is not shared across tabs and windows. What's the security risk in this approach and its a good idea?

For example, I would store the session id or Key in a hidden field:

  <input type="hidden" name="sessionId" id="sessionId" value="" />
  • Can you be more specific about the hidden field: hidden field of what?
    – Erik Eidt
    Jun 26 '15 at 19:09
  • @ErikEidt I updated the OP to reflect your question
    – PhillyNJ
    Jun 26 '15 at 19:13
  • Ok, not too big a deal but the web page becomes uncacheable (if it already is anyway, obviously this won't matter). I don't think this is any worse than using a cookie, from a security perspective, as both appear on the wire, just where in the http packet is different (header vs. content), but I'll let others weigh in on that. Are you using https?
    – Erik Eidt
    Jun 26 '15 at 19:20

Cookies are primarily attractive because of the ability to store long-lived values and the convenience of not having to explicitly submit session identification with each request (because the browser will). You can also pretty effortlessly hide cookie values from scripts, whereas the same protection over a form field or variable requires a more verbose solution.

But, since you'll probably be rolling your own session management library, you'll need to be aware of a few things -- probably more than I have listed here -- but as a start, you need to protect against:

  • Predictable session ID's which may allow users to "find" and hijack another
  • Allowing users to provide their own Session ID; only ID's generated by the server should be recognized
  • Allowing scripts to see the session ID

The first two concerns apply to any type of session. They're notable largely because you'll likely be rolling some custom session management code. The third concern applies much more-so, but not exclusively, to cookieless sessions, because cookie headers can be flagged as http-only cookies.

To prevent scripts from seeing a value, you need to close over the ID with some care:

var SessionScope = (function() {
  var o = {};

  // outside scripts can't see this:
  var session_id = '1234';

  // these methods can see session_id and use it to channel/sign requests
  o.get = function(url, data) { };
  o.post = function(url, data) { };
  o.whateverelse = function() { };

  return o;

To be clear, you ideally need to ensure that the SessionScope (or whatever) is built in such a way that it doesn't even have ties to a constructor that could be toString()'d.

Now, I understand the risk of letting scripts see your session ID's to be pretty low in most cases. It becomes most problematic when you display data submitted by one user to another user, or when you incorporate less-than-trustworthy 3rd party libraries. That said, if you go this route, it's perfectly feasible to add the extra protection, so you should.

And again, you'll want to consider that, if you depart from storing session ID's in cookies, you'll likely either lose or impede the ability to reattach to the session without asking the user to "find" it in some way.

With all of that said, you may not actually want distinct "sessions" at all. The best solution may still just be a single session. If your user is logged in using the same credentials and permissions on each tab, and you need to track data related to a particular window, tab, or view on both the client and server, you probably just want a collection in the session. But in that type of solution, view/tab identifiers aren't usually necessary because the view only asks for things relevant to itself.

Cross-talk between tabs and views is avoided by a combination of keeping things out of the "global" session that don't belong there and only asking for things you need.

But, if that's not feasible for some reason, you could consider adding a collection of view collection to your session model and passing a viewid around. In this case, you wouldn't have to worry about all the security concerns of session key management and protection (assuming you're properly using a strong session system). The view keys would only be relevant to the session, so a leaked viewid isn't relevant to anyone else, and therefore not a significant threat.

  • Question - Isnt cookies a moot point since a cookie is shared across all instances?
    – PhillyNJ
    Jun 26 '15 at 20:32
  • 1
    @PhillyNJ I'm not saying you should use cookies; I'm saying cookies and prepackaged session management systems come with some protections against XSS that you need to be aware of when you're implementing a new, cookieless session management system.
    – svidgen
    Jun 26 '15 at 20:38
  • Understood. Also, either I dont understand your answer or you misunderstood my question. I am not implementing my own Session Management Library, but rather want to store a KEY in a hidden field. This key would be used to identify which session belongs to which tab or window.
    – PhillyNJ
    Jun 29 '15 at 12:28
  • @PhillyNJ Yep. My assumption is that that action constitutes either the modification of an existing session sub-system or the creation of a new one. In either case, it'll be wise to consider the first two bullets above. And the third bullet is a consideration that is implicit to the cookie to not-cookie change.
    – svidgen
    Jun 29 '15 at 14:46
  • @PhillyNJ See my addendum. Maybe that speaks more to what you're trying to do ...
    – svidgen
    Jun 29 '15 at 15:04

I thought about this a little bit to see how complicated it would be to have our web server support multiple sessions across multiple tabs. Disclaimer I just had a quick brainstorm about this and I have not done this in practice or even tried to implement something like this. In order to take advantage of everything that cookies do and to not have a major rewrite on our client and server I wanted to keep using cookies for session management.

To do this we would make unique url paths and have that cookie be unique to that path, our application is single page so it would be pretty trivial to add an ending /GUID/ and just ignore it on the client and server. Things might get complicated for multi page applications.

Previous way:

User goes to mydomain/app/ in two tabs and their session id cookie is shared across tabs.

Proposed way:

User goes to mydomain/app/ they are redirected to mydomain/app/{GUID}/ with a cookie path of mydomain/app/{GUID}/ a new tab is opened and they are redirected to mydomain/app/{NEXTGUID}/ with the {NEXTGUID cookie path. When tab 1 communicates with the backend that tabs specific cookie is only visible to the server and the same thing with tab2. The client knows nothing about its session id and the server just uses the session id that it is given, single or multiple tabs everything just works the same way.

Response to comment

No storing the session in the url is a bad idea for security reasons. The guid would just make the cookies path unique to that tab, the session key is still in each cookie. The guid and session id know nothing about each other. The cookies could and should be httponly and not available to the client.

I think the benefit to this approach is that the client has no knowledge about how to manage sessions (the browser will send the right cookie and the associated session for that tab) and the server will just use the session from the passed in request. The only thing that needs to get implemented on the server is adding something to the uri to make it unique per tab and have the session cookie use that uri when setting the path on the session cookie. This will also allow for non browser based clients that don't care about tabs to have a clean api as well, they just need to send the session cookie in the cookie header.

  • Interesting approach. I think the only difference between your approach and mine, is I would store the key (or in your case a guid) in a hidden field and you would store yours in the URL string. I think is a plausible idea, but like my idea, is it safe?
    – PhillyNJ
    Jun 29 '15 at 18:16
  • @PhillyNJ I updated my answer to respond to your comment.
    – pllee
    Jun 29 '15 at 19:13

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.