That's right, and it wouldn't seem that just encrypting the sessionID would
do much good, because a session hijacker could just send back the same
encrypted ID. It seems that there needs to be an applet running on the
client that could take the encrypted sessionID, then use a key to re-encrypt
it in such a way that the server could recognize it came from the intended
recipient. Any ideas?
Thanks, Brian
> -----Original Message-----
> From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
> Sent: Saturday, January 22, 2000 8:58 AM
> To: [EMAIL PROTECTED]
> Subject: Re: URL rewritting and security
>
>
> Martin Leboeuf wrote:
>
> > Hi !
> >
> > I have been following the discussion about session
> management ( amongst
> > others ) and I just thought about something : if I
> understand correctly, one
> > can implement session management through URL rewritting
> which, in a word,
> > does nothing more than adding the session ID to the URL in
> the form of a
> > query string.
>
> Using a query string is one possibility; there are other
> techniques as well. But
> they all rely on modifying the actual URL in some fashion
> that the servlet
> container can recognize on the next request, and pull out the
> desired session ID.
>
> > My question : this means that someone could intercept a
> > request (or just take a peak at the browser ), and use the
> session ID to
> > interfere this session.
>
> Yes, they can -- if the session is still active when they do
> so. Servlet
> containers try to make it difficult to guess what a valid
> session ID will be for
> new sessions, but if you can snoop the TCP socket, you can
> certainly grab the
> current one.
>
> > Doesn't that pose a security problem ? Or am I
> > missing something obvious here ?
> >
>
> Yes, it does pose a security problem. Of course, so does
> using cookies for
> session management -- the fact that the cookie values are not
> visible to the
> casual observer is hardly a challenge for someone determined
> to hack your session,
> because the cookies themselves are sent on every request.
>
> If you do not want to be hacked in this way, you should run
> inside an intranet
> protected by strong firewalls (still doesn't protect you from
> attacks inside your
> network), or run on encrypted connections such as SSL. The
> advantage of the
> latter is that you can encrypt all data, not just the session
> id stuff. The
> disadvantages include the complexity (and cost) of setting it
> up, and the
> performance overhead of performing the encryption.
>
> >
> > Thanks, Martin
> > [EMAIL PROTECTED]
> >
>
> Craig McClanahan
>
> ==============================================================
> =============
> To unsubscribe: mailto [EMAIL PROTECTED] with body:
> "signoff JSP-INTEREST".
> FAQs on JSP can be found at:
> http://java.sun.com/products/jsp/faq.html
> http://www.esperanto.org.nz/jsp/jspfaq.html
>
===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
FAQs on JSP can be found at:
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.html
