If you are worried about someone stealing the session id by (visual) site - make sure your application runs in a browser window where the URL cannot be diplayed.
AFAIK - session ids are generated in such a way that they can't be guessed. But this is really servlet container dependent - so an idiot could in theory implement the servlet API and make the session ids sequential numbers.
-Tim
Mike W-M wrote:
Apologies if this has all been asked / answered before (in fact I hope it has, and a pointer to previous info would be great!), but I'm looking for a little reassurance on some security concerns. Okay....I have a web-application for which I'm using form-based login to authenticate the user. It's running over HTTPS / SSL. When I fire up my browser and enter a URL requesting a resource that falls within the application's secured area, I'm being correctly redirected to the login page. I've noticed that I'm picking up a "jsessionid" as part of the URL at this point. I've also found that after I've successfully logged-in, I can go to another machine, fire up a browser and get immediate access (i.e. no login required) to a protected resource if I enter its URL and append the previous ";jsessionid=....." string. So my issues are: a) I'm only slightly concerned that someone will look over someone else's shoulder and make a note of the jsessionid string, since it'd be easier to watch their fingers than make a note of a 32-character string. (Then again, if you've got a digital camera with a zoom lens - or a photographic memory - it'd be easier to note the id.) My major concern here is that because this string forms a part of the URL it could be read as it passes over the network. I've done some Google-based research and have come to the conclusion that if I'm running over SSL/TLS then the string has probably been encrypted. (This is only a vague conclusion, though: statements like (I paraphrase) "SSL is independent of the protocol running on top of it" reassure me, but newsgroup discussions push me the other way.) However, I think I did see (in an SSL faq?) mention of proxies, caches, the SOCKS(?) protocol, tunnelling, and - particular worrying in this scenario - one other protocol that allows https requests to be logged or filtered or something, because the request data was transmitted unencrypted. Now if this url is ever transmitted in the clear, then I think there's a big security issue..... b) I remember - years ago - having read someone criticise a web-container because the session-ids were "predictable". Are Tomcat's session-ids "predictable"? i.e. If I were to get myself one of these session-id strings by asking for a protected resource (but not being able to logon because I don't have a username and password), what are the odds I could have a good guess at the previous session-ids that have been allocated and are probably still active? I guess what I was hoping is that a jsessionid would be useless outside of the HTTPS "session" or "connection" that produced it.... Thanks for any help.... Mike.
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
