If a session's chances of being hijacked are very high because of the same
sessionid going back and forth between client and server,
why not make the send back a sessionid cookie with each response ? and
associate the sessionid with the httpsession.
I can see how it might be a little more processing, but is there anything
inherently flawed in this thinking ?
I'm trying to understand this thing, so its not about having just a super
secure connection, but I'm looking for a cheap way to improve the
security...
mgungora - 14 Jan 2006 22:56 GMT
Haven't tried that myself, but another method would be: associate the
session id with the client's face IP address.
mgungora - 14 Jan 2006 22:58 GMT
Oops, I just read your previous msg where associating IP address was
already mentioned... Sorry...
Roedy Green - 14 Jan 2006 23:45 GMT
>Haven't tried that myself, but another method would be: associate the
>session id with the client's face IP address.
You could of course have many clients coming at you from the same LAN
all sharing the same face IP.

Signature
Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.
josh.s17@gmail.com - 15 Jan 2006 09:58 GMT
The back button is not going to work too well with this approach.
josh.s17@gmail.com - 15 Jan 2006 19:42 GMT
If the site is using https then session's chance of being hijacked
should be minimal as it shouldn't be visible to anything on the
network. This should be secure enough for anyone's needs especially
since the sessionid cookie only lasts as long as the browser is open.