Regarding difficulty of session hijacking with cookie vs URL session id.
I think in a strict sense, you are correct, in that the added difficulty
does not require work on the order of magnitude more difficult.
However URL's are more commonly available in log files, and more easily
entered by a potential hijacker.
The added difficulty of the cookie approach to security is that the hijacker
needs to find the cookie which is more likely to require sniffing, and then
has to generate a request with the stolen cookie which requires more
advanced knowledge and/or tools than simply typing in a URL that you can see
in a logfile.
But for a determined and reasonably skilled hacker, or a less skilled hacker
with the right tools, SSL would be a much more secure option.
> -----Original Message-----
> From: Randall Randall [mailto:randall@...]
> Sent: Friday, January 03, 2003 4:32 PM
> To: webware-discuss@...
> Subject: Re: [Webware-discuss] Sessions for dumb clients?
> Edmund Lian wrote:
> > On 01/03/2003 04:47:38 PM webware-discuss-admin wrote:
> > >I am looking to have WK be session aware when the
> client side cannot
> > support
> > >Cookies or POSTs (spefically, I am targeting Plucker
> on the Palm OS).
> > Is
> > >this doable/hackable? Ideas?
> > ... is yes. There's a setting in Application.config to turn this on.
> > Be aware however, that having the session encoded in the
> URL makes session
> > hijacking easier, and bookmarking harder.
> In what way does it make session hijacking easier? Sure, if you're
> unencrypted, someone could see the URL session in the traffic as it
> goes by, but the same is true of the _SID_ cookie, isn't it? So it
> would seem that only SSL makes session hijacking hard, and it then
> doesn't matter which one you use for security?
> If this isn't correct, someone please enlighten me.
> Randall Randall <randall@...>
> "[The] poetic justice of cause and effect compels
> respect, compassion." -- Faithless, God is a DJ.
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> Webware-discuss mailing list