Security concerns over URL

[Mike W-M <mi...@ward-murphy.co.uk>]

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:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Security concerns over URL

[Tim Funk <fu...@joedog.org>]

If you are using SSL - everything is encrypted across the wire. No problems.

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:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>