Opened 8 years ago

Closed 4 years ago

#3304 closed enhancement (fixed)

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

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

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

Download all attachments as: .zip

Change History (37)

comment:1 Changed 8 years ago by 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).

comment:2 Changed 8 years ago by 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.

Changed 8 years ago by arvin

Patch for python

Changed 8 years ago by arvin

Patch for django

comment:3 Changed 8 years ago by arvin

  • Summary changed from Support "httponly"-attribute in session cookie. to [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 Changed 8 years ago by anonymous

  • milestone Version 1.0 deleted

Milestone Version 1.0 deleted

comment:5 follow-up: Changed 8 years ago by mir@…

  • Needs documentation set
  • Needs tests set
  • Patch needs improvement set
  • Triage Stage changed from Unreviewed to Design 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 Changed 8 years ago by ubernostrum

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.

comment:7 in reply to: ↑ 5 Changed 8 years ago by 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.

Changed 8 years ago by cephelo@…

patch for supporting HttpOnly in cookies/session

Changed 8 years ago by cephelo@…

HttpOnly cookie docs

comment:8 Changed 8 years ago by 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

comment:9 Changed 8 years ago by anonymous

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

comment:10 Changed 7 years ago by anonymous

  • Cc sam@… added

comment:11 Changed 7 years ago by jacob

  • Triage Stage changed from Design decision needed to Someday/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 Changed 7 years ago by mrts

  • milestone set to post-1.0

This looks not to be in scope for 1.0.

comment:14 Changed 7 years ago by mattrussell

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

comment:15 Changed 6 years ago by anonymous

  • milestone post-1.0 deleted

Milestone post-1.0 deleted

Changed 6 years ago by 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.

comment:16 Changed 6 years ago by cyounkins

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

Changed 6 years ago by rodolfo

comment:17 Changed 6 years ago by rodolfo

  • Component changed from Core framework to Contrib 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 Changed 5 years ago by anonymous

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

comment:19 Changed 5 years ago by jedie

  • Cc jedie added

comment:20 Changed 5 years ago by rodolfo

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

comment:21 Changed 5 years ago by Ciantic

  • Cc Ciantic added

comment:22 Changed 5 years ago by anonymous

  • Cc andy@… added

comment:23 Changed 5 years ago by jcrocholl

  • 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 Changed 5 years ago by edevil

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 Changed 5 years ago by jsocol

  • Cc james@… added

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

comment:26 Changed 5 years ago by russellm

  • Component changed from Contrib apps to Core framework
  • Triage Stage changed from Someday/Maybe to Accepted

@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 Changed 5 years ago by edevil

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 Changed 5 years ago by russellm

@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 follow-up: Changed 4 years ago by cyounkins

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

comment:30 in reply to: ↑ 29 Changed 4 years ago by lukeplant

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 Changed 4 years ago by russellm

  • Resolution set to fixed
  • Status changed from new to closed

(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