Servlet Session security

[A]

To identify a request urlB as belonging to the same clientX who sent
request urlA, request to urlA must supply the session id which was given to
it by the server in any number of ways
FORM hidden fields, session id in the querystring or with cookies

My question is this:
if a client Y manages to find the session id by which ever way, it should
not be so difficult to pretend to be clientX and attach to clientX's
httpsession on the server... Probably one way to kind of protect against
this would be to associate sessionid and ip and deny access to anyother ip
trying to access the session... but how do popular servelet containers,
j2ee servers handle this ?

This mystifies me- perhaps its something simple but I cant figure it out.
On yahoo for instance if I login to my mail.yahoo.com but then type in
another url in the yahoo domain, say yp.yahoo.com,
(with cookies turned off, with no session id being sent to the server
through the url) it still identifies me and greets me by my id.

How does the server know to find my name in my authenticated session and
serve a personalized page ?

Thanks

 

[mgungora]

It's done by an "authentication cookie". The usual method is, the
server creates a "ticket" when you login in and stores it in a cookie
for all your same-domain requests from the same machine.

 

[Juha Laiho]

if a client Y manages to find the session id by which ever way, it should
not be so difficult to pretend to be clientX and attach to clientX's
httpsession on the server... Probably one way to kind of protect against
this would be to associate sessionid and ip and deny access to anyother ip
trying to access the session... but how do popular servelet containers,
j2ee servers handle this ?

.... but binding session id to the connection source IP is problematic,
because:
- client address can change between two successive requests (DHCP
re-negotiation with address renewal)
- client can use a clustered proxy, which shows as a bunch of
source addresses

.... and thus, it is deemed that just making it hard enough to guess the
session id is enough. SSL (with trusted server certificate) is used when
server non-repudiation and content trustworthiness/secrecy are desired.
SSL wil also protect the content of session ids over the network (but
of course not on the client).

This mystifies me- perhaps its something simple but I cant figure it out.
On yahoo for instance if I login to my mail.yahoo.com but then type in
another url in the yahoo domain, say yp.yahoo.com,
(with cookies turned off, with no session id being sent to the server
through the url) it still identifies me and greets me by my id.

How does the server know to find my name in my authenticated session and
serve a personalized page ?

Hmm.. SSL connection can well have a session id (mostly to avoid costly
SSL session re-negotiation for each request), which is invisible at the
HTTP level (but still usable on the server side) - if mail.yahoo.com is
SSL-protected, that is; I didn't check.