tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier>
Subject Re: Is there a better way to disable JSESSIONID in the URLs?
Date Wed, 18 Aug 2010 09:40:06 GMT
Caldarale, Charles R wrote:
>> From: Scott Hamilton []
>> 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:
For additional commands, e-mail:

View raw message