Just a word about associating a given session to one IP address, it
works alright and sure is a security enhancement - not sure though if
there are built-in support for that in tomcat though it can be
implemented at application layer. The major drawback of doing so
depends of your user's ISP IPs management i.e. some will change IP
addresses quite frequently thus causing them to loose their session
each time they'll be switched to a different IP. One would also have
to think of network's artefacts such as proxies that may be shared by
many users on customer's end - together with your own network
architecture that may also prevent you from retrieving correctly
originating IPs - re latest posts on "request.getRemoteAddr() vs.
request.getHeader("REMOTE_ADDR")"- Joseph On Fri, Mar 13, 2009 at 12:18 PM, Peter Crowther <peter.crowt...@melandra.com> wrote: >> From: Pieter Temmerman [mailto:ptemmerman....@sadiel.es] >> I don't know. It just seemed way to easy to hijack a session, so I >> supposed it must be secure. > > Large portions of the web architecture are insecure by their original design. > This makes security in web-based systems... erm.. "a challenge" :-). > >> In my case cookies are created as well. > > OK. So why not rely entirely on the cookie rather than exposing the > JSESSIONID in the URL at all? Or (most likely) have I got the wrong end of > the stick here? > >> By SSL, I suppose you mean client authentication with a certificate? > > No, I mean securing the connection by using https: rather than http:. > Entirely server-side. At least that way, someone with a wiretap can't steal > your session IDs off the wire. There's still a long way to go before you can > prevent a different person using a different client from using a session ID > that they happen to have obtained via (say) an eavesdropping plug-in on the > user's browser, but it's a good start. > > Something to think about: No security will be 100%, not least because there > are users involved and they're really remarkably good at leaving massive > security holes in any technological solution - emailing their password to a > colleague's Hotmail account, writing down login details on a Post-It or just > leaving their computer unlocked as they nip to the loo. What security is > "good enough" for your application? > > - Peter > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
