Sonntag, 28. November 2010

Sessionmanagement in X-Header

Hi,

I recently stumbled upon a solution for session management where I'm searching hard to find the weak points but I failed so far.

There is this web 2.0 application which neither uses cookie nor it transports the session ID within the URL. The devs decided to transport the session ID within an X-Header HTTP field which they send over on each (XHR) request. This seems smart from a range of perspectives:
  1. They do not have to care about CSRF Protection, because no session identifier is sent without explicit intend.
  2. They do not have to care about cached or otherwise leaked session ids, since the ID is held in RAM only and the user doesn't see (and thus cannot share it accidentally) it.
  3. They fully control the transport of the session ID (they do not need a "secure" flag for their cookie as the ID is only send to desired hosts with desired transport protocol).
  4. The session invalidates as soon as the user changes to another site.
  5. No crossdomain.xml hassle: As far I know a flash movie cannot access in-memory variables of a JavaScript instances.
So, these are the advantages, but hey: if there is light, there must be shadow :).
Here are the drawbacks I identified so far:
  1. The X-Header isn't clearly specified in RFC2616 - only in RFC2045ff
    I'm not sure how this affects this approach - Are there any Proxies etc out there which are stripping X-Headers?
  2. No "HTTP only" flag, but hey it's a web 2.0 application. Even if a cookie is set this can't be done for such an application
I'm not happy with such less drawbacks :). Is this solution of a web2.0 session management so simple and smart that there are no big drawbacks? What I'm missing here?

comments appreciated...

wlet

2 Kommentare:

  1. <>

    Sure it can. Flash can invoke JavaScript in the context of the page, and thus can "see" the token.

    AntwortenLöschen
  2. I've seen a banking app doing all its session management using POSTed hidden form variables. Every single page is retrieved using a POST (issued using javascript), and so there is not a single cookie, nor a session identifier in the URL.

    The only downside that I have seen to this approach is the browser caching the previous POST (i.e. no "redirect after POST" pattern).

    AntwortenLöschen