Return-Path: Mailing-List: contact tomcat-user-help@jakarta.apache.org; run by ezmlm Delivered-To: mailing list tomcat-user@jakarta.apache.org Received: (qmail 66452 invoked from network); 14 Aug 2000 20:13:53 -0000 Received: from unknown (HELO blade.dmz.xxitech.com) (216.230.85.139) by locus.apache.org with SMTP; 14 Aug 2000 20:13:53 -0000 Received: from ishta (barbarossa.2ndwaveinc.com [216.136.51.151]) by blade.dmz.xxitech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id QTVH26ND; Mon, 14 Aug 2000 15:22:27 -0500 From: "Dan Kirkpatrick" To: Subject: RE: [Q] Session invalidation and authentication mechanism Date: Mon, 14 Aug 2000 15:12:56 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <20000814105731.14113.qmail@web4402.mail.yahoo.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N This method is still open to an attack where the attacker hijacks the session from a valid user. Many servlet engines use a predictable method of creating the session ID, and thus one user can infer future session IDs based upon the session ID originally given to them. A simple edit of their cookie and they have now hijacked another user's session. Another approach that should be used is that the IP address of the user should be stored server-side. Future requests should check that the user IP address matches the address stored server-side. If they don't match, the session has been hijacked. -dan -----Original Message----- From: java program [mailto:asdf834@yahoo.com] Sent: Monday, August 14, 2000 3:58 AM To: tomcat-user@jakarta.apache.org Subject: Re: [Q] Session invalidation and authentication mechanism Hello Is it a good way of doing authentication? I make authentication with database for userid/password, if in session some attribute is not set. like "user.logged" and each entry point has to check this before continue. Is it a good way of doing authentication? In My case I don't have to invalidate complete session but only that attribute. offcourse I will assume that my application will run under SSL etc., which still I have to check. comments!!! /uma asdf834@yahoo.com --- Luke Taylor wrote: > Basically the question is how are the session and > authentication data > linked (or are they)? > > I've set up a web application which has various > security constraints > configured in the web.xml file and I use basic > authentication to login. > At a later stage I want to logout and I click on a > link that gets a > servlet to invalidate() the user session. The > problem is that I can > still access pages which are protected and the > browser doesn't ask me > to login again. I would have expected the security > information to be > linked to the session object, and indeed the user > principal object is > no longer there when I subsequently call > getUserPrincipal() (during > another logout attempt)... > > Anyone any ideas? > > Luke. > > > -- > Luke Taylor. > PGP Key ID: 0x57E9523C __________________________________________________ Do You Yahoo!? Yahoo! Mail  Free email you can access from anywhere! http://mail.yahoo.com/