tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Caron <>
Subject Re: session hijacking again
Date Mon, 29 Jan 2007 20:17:52 GMT
Hi Peter:

Peter Stavrinides wrote:
> Do you use Java?


> We are a financial institution, we use a Java Framework based on 
> servlets with SSL, but if you ask my opinion SSL is not the big issue. 
> The vast majority of hacked sites are social engineering attacks. Secure 
> your database (do not store clear text passwords in the database) 
> minimize access of staff, require strong passwords (8 characters and 
> numbers). No strategy or amount of code is foolproof, although yes It is 
> also worth the extra effort to make your application a bit smart, but it 
> is better to focus your attention on preventing social engineering, 
> because no matter how clever you make it if the passwords are easily 
> guessed or users careless its all for nothing.
> Design your application like a container that reloads its body, that way 
> you can implement security and logging application wide with minimal code.
> We secure our application like this: on login (after authentication) we 
> store in state for the duration of that session, the users unique id and 
> session id and for logging purposes the current IP. (no cookies etc are 
> used at all, because cookies are stored on the client which is out of 
> our control).

doesnt the client have to return a jsessionid cookie?

> We perform a check for each new login to ensure at least the user id and 
> session id does NOT exist in state before allowing the new login. We do 
> not allow two concurrent logins with the same account.
> If you wish to implement session id switching you have to destroy the 
> users old session and recreate it and update the session id in state (to 
> me again, just my humble opinion, not so important)... it is far more 
> useful to use a session timer that times out after a few minutes of 
> inactivity, it will automatically call a sign out but you can keep the 
> users details in the server state until the browser closes, if they try 
> to continue activity, then you ask them to sign in again and add their 
> new session id back into your state object. When the browser closes a 
> session listener cleans out the session so the users details are discarded.
> Again paranoid coding is not going to prevent social engineering, 
> educating users might... by far the most effective strategy is to tell 
> users to never give out their password, give them a support number and 
> inform them about what the support personnel is and isn't allowed to ask 
> them for. Lastly tell users exactly what type of email they will and 
> won't receive from your organization. When they login to your site tell 
> them they should ALWAYS check that the domain name appears correctly in 
> the address bar.

thank you very much for your advice, i will use it!


To start a new topic, e-mail:
To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message