As a workaround, you can simply roll-your-own session IDs instead of using
the JRun ones. This will also make your applications more portable.
Kevin Spett
SPI Labs
http://www.spidynamics.com/
----- Original Message -----
From: "Christoph Schnidrig" <christoph.schnidrig (at) csnc (dot) ch [email concealed]>
To: <bugtraq (at) securityfocus (dot) com [email concealed]>
Sent: Friday, February 28, 2003 9:35 AM
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
>
>
>
the JRun ones. This will also make your applications more portable.
Kevin Spett
SPI Labs
http://www.spidynamics.com/
----- Original Message -----
From: "Christoph Schnidrig" <christoph.schnidrig (at) csnc (dot) ch [email concealed]>
To: <bugtraq (at) securityfocus (dot) com [email concealed]>
Sent: Friday, February 28, 2003 9:35 AM
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 ]