Caldarale, Charles R wrote:
From: Scott Hamilton [mailto:scott.hamil...@plateau.com]
Subject: RE: Is there a better way to disable JSESSIONID in the URLs?
I could be missing something, but on a request where a session is
created it appears as though Tomcat will both set the cookie AND
do any necessary URL rewriting in order to ensure that the cookie
is preserved.
Sorry, you're right; at that point Tomcat doesn't know if the client supports
cookies. However, when skimming through the Tomcat code, the only internal
call to encodeURL() that I can find appears to be called only for relative
URLs, so possibly making your initial URLs absolute might avoid appending the
jsessionid. (But I could have easily missed a call, and there may be another
method that's doing the appending.)
The issue in question isn't so much about determined hackers
but hapless users who will bookmark URLs or worse, copy URLs
to email to their co-workers.
"Hapless" being the operative word. I think you're stuck with using a filter.
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 ?
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.
And it is not a foolproof security system either.
But at least then these links would not so easily "work" and give cold sweats to these
people's network admins.
If I understand correctly how it works, then currently the following scenario is possible,
isn't it ?
Within a corporate LAN, all users must login into their workstation using some form of
network login (in 99% of the practical cases, that would be Windows NTLM).
Then they call up an application residing on a corporate Tomcat host. This host is
configured so as to automatically pick up the user's network user-id (through e.g. Jespa,
or Waffle, or similar), and use it as the "Tomcat user-id".
Then this first user session gets a tomcat session and associated JSESSIONID.
The application checks that the user session is authenticated, but also controls access to
some information in function of this user-id.
Now this particular user gets a link to a resource, accessible to his user-id, and then
copies that link to a colleague (also logged-in into the corporate network), who normally
would not have access to that resource.
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.
This is inside a corporate LAN, where one would normally tend to consider communications
as "trusted", and thus to not really need SSL.
The authentication method is fairly secure, in the sense that passwords are not exchanged,
and Tomcat can "trust" the user-id as received by the first user's authentication method.
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
