tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Akoulov, Alexandre [IT]" <>
Subject RE: Tomcat security realms question
Date Mon, 18 Jul 2005 03:30:54 GMT
Thanks a lot for your reply. We'll see if we can persuade our security guys to drop this issue.

Kind regards,


-----Original Message-----
From: Mark Thomas []
Sent: Monday, 18 July 2005 2:50 AM
To: Tomcat Users List
Subject: Re: Tomcat security realms question

The problem you describe is true of any session tracking system running 
over http. The solution is to use https.

However, here's a question to fire back at your security team:
"If you are worried about an attacker physically looking at a session ID 
on a user's screen, what about if they decide to install a keyboard 
logger (physical or software) whilst they have access to the user's 

In fact, I can think of a whole bunch of other things I could do as well 
that would be equally or more damaging than hijacking a single session.

Fundamentally, if an attacker has physical access to a machine it is 
game over - they have won.

Your security team knows the threat model for you situation far better 
than I do but it sounds to me like they are trying too hard in one area 
and have missed a bunch of other threats.


Akoulov, Alexandre [IT] wrote:
>  Hi all
>  I have a problem that's been raised by my security team to do with using Tomcat JDBCRealms.
We're using such realms to protect restricted resources. We also have a custom login form.
The steps Tomcat seems to follow when using such a setup is:
>  1. Check to see if the user is logged in with access to the restricted resource.
>  2. If they aren't, forward them to the login page and create an HTTPSession to keep
track of that user.
>  3. Once they've logged in, add the authentication system to the HTTPSession created
in step 2 to hold that info and forward them to the resource.
>  4. Continue using the same HTTPSession to maintain state.
>  The problem my security team has with this is that someone could potentially steal the
users HTTPSession ID before they've logged in, as this is created in the login screen. e.g.
the user is forwarded to the login screen, then goes to make themselves a cup of coffee. A
hacker goes to their computer and writes down the session ID. The user comes back and logs
in, and the hacker pretends to be them from another computer.
>  My question is: how can I avoid this situation and keep the security guys happy? Is
it possible to have the session ID held by the browser (in JSessionID) change post-login (ie
make tomcat invalidate the current session and create a new session after the user has been
successfully authenticated)?
>  Thanks for your help.

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

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

View raw message