You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by mfs <fa...@gmail.com> on 2008/04/17 06:23:49 UTC
Cookie-less session tracking - whats are the downsides
Guys,
I would want to know the downsides to using cookie-less sessions ? I want to
give my client the freedom to disable cookies on the browser if he chooses
to, but i would want to know the implications to that ?
Some say, exposing your sessionId in the url exposes it to hackers who can
spoof the IP (as of the victim) and provide the jsessionId (in the url) and
can gain control of the victim's session, but if u are using ssl, that
shouldnt be an issue.
Would someone comment on the real hazards/bottlenecks to the cookie-less
approach.
Thanks in advance and Regards,
Farhan.
--
View this message in context: http://www.nabble.com/Cookie-less-session-tracking---whats-are-the-downsides-tp16738472p16738472.html
Sent from the Tomcat - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Cookie-less session tracking - whats are the downsides
Posted by Peter Stavrinides <p....@albourne.com>.
This topic comes up on the list very frequently, you ask ten developers
this question you may even get eleven opinions. Your answer is it
depends on your use case and security requirements (for example: I may
not care, in a shopping cart application, if I write a product id in the
URL, but I may care about exposing a primary key for a user record in
the URL)... these are subject to your implementation.
I suggest you do a little more reading and understand the history of
cookies and URL rewriting, which may help you to understand why/why
not/when to use them, because this is a highly subjective area, and when
do developers agree about technology anyway! Personally though, I am
prepared to sacrifice some compatibility in favour of security... on the
other hand I also detest the over paranoid.
Peter
mfs wrote:
> Guys,
>
> I would want to know the downsides to using cookie-less sessions ? I want to
> give my client the freedom to disable cookies on the browser if he chooses
> to, but i would want to know the implications to that ?
>
> Some say, exposing your sessionId in the url exposes it to hackers who can
> spoof the IP (as of the victim) and provide the jsessionId (in the url) and
> can gain control of the victim's session, but if u are using ssl, that
> shouldnt be an issue.
>
> Would someone comment on the real hazards/bottlenecks to the cookie-less
> approach.
>
> Thanks in advance and Regards,
>
> Farhan.
>
>
>
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Cookie-less session tracking - whats are the downsides
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Robert,
Robert Koberg wrote:
| On Thu, 2008-04-17 at 09:38 -0400, Christopher Schultz wrote:
|> The only runtime bottleneck is the time required to add
|> ";jsessionid=123456789" to your outgoing URLs, which is to say "pretty
|> much nothing". The engineering bottleneck is that you have to run all
|> your URLs through HttpServletRequest.encodeURL or
|> HttpServletRequest.encodeRedirectURL (which you should have been doing
|> all along, right?).
|
| I doubt you have been doing that unless you have a special
| HttpServletRequest :)
request... response... whatever ;)
s/Request/Response/g
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkgHZk0ACgkQ9CaO5/Lv0PCGKwCeKv5OOOnoztWIxcnjkUcbrwWy
yScAn23Ck+NHG+ZOKBQTVUcHGy+TQhca
=ltPT
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Cookie-less session tracking - whats are the downsides
Posted by Robert Koberg <ro...@koberg.com>.
On Thu, 2008-04-17 at 09:38 -0400, Christopher Schultz wrote:
> The only runtime bottleneck is the time required to add
> ";jsessionid=123456789" to your outgoing URLs, which is to say "pretty
> much nothing". The engineering bottleneck is that you have to run all
> your URLs through HttpServletRequest.encodeURL or
> HttpServletRequest.encodeRedirectURL (which you should have been doing
> all along, right?).
I doubt you have been doing that unless you have a special
HttpServletRequest :)
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Cookie-less session tracking - whats are the downsides
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Farhan,
mfs wrote:
| I would want to know the downsides to using cookie-less sessions ? I
want to
| give my client the freedom to disable cookies on the browser if he chooses
| to, but i would want to know the implications to that ?
http://randomcoder.com/articles/jsessionid-considered-harmful
I disagree with nearly everything this guy has to say (laziness is no
excuse and it's no less risky than using cookies), except for the part
about the search engine problems (which shouldn't be understated). The
author provides a workaround for that, though. Unfortunately, that
solution generates /lots/ of sessions unless your code handles it properly.
Frankly, you should be avoiding sessions without authentication in the
first place, search engines should never authenticate, and therefore
your application should never generate a session for a search engine,
and the problem is gone. There are certainly reasons to create sessions
for non-authenticated users, but this is one argument against doing that.
| Some say, exposing your sessionId in the url exposes it to hackers who can
| spoof the IP (as of the victim) and provide the jsessionId (in the
url) and
| can gain control of the victim's session, but if u are using ssl, that
| shouldnt be an issue.
...and this is just as easy with cookies. They are no less susceptible
to this type of attack. The only difference is that URLs (including the
jsessionid) are often logged on proxies and web servers, while cookies
are almost never logged.
SSL fixes everything but the logging, which shouldn't be a problem on
properly secured systems.
| Would someone comment on the real hazards/bottlenecks to the cookie-less
| approach.
The only runtime bottleneck is the time required to add
";jsessionid=123456789" to your outgoing URLs, which is to say "pretty
much nothing". The engineering bottleneck is that you have to run all
your URLs through HttpServletRequest.encodeURL or
HttpServletRequest.encodeRedirectURL (which you should have been doing
all along, right?).
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkgHUt4ACgkQ9CaO5/Lv0PDFHACgi8yIAnRsDENNTnukH25AVkUG
krYAn2xwy69v5FTgJ0MIFhmPsGp5kEkF
=vvmJ
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Cookie-less session tracking - whats are the downsides
Posted by David Smith <dn...@cornell.edu>.
The "man in the middle" attack you describe below is one possible
issue. However it's easy to capture cookies and provide those in an
attack. An effective hacker is going to be able to look exactly like
the client on an unencrypted connection. URL encoded sessonIds can
cause headaches if you a proxy in the middle strip off the sessionIds on
the way through or if the search bots suck up URLs with sessonIds. If
your app can effectively handle those cases, I don't see a downside.
--David
mfs wrote:
>Guys,
>
>I would want to know the downsides to using cookie-less sessions ? I want to
>give my client the freedom to disable cookies on the browser if he chooses
>to, but i would want to know the implications to that ?
>
>Some say, exposing your sessionId in the url exposes it to hackers who can
>spoof the IP (as of the victim) and provide the jsessionId (in the url) and
>can gain control of the victim's session, but if u are using ssl, that
>shouldnt be an issue.
>
>Would someone comment on the real hazards/bottlenecks to the cookie-less
>approach.
>
>Thanks in advance and Regards,
>
>Farhan.
>
>
>
>
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org