Hi Christoph, I'm sure you know this but as the author of the session fixation paper I'd like to make things perfectly clear for everyone: The JRun functionality that you mentioned is *NOT* a security problem by itself. There has to exist a session fixation vulnerability in a web application to be exploited using this functionality in the first place! You're right that it makes fixing a session much easier but it's just an unfortunate side effect. Again, if the web application is immune to session fixation, your ability to set a session ID cookie becomes completely irrelevant to security. Session fixation is a vulnerability of web applications, not the web servers these apps are running on. Apologies to everyone for repeating myself, but my paper seems to have caused a bit of confusion among readers. To answer one of your questions, you can make a call to session.invalidate() for invalidating any current session the browser may be in. This will make JRun issue a new JSESSIONID cookie. Regards, Mitja Kolsek ACROS Security http://www.acros.si > -----Original Message----- > From: Christoph Schnidrig [mailto:christoph.schnidrig@csnc.ch] > Sent: Friday, February 28, 2003 3:36 PM > To: bugtraq@securityfocus.com > Subject: JRun: The Easiness of Session Fixation > > > Hi all > > The the Session-ID Fixation paper available from > http://www.acros.si/papers/session_fixation.pdf mentions that JRun > accepts abritrary Session-ID's and create new sessions with the proposed > Session-ID. This means that it is possible to send the following URL > http://foo/bar?jsessionid=foo123 and the JRun server will accept and use > the proposed Session-ID (foo123). Furthermore the server will set a > cookie in users browser with the proposed Session-ID! Using this > technique, it is much easier to exploit this kind of attack and to enter > in other's web application sessions. > > Is anybody aware of a vendor patch or another workaround? Is it possible > to enforce the server to create a new Session-ID? > > > Thanks a lot > > Christoph > >
