I'm sure preventing multiple people from using the same session ID if the url is emailed or posted is something lots of people would like to prevent.
This is a really odd use case and I can't think of time when it would be advisable to do this (perhaps you can give me one). Unless you have a very good, specific reason, your understanding of sessions may be mistaken.
The point of a session is to store data while a user is interacting with a webapp -- it's tied to one user. Sometime that user is authenticated, sometimes not. If you require users to be authenticated (which I'm assuming since you're concerned with session hijacking), and you want to email a link to a resource that's protected, it makes no sense to bypass that protection when the user clicks on the link. The user who tries to access the resource should go through authentication as well.
I would assume there are good ways of handling it and I'd rather not reinvent the wheel. Are there any best-practices or design patterns to guide someone? Maybe restricting url tracking people to a certain ip range, or within a certain tolerance of other info they send back (browser, some other signature, etc.)?
You're treating the symptoms of a fringe/poor design. Sometimes that's necessary, but hopefully for your sake it's not.
justin
Subject: Re: Tomcat5 and url tracking hijacking From: Tim Funk <[EMAIL PROTECTED]> Date: Tue, 27 Jan 2004 09:41:27 -0500
To: Tomcat Users List <[EMAIL PROTECTED]>
yeah - you'd get that users session. Same problem with cookie hijacking.
Use https.
There is nothing defined by the spec to prevent this. (Except https)
-Tim
Marc Hughes wrote:
Does tomcat 5 use some kind of mechanism to prevent session hijacking when url session tracking is being used? For instance, if someone posts a url to a website with the tracking info in it, will anyone clicking on that link pick up the original user's session (assuming it didn't time out yet)? If it does prevent this, how?
If anyone knows of any articles about keeping sessions safe, I'd love to get pointed to those.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
______________________________________________ Justin Ruthenbeck Software Engineer, NextEngine Inc. justinr - AT - nextengine DOT com Confidential. See: http://www.nextengine.com/confidentiality.php ______________________________________________
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
