Mitigating security holes with HttpOnly cookies

Avoiding cross site scripting is a full time job. The more you let your users do the more likely you will have a security whole. Thankfuly Django makes closing some of the more obvious gaps in site security as easy as installing a middleware (well, almost). The CSRF middleware inserts a token into every form on the site and then validates any post requests to make sure it's coming from the site itself rather than a remote site (which won't have the tokens). That is, as long as you make sure to require every state changing request to use POST.

Another problem comes from the chance that a user might be able to inject javascript into a page. At this point they have nearly full control over a users browser that visits that page. There is a way to limit the damage and that is to send all cookies with the HttpOnly attribute. The attribute means that the cookie will only be sent to the server and can not be accessed by client side javascript. So the malicious script on the page can still perform actions on the user's behalf but it can not get the session id.

IE was the first to implement the HttpOnly attribute, and until recently it was the only browser to do so. Fortunately, Opera 9.5 (currently in alpha) and Firefox now both have it (though not in the latest stable releases). Now it's just older browsers and Safari that need to catch up.

Unfortunately, the cookie module that comes with Python does not support/understand/allow the HttpOnly attribute, but to work around this in Django is as easy as creating a middleware with the following bit of code in the process_response method:

sessionid = response.cookies.pop('sessionid', None)
if sessionid:
    cookie = sessionid.output(header="").strip()
    response["Set-Cookie"] = cookie + "; HttpOnly"

The HttpOnly attribute for cookies is just one small part of covering your ass when it comes to site security. All it does is lessen the risk. Security is always only as good as the weakest link in the chain.