Christopher L Merrill [EMAIL PROTECTED] wrote: > [EMAIL PROTECTED] wrote: > >That JSESSIONID are you putting that in the URL or in a cookie. So if > >you put it in a URL its not > >secure and can never be secure and I can hack you with ethereal but if > > The session ID in a cookie is equally as vulnerable as in the URL.
As Christopher points out, this is very true. For most people skilled enough to use ethereal or some other packet capture tool to snoop on session IDs, it's no more work to forge a cookie in the HTTP headers than it is to modify the query string on the request URL. The only ways to really protect against session hijacking is to run every single request through SSL or to conduct the request only with servers where you and the server both share a trusted network. The obvious disadvantage with running every request through SSL is that it places additional load on the server to handle encryption for each request. This can be offloaded, however, to an SSL accelerator. Go to google and search for "SSL accelerator card" and you'll get thousands of matches. Another, less expensive method to minimize the CPU cost is to offload images to a different domain name. Keep in mind that the browser will want to include the cookie information for anything in the same domain. Once the browser receieves the HTML, it will download all the images. If any one of those images specifies http:// instead of just being a relative path (with no protcol specified) or being an explicit https://, the request for the image will be transmitted in plain text. Since the image is in the same domain, the browser will try and be "helpful" by including the cookie information (which honestly, you might want, since the session information may help you determine if the user has permissions to see said image). If you offload your images to a different domain, you will have to make certain that it cannot be seen as a subdomain. If you have set a cookie for "foo.com" and then get your images from "images.foo.com", the browser will probably still include the cookie information for "foo.com". You can solve this problem by always having a third level domain name. Thus, you could have "bar.foo.com" for all your SSL encrypted session data and you could use "images.foo.com" for the non-encrypted images. Since they are peer level domains, the browser will keep the cookies data separate. So, this method could save you the cost of an SSL accelerator, but there is a slight drawback. Most browsers will throw a scary message up for the user, informing them that the page contains some secure items and some non-secure items. As one last point, I do want to mention that using cookies for session ID's is still more secure than using the URL. It's true that there is no difference between the difficulty of using packet capture data (with a tool like ethereal) to hijack a URL session ID or a cookie session ID. The big difference comes when the user goes and visits another site. If the session ID is in the URL, the browser is probably going to pass it to the next site in the Http-Referrer header. An unscrupulous website administrator could then sit and watch for any session IDs from websites that look interesting and then go browse around a session that is probably no longer in use by the original user but has not yet expired. To top it all off, many browsers will send the Http-Referrer even if the user has simply typed in a new URL. It is not necessary for them to click on a link from within your application. With all this said, though, very few sites are using SSL accelerators or even running everything through SSL. There is just too much traffic on the web for there to be any high likelihood that someone will pick your application as the one they wish to target. As a compromise, I recommend requiring SSL sessions for users that have priviliges of any significance (an administrator, moderator, power user, etc). For the run of the mill user, on the average web application, the damage done when a session gets hijacked is pretty minimal. If you have an application that handles credit cards or financial transactions on the behalf on the average user, that is where you should consider SSL for even the most basic user sessions. Anyhow, there's my diatribe for the evening. Hopefully it has been useful to someone. Kind regards, Justis Peters _______________________________________________ Juglist mailing list [email protected] http://trijug.org/mailman/listinfo/juglist_trijug.org
