> From: Pieter Temmerman [mailto:[email protected]]
> 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: [email protected]
For additional commands, e-mail: [email protected]
