Unless you have any specific reason to access cookies from javascript - it is a good idea to turn on HttpOnly on the cookie to help prevent cross site scripting attacks to send your cookie content elsewhere - have a read of Jeff Atwood's post here: http://www.codinghorror.com/blog/archives/001167.html

On top of this however, there is another setting that is not mentioned, and that is RequireSSL. This will mean that the web browser will only send the cookie to the website if it is requested over SSL. 

The idea of that didn't make much sense to me - since surely the user would need to purposely change it from https to http for this to be an issue, until you consider the following scenario (it still seems like a long shot, but hey):

1) You log in as as administrator on the HTTPS site.
2) The website sets a cookie on your browser with your administrator session token. This is transmitted encrypted for each request back to the website.
3) While your session is open you browse to dodgy website (or directed to it somehow, by the hacker)
4) Dodgy website redirects you to the same site you logged in as an administrator, but using HTTP instead of HTTPS. The site might throw an error at this point saying that it can only be accessed over HTTP but the damage has already been done as per the next point (there might be ways of hiding this web request from the user however).
5) Your administrator session token in the cookie is now submitted across the network in plain text.
6) Dodgy hacker now intercepts this through a man in the middle attack (using ARP poisoning or similar)
7) Hacker now has your administrator session token and can use this to browse the site as yourself. 

Now, I think there are further protections the HTTPS site could make, for example, check that the I.P address & browser user agent remain consistent for a particular session - however it is possible to fake these as well. 

Seems difficult to achieve, but hmm - if you have an HTTPS site, just put the following line in the web.config and you will be right (at least for all browsers that support it):
<httpCookies httpOnlyCookies="true" requireSSL="true"/>

This will set the options on all cookies leaving the site - or you can turn the settings on each cookie individually, or on the FormsAuthentication component like so.

It's an interesting example to think about however, as it gets you thinking about all things security after that.

[Update: It pays to also be aware of XSRF]

When you have forms authentication setup in ASP.NET, you might have a folder containing static content, such as PDF/zip files etc. You might try to protect these files using the following item in the web.config to allow access to authenticated users only:

            <authorization path="PDFFolder">
                  <deny users="?"/>
            </authorization>

This will not work however since IIS serves non ASP.NET file types directly, and will not pass the request through to ASP.NET to carry out any authentication first.

In order to protect all static content in the site (if you have any), you need to setup the following Wildcard application map on the virtual directory to pass all file types through to ASP.NET so that everything is protected:

It is important however that “Verify that file exists” is NOT ticked, since there are some ASP.NET files such as:

• WebResource.axd
• Trace.axd

Which don’t physically exist.

WebResource.axd it seems is responsible from .NET 2 onwards for dishing up ASP.NET framework js files, (in 1/1.1 these were served from the C:\Inetpub\wwwroot\aspnet_client\system_web\1_1_4322 folder)

If it is ticked, you will have missing javascript object errors all over the place (because IIS will scrap the request to WebResource.axd) and may be tempting to incorrectly think the empty C:\Inetpub\wwwroot\aspnet_client\system_web\2_0_50727 folder is where the problem lies.

So there you go.

Also, if you are curious what AXD stands for which of course I was, here it is from the man himself:

“Hi Wouter,

I'm somewhat embarrased to say that I don't think it stands for anything. I think we choose it because it sounded cool, and used the leters a & x -- which we usually incorporate in other file extension names.

Hope this helps!

Scott”