Now the debate goes on about Firesheep, here's a good blog post on the ethical aspects. In this post I also found a link to Microsoft's Malware center, their antivirus software apparently detects Firesheep as a hacktool. Like it really matters. Firesheep clones will pop up all over the Internet. The only viable path forward is to build websites not vulnerable to trivial eavesdropping attacks.
Firesheep has raised the bar for baseline security in web applications. Before Firesheep, you would be regarded as sloppy or lazy not to have secured your website's cookies. After the release of Firesheep, you're essentially committing a crime against your users — because now you (and they) know that cookies can easily be stolen.
If you need a basic introduction to what cookies are, check out the cookie article on Wikipedia. The rest of this post discusses more technical aspects of cookie security.
We'll start with the solution. If you're running an ASP.NET site and all the traffic should be served over SSL/TLS, you'll want to add the following configuration to your web.config:
<system.web> <httpCookies httpOnlyCookies="true" requireSSL="true" lockItem="true" /> </system.web>
Include this configuration in the web.config in the application's root directory, to ensure that the cookies you are issuing are secured across your entire site. The httpOnlyCookies configuration helps protect cookies from scripting attacks, while the requireSSL setting fixes the Firesheep problem by marking issued cookies as secure. The lockItem attribute ensures that other web.config's cannot override these settings. Here's the documentation on MSDN.
Read on for an explanation on what this configuration means (yes, you should read this too).
The secure attribute instructs the browser to include the cookie only in requests that are sent over an SSL/TLS connection. In effect the cookie will be missing in requests to addresses starting with http://, but will be included in requests to addresses served over https://. This attribute is read by the browser when the cookie is set, in subsequent requests the secure flag will be included in neither request nor response.
The httpOnlyCookies attribute politely asks the web browser to not share a cookie with scripts or Applets. For session cookies, this attribute should always be true. As with the secure attribute, httpOnly can only be seen when a cookie is set in a response.
Modern browsers will prohibit scripts from reading the cookie value when this attribute is set. If scripts make requests to the web application (ajax) , the browser will still include the cookie in the request, but the script never gets direct access to the cookie's value.
For e.g. a Java applet, the security effect is more notable. Requests initiated by an applet will be sent without the httponly cookie. There are several subtle effects of the httponly attribute on applets, depending on which browser and version is in use. These effects deserve a separate blog post — it's upcoming. Still, enable httpOnlyCookies on your site if you can!
Read more about HttpOnly cookies on the OWASP website.