tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: Is there a better way to disable JSESSIONID in the URLs?
Date Thu, 19 Aug 2010 04:08:51 GMT
Hash: SHA1


Wow. I wrote a book. Sorry for my uncharacteristically long exposition.

On 8/18/2010 5:40 AM, André Warnier wrote:
> Could/should not Tomcat at least verify, when it gets a JSESSIONID from
> a client and retrieves the corresponding session information, that the
> IP address of this current client matches the client IP address (which
> would have been) previously stored in the session ?
> Or would this introduce other problems ?

Sometimes a user's IP changes for one of several reasons:

1. Internet connection dies / re-establishes with a new BOOTP/DHCP IP
2. Came through a different proxy on different requests
3. You have AOL, who apparently loves to play games with IPs

This is a good security feature to allow users to opt-into, though.
There's a filter in securityfilter (have I committed it, yet?) to do
just this, and it's user-selectable at login (or any time? I'll have to
look at the code again).

> I know that it is not really a "solution", because hapless users will
> anyway continue (mostly innocently) to email links to their colleagues,
> and they will wonder why they do not work.

If security has been implemented correctly, Tomcat will ask the user for
their credentials and ultimately give access to the requested resource
once authentication has been completed successfully. That's part of the
spec: one that works quite well for users IMO.

> If I understand correctly how it works, then currently the following
> scenario is possible, isn't it ?
> But because the link contains the jsessionid of the first user, the
> colleague would gain access to the resource, without either one of them
> even thinking about it.

Yup. This is called session hijacking. It can be performed against any
web server using non-SSL sessions (I mean an SSL-session, not just an
HTTP session being used over HTTPS).

Note that "disabling" the jsessionid parameter being added to URLs does
not in the slightest way prevent a hacker from crafting a URL that
contains a jsessionid and using it to hijack a session.

Not only that, but there's no spec or Tomcat requirement that the
session be accessed via SSL. That means that if you, André (the "good
guy") log into your secure web application using HTTPS and establish a
session, I (the "bad guy") can hit
http://yourserver/secretStuff.jsp?jsessionid=12345 and, if I've guessed
your session id correctly, I get to masquerade as you. In fact, I
believe Tomcat will continue sending Set-Cookie headers, so once I've
sent my specially-crafted URL to the server, I don't even have to go
through the pain of re-writing every URL I see: I've got the same cookie
you do, now, too (except mine probably doesn't have secure=true set).

Note that guessing a session id is non-trivial, so it may take a long
time to accomplish. The good news for hackers is that there is no
built-in anti-hacking mechanism to prohibit remote users from simply
attempting to hijack session id after session id, so they can try all
day to break into a standard Tomcat server.

No, I haven't yet written a filter that can capture these attacks and
try to mitigate them.

> This is inside a corporate LAN, where one would normally tend to
> consider communications as "trusted", and thus to not really need SSL.

Hah. Trust no one.

> But by simply exchanging this link, the users unwittingly or not break
> the access control mechanisms buried deep into an application.
> Furthermore, now these two users can continue to interact with the
> application, both within the same Tomcat session, although they are on
> different workstations altogether ?
> To me, that sounds really bad.

It's not terribly good. Note that the presence of the jsessionid in the
URL is not really the attack vector: it just makes the attack vector
slightly more convenient for hackers or idiots. Cookies have the same
"danger" in that anyone can send any cookie to any web server. The real
problem is allowing remote clients to self-authenticate -- that is,
provide an otherwise non-corroborated credential (that's the session id)
to the server. The only really good way to secure a session to a single
user is to use SSL client certificates with the cert fingerprint stored
in the session. Even then, the client cert can be shared with others so
you're really just shrinking the pool of potential session hijackers to
those who might be able to get their hands on an SSL cert.

With credentials, it's always something you know or something you have
(or something you /are/, but that's not practical for web-based
security). Something you know can always be guessed if given enough
time. Something you have is almost always better than something you
know, especially if it's not duplicatable (is that a word?) like one of
those dongles they used to use for software licenses. Coupling the two
is pretty much as good as you can get (which is why they call it
"two-factor authentication" and why it gets so much hype).

By the way, anyone not using SSL certificates who says they use
two-factor authentication for web-based security is lying to you: they
are using dual-single-factor authentication which isn't the same thing.

- -chris
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla -


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message