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:
- They do not have to care about CSRF Protection, because no session identifier is sent without explicit intend.
- 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.
- 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).
- The session invalidates as soon as the user changes to another site.
No crossdomain.xml hassle: As far I know a flash movie cannot access in-memory variables of a JavaScript instances.
Here are the drawbacks I identified so far:
- 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? - 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
comments appreciated...
wlet
<>
AntwortenLöschenSure it can. Flash can invoke JavaScript in the context of the page, and thus can "see" the token.
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.
AntwortenLöschenThe only downside that I have seen to this approach is the browser caching the previous POST (i.e. no "redirect after POST" pattern).