Mailing-List: contact tomcat-user-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <tomcat-user@jakarta.apache.org>
Received-SPF: neutral (asf.osuosl.org: local policy)
Message-ID: <42DA8C24.20603@apache.org>
Date: Sun, 17 Jul 2005 17:49:40 +0100
From: Mark Thomas <markt@apache.org>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
MIME-Version: 1.0
To: Tomcat Users List <tomcat-user@jakarta.apache.org>
Subject: Re: Tomcat security realms question
References: <1F78B75C252B574FBC551990AE8A8367023CECE0@exsymb02.aus.nsroot.net>
In-Reply-To: 
 <1F78B75C252B574FBC551990AE8A8367023CECE0@exsymb02.aus.nsroot.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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 
machine?"

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.

Mark

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: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org