Opened 17 years ago

Closed 13 years ago

#3304 closed enhancement (fixed)

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

Reported by: arvin Owned by: nobody
Component: Core (Other) Version: dev
Severity: normal Keywords: session security
Cc: sam@…, jedie, Jari Pennanen, andy@…, johann@…, james@… Triage Stage: Accepted
Has patch: yes Needs documentation: no
Needs tests: yes Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

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.

Attachments (6)

python.diff (1.1 KB ) - added by arvin 17 years ago.
Patch for python
django.diff (2.3 KB ) - added by arvin 17 years ago.
Patch for django
httponly.patch (3.8 KB ) - added by cephelo@… 17 years ago.
patch for supporting HttpOnly in cookies/session
httponly_docs.patch (2.6 KB ) - added by cephelo@… 17 years ago.
HttpOnly cookie docs
django_p26_patch.diff (2.5 KB ) - added by rodolfo 15 years ago.
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.
django_httponly_patch.diff (5.4 KB ) - added by rodolfo 15 years ago.

Download all attachments as: .zip

Change History (37)

comment:1 by Simon Willison, 17 years ago

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).

comment:2 by arvin, 17 years ago

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.

by arvin, 17 years ago

Attachment: python.diff added

Patch for python

by arvin, 17 years ago

Attachment: django.diff added

Patch for django

comment:3 by arvin, 17 years ago

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

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.

comment:4 by (none), 17 years ago

milestone: Version 1.0

Milestone Version 1.0 deleted

comment:5 by mir@…, 17 years ago

Needs documentation: set
Needs tests: set
Patch needs improvement: set
Triage Stage: UnreviewedDesign decision needed

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.

comment:6 by James Bennett, 17 years ago

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.

in reply to:  5 comment:7 by arvin, 17 years ago

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.

by cephelo@…, 17 years ago

Attachment: httponly.patch added

patch for supporting HttpOnly in cookies/session

by cephelo@…, 17 years ago

Attachment: httponly_docs.patch added

HttpOnly cookie docs

comment:8 by cephelo@…, 17 years ago

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

comment:9 by anonymous, 17 years ago

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

comment:10 by anonymous, 16 years ago

Cc: sam@… added

comment:11 by Jacob, 16 years ago

Triage Stage: Design decision neededSomeday/Maybe

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.

comment:12 by mrts, 16 years ago

milestone: post-1.0

This looks not to be in scope for 1.0.

comment:14 by mattrussell, 16 years ago

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

comment:15 by (none), 15 years ago

milestone: post-1.0

Milestone post-1.0 deleted

by rodolfo, 15 years ago

Attachment: django_p26_patch.diff added

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.

comment:16 by Craig Younkins, 15 years ago

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...

by rodolfo, 15 years ago

Attachment: django_httponly_patch.diff added

comment:17 by rodolfo, 15 years ago

Component: Core frameworkContrib apps
Keywords: session security added
Needs documentation: unset
Patch needs improvement: unset

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

comment:18 by anonymous, 14 years ago

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

comment:19 by jedie, 14 years ago

Cc: jedie added

comment:20 by rodolfo, 14 years ago

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

comment:21 by Jari Pennanen, 14 years ago

Cc: Jari Pennanen added

comment:22 by anonymous, 14 years ago

Cc: andy@… added

comment:23 by jcrocholl, 14 years ago

Cc: johann@… added

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

comment:24 by André Cruz, 14 years ago

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...

comment:25 by James Socol, 13 years ago

Cc: james@… added

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

comment:26 by Russell Keith-Magee, 13 years ago

Component: Contrib appsCore framework
Triage Stage: Someday/MaybeAccepted

@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.

comment:27 by André Cruz, 13 years ago

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.

comment:28 by Russell Keith-Magee, 13 years ago

@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@….

comment:29 by Craig Younkins, 13 years ago

"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.

in reply to:  29 comment:30 by Luke Plant, 13 years ago

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.

comment:31 by Russell Keith-Magee, 13 years ago

Resolution: fixed
Status: newclosed

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

Note: See TracTickets for help on using tickets.
Back to Top