[patch] Support "httponly"-attribute in session cookie.

[arvin]

The cookie used for the session id should get the "httponly"-attribute to mitigate XSS.
See ​http://msdn.microsoft.com/workshop/author/dhtml/httponly_cookies.asp.

[Simon Willison]

I've always wondered if there's a downside to doing this - it seems like a great idea, but you rarely see sites actually doing it. It should definitely be possible to do this from Django, but I'd like confirmation that it doesn't break things for some browsers / proxies / what have you before recommending it be turned on by default. As far as I can tell it breaks the cookie spec (if such a thing exists).

[arvin]

You are right that only few site use it, e.g. time.com. Maybe because most tools
don't support it yet. PHP has it only since 5.2.0, Python doesn't have it so far.

The cookie spec is here:
​http://wp.netscape.com/newsref/std/cookie_spec.html
​http://www.faqs.org/rfcs/rfc2109.html

Firefox will likely have support in the far future:
​https://bugzilla.mozilla.org/show_bug.cgi?id=178993

I'll attach two patches, one for python and one for django. With those it works for me
with the development server. Since I'm new to django I might miss something.

[arvin]

Patch for python

[arvin]

Patch for django

[arvin]

Of course enabling SESSION_COOKIE_HTTPONLY without the python patch breaks the
system. If the patches look good to you I will send the python patch to the
project.

[(none)]

Milestone Version 1.0 deleted

[mir@…]

Hmm, we probably can't use a patch that requires a patched python. Any different solution?

Also, could you point me to where the RFC is talking about 'httponly'? I couldn't find it at all. According to the specs from the Microsoft site, it makes the cookie unavailable to script languages.

[James Bennett]

It's worth noting that IE is the only browser likely to support this in the foreseeable future; the bug for it at Mozilla is still marked as NEW nearly four years after opening, and no-one seems to know what other vendors will do.

[arvin]

Replying to mir@noris.de:

Hmm, we probably can't use a patch that requires a patched python. Any different solution?

Surely Python itself has to be extended. In Django we can check sys.hexversion and write that
the feature only works with e.g. python 2.6 or higher.

Also, could you point me to where the RFC is talking about 'httponly'? I couldn't find it at all. According to the specs from the Microsoft site, it makes the cookie unavailable to script languages.

The RFC doesn't talk about 'httponly'. Microsoft introduced it later on.

The attribute makes the cookie unavailable to scripts in the browser, e.g. Javascript injected
through XSS.

[cephelo@…]

patch for supporting HttpOnly in cookies/session

[cephelo@…]

HttpOnly cookie docs

[cephelo@…]

I've attached two new patches. The first is a patch to the Django sources that wraps the Python Cookie.py objects with very minimal wrappers. They merely intercept the HttpOnly flag and work with it, the rest is handled as before with Cookie/Morsel and SimpleCookie. It provides a SESSION_HTTP_ONLY setting True/False/None. It also provides the hook in HttpResponse.set_cookie(..., httponly=True). The second setting updates the docs/.

Firefox 3.0 will have it, it's working in 3.0a3, as I just tested my patch with. Also works fine in IE7.

Mozilla Bugzilla: ​https://bugzilla.mozilla.org/show_bug.cgi?id=178993

[anonymous]

Opera 9.50a1 also supports HttpOnly: ​http://snapshot.opera.com/windows/w950a1.html.

[Jacob]

Hacking around the Python Cookie objects just gives off that "code smell" to me, and I'm reluctant to check in smelly code to support a non-standard addition to HTTP.

Still, added security is always a good thing, so I'm pretty conflicted about this one. For now I'm going to mark this "somday/maybe" and move on, but a better patch would help move this back towards reality.

[mrts]

This looks not to be in scope for 1.0.

[Julian Bez]

​http://www.codinghorror.com/blog/archives/001167.html

[mattrussell]

Just to note the Python 2.6rc1 adds support for httplonly in Cookie.Morsel

[(none)]

Milestone post-1.0 deleted

[rodolfo]

patch to add "httponly" with Python 2.6 (with 2.5 doesn't work, but doesn't show error). Docs are the same attached by cephelo.

[Craig Younkins]

For more security information and browser support table:
​http://www.owasp.org/index.php/HTTPOnly

Also, did I just see a BasicAuth dialog for Trac? Whew, I sure hope not...

[rodolfo]

I re-updated a patch, now with docs. This patch works on older python versions (2.3-2.5) and a python's patch isn't needed.

This is a feature to "contrib" (sessions are on contrib), not to "core", then don't have problems with ​http://docs.djangoproject.com/en/dev/faq/install/#do-i-lose-anything-by-using-python-2-3-versus-newer-python-versions-such-as-python-2-5

[anonymous]

The Firefox bug has been fixed, so it now supports HTTP-only cookies.

[rodolfo]

Is possible solve it with a middleware: ​http://www.djangosnippets.org/snippets/1983/

[jcrocholl]

Here's a simple Django middleware for HttpOnly cookies that works on Python 2.5:

​http://code.google.com/p/pageforest/source/browse/appengine/utils/cookies.py

[André Cruz]

The support in python has been added, what's stopping django from using it when it's available?

It's such a simple change and the security benefits are obvious...

[James Socol]

We (Mozilla) would love to see this patch get onto the 1.2.x branch.

[Russell Keith-Magee]

@jsocol: This can't get onto the 1.2.X branch, because that branch is in support mode, and this would represent a new feature. However, it can be considered for inclusion in trunk, which will become 1.3.

The landscape seems to have changed a bit since Jacob "someday/maybe"d this three years ago; I'm happy to push this to accepted now, based on the existence of native Python support, and the ​apparent level of browser support.

As the ticket metadata indicates, the patch also requires tests. This is particularly important since we're introducing a workaround for Python 2.5 and previous.

[André Cruz]

This being a new feature is highly debatable. It doesn't add anything, but prevents a security problem. It seems more like a security fix.

[Russell Keith-Magee]

@edevil -- No, it's not even slightly debatable. It adds a new setting and a new argument where one didn't exist previously. It provides functionality that didn't exist previously.

The functionality it is adding may be desirable, but it doesn't change the fact that it's new functionality.

It's also not something covered by out security fix policy. While HTTP-only cookies will prevent a certain class of attack from being possible, there is no evidence of an in-theory or an in-practice actual attack on code for which the Django project itself is responsible. If you can demonstrate that (for example) every Django admin site is vulnerable because of the non-use of HTTP-only cookies, *that* would be a security issue triggering a security release. The fact that it is possible to build a site that would be vulnerable to an attack that would be prevented by the use of HTTP-only cookies does not make this a security issue for Django as a project.

Sidebar: if you find such an attack, it should be reported to security@….

[Craig Younkins]

"While HTTP-only cookies will prevent a certain class of attack from being possible, there is no evidence of an in-theory or an in-practice actual attack on code for which the Django project itself is responsible."

This comment represents a serious flaw in the way Django developers are handling security. Django is a key part of any user-created applications, and thus the security of user applications is intertwined with the security of Django.

Does Django have a vulnerability? No. Is Django empowering users to secure their apps? No. And I think it should.

Django developers need to develop a sense of responsibility for the security of user applications. The responsibility is not Django's alone of course, and certainly the developer is also to blame, but framework developers need to provide usable security controls to aid users.

[Luke Plant]

Replying to cyounkins:

Does Django have a vulnerability? No. Is Django empowering users to secure their apps? No. And I think it should.

We absolutely agree, and have consistently sought to do just that - we have excellent out-of-the-box behaviour and APIs for all kinds of security issues. Russell's comment was about whether this feature should be backported to our bug fix branch or not. The answer is it shouldn't, as it is a new feature, and it is not a "security issue" in the sense that is relevant for our policy regarding backporting security fixes. But we do want to add it to trunk, and would do so much quicker if a patch appeared that addressed the current deficiencies - namely the need for tests. The patch also needs to be updated for [12282] AFAICS.

[Russell Keith-Magee]

(In [14707]) Fixed #3304 -- Added support for HTTPOnly cookies. Thanks to arvin for the suggestion, and rodolfo for the draft patch.