tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Stavrinides <p.stavrini...@albourne.com>
Subject Re: session hijacking again
Date Mon, 29 Jan 2007 08:00:01 GMT
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).

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.

John Caron wrote:
> Hello:
>
> Our application is serving large amounts of scientific data over HTTP. 
> The user needs to login to access the data. We would like to use 
> session ids to reduce the login overhead. We cant afford the overhead 
> of HTTPS encryption of teh data (3 times slower ?). We realize this 
> makes us vulnerable to session hijacking. Still, we arent transferring 
> financial information, so tentatively we think its a reasonable risk.
>
> The Wikipedia article (http://en.wikipedia.org/wiki/Session_hijacking) 
> suggest a couple of things that help, that seem reasonable to me:
>
> # Some services make secondary checks against the identity of the 
> user. For example, a web server could check with each request made 
> that the IP address of the user matched the one last used during that 
> session. This does not prevent attacks by somebody who shares the same 
> IP address, however, and could be frustrating for users who's IP 
> address is liable to change during a browsing session.
>
> # Alternatively, some services will change the value of the cookie 
> with each and every request. This dramatically reduces the window in 
> which an attacker can operate and makes it easy to identify whether an 
> attack has taken place, but can cause other technical problems (for 
> example, preventing the back button from working properly, on the web).
>
> I would like to implement one or both of these in Tomcat: 1) IP 
> checking and 2) session id switching. I guess others have thought 
> about this. Does anyone have any advice or pointers (or code!) to get 
> started.
>
> Thanks for any help.
>
> John Caron
> Unidata/UCAR
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>

-- 
Peter Stavrinides
Albourne Partners (Cyprus) Ltd
Tel: +357 22 750652 

If you are not an intended recipient of this e-mail, please notify the sender, delete it and
do not read, act upon, print, disclose, copy, retain or redistribute it. Please visit http://www.albourne.com/email.html
for important additional terms relating to this e-mail. 



---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message