On Fri, Feb 23, 2001 at 03:26:16PM -, Magns r Torfason wrote:
My theoretical scenario was:
The session ID is NOT cryptographically secure.
The attacker enters the url for turbine (ssl or not)and gets back a session
ID.
He then tries different subtle variations on the session ID, and
But Tomcat could use the source IP to generate the cookie, so from a
different machine it will not work. I can't test right now.
No it can't the IP is not one per session,
it may be many IPs per session (ala AOL), it may be many sessions
per IP (ala firewall or proxy)
So the session
So the session cookie/url parameter,
jsessionid=To1015mC3809102659238063At
must be cryptographically secure, and then you are safe
(unless someone is
intercepting your requests, which pretty much dwarfs this
sessions stuff,
since he can then just steal your password)
Is the
So the session cookie/url parameter,
jsessionid=To1015mC3809102659238063At
must be cryptographically secure, and then you are safe
(unless someone is
intercepting your requests, which pretty much dwarfs this
sessions stuff,
since he can then just steal your password)
I don't think this makes any difference, unless the
id encodes some information that is specific to the
computer that initiated the session. Someone mentioned
IP address, but that is not really unique (for example,
not behind a proxy). So, if the id doesn't encode
anything unique to
[snip]
But my theoretical scenario was: the session id is sent
back to the browser in the URL; the attacker is seating
close by, reads it off the URL (or cuts/pastes it, whatever)
and uses it from their own browser.
My theoretical scenario was:
The session ID is NOT cryptographically
This may show my ignorance; here it goes...
When a user visits a Turbine app, Turbine
creates a session for the user, and sends
the user an opaque identifier for the session
(in the shape of a cookie or a URL parameter).
Say it is a URL parameter, for simplicity.
How easy would it be for another
Diethelm Guallar, Gonzalo wrote:
This may show my ignorance; here it goes...
When a user visits a Turbine app, Turbine
creates a session for the user, and sends
the user an opaque identifier for the session
(in the shape of a cookie or a URL parameter).
Say it is a URL parameter, for
From: Diethelm Guallar, Gonzalo [mailto:[EMAIL PROTECTED]]
Sent: Thursday, February 22, 2001 3:32 PM
This may show my ignorance; here it goes...
When a user visits a Turbine app, Turbine
creates a session for the user, and sends
the user an opaque identifier for the session
(in the
on 2/22/01 3:31 PM, "Diethelm Guallar, Gonzalo" [EMAIL PROTECTED]
wrote:
When a user visits a Turbine app, Turbine
creates a session for the user, and sends
the user an opaque identifier for the session
(in the shape of a cookie or a URL parameter).
No. Turbine does not create this value.
Turbine is not capable of preventing such an attack. I have heard of
solutions that essentially have a second id that varies with every
request. It is possible to do something like this in an application
built from Turbine, but it needs to be built into every request/response
so I guess
The session ID is a servlet engine level entity
it is not set by turbine..
But the hijacking you speak of is totaly possible
and there is nothing to stop it..
There is not enough other information available
from the client in the http request to ensure
that the client is the same entity that
On Thu, 22 Feb 2001, you wrote:
This may show my ignorance; here it goes...
When a user visits a Turbine app, Turbine
creates a session for the user, and sends
the user an opaque identifier for the session
(in the shape of a cookie or a URL parameter).
Say it is a URL parameter, for
But Tomcat could use the source IP to generate the cookie, so from a
different machine it will not work. I can't test right now.
No it can't the IP is not one per session,
it may be many IPs per session (ala AOL), it may be many sessions
per IP (ala firewall or proxy)
14 matches
Mail list logo
