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 (at) csnc (dot) ch [email concealed]]
> Sent: Friday, February 28, 2003 3:36 PM
> To: bugtraq (at) securityfocus (dot) com [email concealed]
> 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
>
>
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 (at) csnc (dot) ch [email concealed]]
> Sent: Friday, February 28, 2003 3:36 PM
> To: bugtraq (at) securityfocus (dot) com [email concealed]
> 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
>
>
[ reply ]