You should consider security concerns if you don't use a cookie for the session ID, i.e., if you use a technique with URLs like /WK/_SID_=1239872987/SomeServlet_ or /WK/SomeServlet_?_SID_=124987254
If the ID is for a logged in session (i.e. the user has typed a password) and needs to be protected from unauthorized access, you have to be careful of any links on your page that point to other sites. If the user's browser is pointing at:
and the user clicks a link on the page to www.attacker.com/whatever, then the browser will normally send an HTTP GET request to the attacker.com server containing an HTTP REFERER header which has your page's URL including the session ID. The attacker can then use the session ID from the referer header to hijack the user session. If you're running something like a web bbs where attackers can drop their own URL's into messages that they post, they can carry out the attack without you (the foo.bar owner) ever adding any links of your own to the attacker.
The user doesn't even have to be made to click a link. if your page (because of you or the attacker) contains an:
to display an image, the attack happens before the user has a chance to do anything about it. -- PaulRubin?
You can secure against this kind of attack by using a redirect script for all external links. I.e., you replace all links (href and img, perhaps script, style, and link) in all your output. So if you would have had a link like http://www.booger.com/green you'd use /WK/Redirect?site=www.booger.com/green where you install some simple redirect script on your server at /WK/Redirect
Also, you'd get a certain amount of security if you didn't allow people to access a session from a new IP address. You could add the original IP address (from <tt>req.environ()['HOST_ADDR']</tt>) to the session, and check that it's consistent in your SitePage's awake() method. Dialup users who get disconnected will also get trapped by this, and they will curse you (just so you know what you are losing).
Note -- normal dialup users who sit behind transparent proxies will run into this problem a lot.
-- FariedNawaz? - 12 Jul 2002 ]
Followup Note: Transparent proxies can be partly cured with use of X-Forwarded-For header field stating the ip address of user of the proxy, but this field can be faked by attacker, so it is not way out of the problem :(
Lastly, if you use SSL, browsers will typically not allow non-secure content to be loaded without a warning (like an IMG). I'm not sure if secure content from another (potentially malicious) server would be loaded, or what referers are passed from secure connections.