cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sonny Sukumar" <>
Subject RE: Need Session Help!
Date Thu, 25 Sep 2003 23:16:52 GMT

>From: Tim Olson <>
> > How much overhead does session replication actually cause vs.
> > fetching
> > everything from the database on every request?
>session replication across a cluster can be very expensive because session
>modifications are O(n) where n is the number of nodes.  it's ok if your
>sessions are light, but it could become a network jam with heavy sessions
>and many nodes.

Good point, although we haven't gotten to the stage where we need a web 
cluster (we certainly plan to, however).

The shopping cart is the main thing we store in the session during the 
browsing process, and then much more data is stored in the session during 
the checkout process.  I suppose that's one reason why some of the larger 
e-comm sites have dedicated servers for the checkout process.

> > My concern is that
> > since URL encoding
> > exposes the session ID in plain view, it's as good as
> > compromised despite
> > using SSL to encrypt it once the customer logs in.
> >
> > Was that why you were saying to only use session cookies
> > everywhere?

Ok, I see, but a session cookie is also compromised in a similar manner 
before heading into a protected area where the connection is encrypted.  
Sure, it's not nearly as clearly compromised as with URL encoding, but it is 
still sent in clear text to the server for each request.  I think a Black 
Hat could snatch it during one of these requests and later use it to request 
a protected page.

Presumably, Black Hat couldn't use a standard web browser client to pull 
this off, but it's certainly feasible to write a client app that makes HTTP 
requests with a specified cookie embedded in the request header.  Then the 
returned data could easily be saved and viewed in a regular browser or 
analyzed in some other not-so-sophisticated way.

Which reminds it possible to make certain URIs only accessible over 
an SSL connection?  (Or over a certain port? because we'd know which port is 
the SSL port).  But I'm guessing this wouldn't really do anything to help 
either because Black Hat could just initiate an SSL connection to that port 
anyway, right?

In any case, to solve the problem, is there some way to force the server 
(Tomcat for us) to change the session ID referencing the same session once 
the user logs into a protected area?  This would invalidate the session ID 
that Black Hat stole and not let him make bogus requests to steal sensitive 
session data.

> > --Btw, are there any data indicating how many people surf the
> > web with
> > session cookies off?  I'm only concerned with session cookies
> > (which are
> > only stored in RAM), and not "normal" cookies (which are
> > stored on the hard
> > drive).
>i'd like to see that data too, but i'm sure it's a very small number.  
>anyone who knows how to turn their cookies off knows how to turn them back
>on again.
>even people who set IE6 to a more restrictive privacy setting generally
>still have session cookies enabled.  we get few customer problems that are
>related to cookie use.

Interesting..thanks for this insight.  Our site will be mostly for college 
and young working women, so I don't think they really know much about 
setting/unsetting least I hope they don't.

Thanks again,


Instant message in style with MSN Messenger 6.0. Download it now FREE!

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message