views:

77

answers:

2

We are programming a new web application framework (Second WAF). I was wondering if we should support cookieless sessions or not.

Who use it and who needs it?

+1  A: 

It is a good feature, but several aspects have to be taken into account

  • what if an URL containing session ID is cached by a web spider such as Google, will you be able to provide content if the ID in session is other than the ID provided in URL
  • security. If you don't implement it smart enough, users will be able to send a URL to another user, where the URL contains the session ID and hence, allowing hijacking the first user's session. For instance, in ASP.Net1.1 the cookieless session mechanism was considered vulnerable
naivists
Ok, but is it even possible to implement URL based sessions secure? If the user sends the url to another user and the session is valid? What should be verified? IP address, browser string,...?
Thomas Maierhofer
+1  A: 

I was wondering if we should support cookieless sessions or not.

I think this depends largely on your userbase. In my organization we support several intranet applications. We also control our users desktops. Since we control their desktop environment we can control browser settings and ensure cookies are enabled. Because of this and the increased risk of session hijacking, there is no reason for us to ever allow cookieless sessions.

Who use it and who needs it?

Those who need to support sessions regardless of the end users' browser settings would need to implement cookieless sessions; keeping in mind the implications of doing so.

tribus
I think we will set this feature on the wishlist but won't implement it in the first version.
Thomas Maierhofer