Proposal: security enhancements

[James Bennett]

I've written this up in pseudo-DEP format partly for ease of

organization, and partly because I'm unsure whether it would require a

DEP. Right now I'm just throwing it out here as a proposal, and

offering to work on implementing it; if you have questions, concerns,

or suggestions for things to add to it, please let me know :)

Introduction

-----------------

Django has acquired a reputation for being helpful with/good at

"security". Which has been a focus since at least 1.0; Django goes out

of its way to protect you out of the box against common security

problems, and includes a lot of tools geared toward making it easy to

do the right thing when building apps.

But security is a Red Queen problem; we can't ever pause and rest,

since as soon as we do we'll fall behind.

In light of which, I'd like to propose a few security-related

improvements/additions, and offer to put in the time to help implement

them. My baseline goal here is to set things up such that it's

possible, using only things that ship with Django itself and an

SSL-enabled hosting service, to score an A+ rating on

securityheaders.com. Beyond that, some stretch goals are possible.

Content Security Policy

--------------------------------

CSP[1] is one of the more important defenses available against XSS and

a few other types of attacks. Django does not currently have

out-of-the-box support for it; the usual solution is to install

django-csp[2], configure it and set up its middlware to emit the CSP

header.

I'd like to see support for CSP built in to Django. This could be done

by integrating django-csp, which is open source and uses a compatible

license, though there'd need to be some updates to its documentation

(which seems to lag a bit behind what the code supports) and it might

also be good to switch over to using dictionary-based configuration.

Referrer-Policy

---------------------

The Referrer-Policy header[3] is relatively new, but gaining support

in major browsers. It helps enhance both security and privacy.

I wrote a package earlier this year[4] that supports sending the

Referrer-Policy header, and BSD-licensed it. It would be relatively

easy to integrate this into Django.

Subresource integrity

-----------------------------

Subresource integrity[5] allows the author of an HTML document to

supply the expected hashes of resources (scripts, stylesheets, images,

etc.) referenced in the document. This helps to harden against not

only local breaches, but also breaches of third-party scripts and

CDNs.

I don't have a clear vision yet of how it would work, but I'd like to

see the form media system and the staticfiles app grow support for

SRI. In the case of form media, the output already generates the full

HTML and could include the hash. In the case of the {% static %}

template tag, I'm open to suggestions for how it could

generate/include the hash. The admin should use this by default.

CORS

---------

Cross-Origin Resource Sharing is increasingly important on the modern

web, and Django does not currently support setting CORS headers. There

is an open-source package for CORS in Django[6], which could be

integrated.

rel="noopener"

---------------------

Setting rel="noopener" on links which will open in new tabs/windows is

an easy way to head off certain types of surprising attacks[7]. Like

SRI, I don't yet have a great plan for how this could be supported

easily/automatically in Django, but I'd like to give it a try.

Improved system-check integration

-----------------------------------------------

Currently the security system-check is OK, but still a bit

minimal. I'd like to add support for checking at least everything I've

proposed adding above, and probably several more items. In my ideal

world, a service like securityheaders.com could be replicated by the

security check.

In my magical stretch-goal land, I'd also figure out a way to support

the pyup safety library[8] to scan for a requirements file and any

dependencies in setup.py, and warn if known-insecure versions are

specified.

Improved security documentation

---------------------------------------------

Right now we have OK documentation on security, in that we have an

overview[9] listing the broad categories of things Django can protect

you against and pointing to their documentation.

I'd like to expand on that by including a rundown of where to learn

about common security issues, how to go beyond the basic protective

mechanisms Django includes today, and automated scanning/security

check tools like securityheaders, Mozilla Observatory, pyup,

requires.io, etc.

[1] https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP

[2] https://pypi.org/project/django_csp/

[3] https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referrer-Policy

[4] https://pypi.org/project/django-referrer-policy/

[5] https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity

[6] https://pypi.org/project/django-cors-headers/

[7] https://mathiasbynens.github.io/rel-noopener/

[8] https://pypi.org/project/safety/

[9] https://docs.djangoproject.com/en/2.0/topics/security/

[Jacob Kaplan-Moss]

Great ideas, James. I totally agree we shouldn't rest on our laurels, and love the goal of pushing things forwards. Overall, I'm not sure a DEP is needed: each of these things is fairly small and tightly scoped, can be implemented on its own, and provides value independent of the whole. That seems like a scenario where just a bunch of loosely-related PRs makes the most sense. Added bonus: many of these things would be fairly easy pickings for a new contributor. If you wanted, you could delegate/coordinate some of this, and help us get more folks involved as a bonus.

Some comments on specifics:

On Tue, May 1, 2018 at 12:28 AM, James Bennett <ubern...@gmail.com> wrote:

Content Security Policy 

CSP is a tricky one. On the one hand, it's a tremendously effective defense against XSS. But, it's pretty tricky to get right: I've seen several sites struggle with a proper CSP config for years. It tends to be beyond the grasp of your classic one- or two-person dev team. When you get it wrong, it totally hoses your site.

Most complex sites find they need to operate in report-only mode for a while and analyze the data before switching to enforce. And that requires a good reporting/analysis mechanism (something like report-uri.com, or a local equivalent).

So all that to say: I highly support exploring this more, but it could be easy to turn CSP into a foot-gun. I don't think it's as easy as just shipping django-csp and calling it a day; we'd need to make sure it's not going to cause more problems than it solves.

 

Referrer-Policy

+1, this seems like a no-brainer.

 

Subresource integrity

 

The jury seems to still be out on the value of SRI (at least, in my corner of the security community). It has some serious problems with dynamic assets, and with externally-hosted tools like Google Analytics. I'm not convinced that the current spec is fully-baked enough for us to support.

The admin's a special case since we tightly control what's shipped there; SRI-for-the-admin would be a nice, if incremental improvement. Preventing injection attacks in the admin is a very good thing :)

CORS

 Yup, another no-brainer.

rel="noopener"

I'm not sure I get this one, might need to see what you come up with to understand the effect.

 

In my magical stretch-goal land, I'd also figure out a way to support

the pyup safety library[8] to scan for a requirements file and any

dependencies in setup.py, and warn if known-insecure versions are

specified.

This seems entirely doable! Of course, grappling with the various options for dependency management might make this.. less fun (https://xkcd.com/1987/).

 

Jacob

[Josh Smeaton]

Most of this sounds really good. As Jacob mentioned, CSP can be quite scary, and sounds like something a novice could try to implement for "good security" and end up causing way more issues. I'd really like to see easy integration for report only mode, with controls that are harder to turn for full blown CSP.

With regard to pyup - the pipenv check command handles this nicely. I'd imagine support would be similar - in that we'd list pyup as a required dependency for Django, and ship a management command that uses it. The deploy check could then hook in.

[emo...@mozilla.com]

On Thursday, 3 May 2018 05:27:11 UTC+1, Josh Smeaton wrote:

As Jacob mentioned, CSP can be quite scary, and sounds like something a novice could try to implement for "good security" and end up causing way more issues.

Perhaps documenting some of the new (and more accessible) CSP tooling available of late would help mitigate this? For example this Firefox addon that records a browser session and auto-generates an appropriate policy:

https://addons.mozilla.org/en-US/firefox/addon/laboratory-by-mozilla/

On Thursday, 3 May 2018 05:27:11 UTC+1, Josh Smeaton wrote:

I'd really like to see easy integration for report only mode

Agreed - particularly since django-csp dropped it's CSP report collection feature - and services like report-uri.com often require company privacy/legal sign-off, so are much more of a hassle to use.

[Ran Benita]

Regarding CSP, I'd like to point to this thread from a year ago, "Django and CSP strict-dynamic", https://groups.google.com/forum/#!topic/django-developers/n--RWhLAoYM. Unfortunately I haven't had time to follow through on it (yet?).

I think `strict-dynamic` provides an avenue for on-by-default CSP in Django with decent protection, however CSP Level 3 is still in "Working Draft" status it seems.

[Tom Forbes]

Hey James,

I think these ideas are fantastic.

I used EmberJS for a project and the development server contained a built in CSP report URL which just printed what the browser sent to the console. This was very useful during development as you could immediately see CSP errors that were triggered rather than perhaps having to navigate to another page and seeing the issues without context. It would be great if we could add this functionality to Django, perhaps even in production - if we provided a route that would output CSP errors to a specified logger users could configure the logger to send the errors to a variety of places without too much configuration or complexity?

The rel=noopener would be pretty hard to implement IMO, and while noble I’m not sure how we could even do this (outside of the Django admin)?

I don’t have much else to add, other than I’d love to help with the implementation of any of these if I’m able.

Tom

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAL13Cg-9TVC33NjcBwOg9%2B1hd-99kwJ6HiLzuWQV-y1UhBybkg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[James Bennett]

If anyone feels competent to review, there's a PR open now for the first part of this, adding Referrer-Policy support:

https://github.com/django/django/pull/9953

[Jonathon Sumner]

Hi all,

Sorry for jumping in on an old thread, but I stumbled across James' post after writing a similar wish list.  Securityheaders.com (and the Mozilla http-observatory) score an out-of-the-box Django site fairly harshly.  With that in mind, me and a colleague put together a very simple package (django-security-headers) to add some headers, package django-csp, self-test against a local http-observatory instance (using django-sslserver), and provide default settings to get a better score.

I completely agree with Jacob that adding CSP post facto can be a minefield, but I think it would promote better practices if Django shipped with secure defaults for CSP, referrer policy, etc. and required the user to turn these settings off for their application.

Anyway, although I would be a newbie contributor, I would be more than happy to pick up the thread started by James if the senior Django community sees value in it!  

Cheers,

Jonathon

[Curtis Maloney]

I think there is certainly a strong case based on "secure by default" to include this in core, where it would otherwise face the "it works fine as a 3rd party app" barrier to entry.

IMHO it would require, however, that the solutions be sufficiently generic as to not enforce an overly restrictive world view.

I, for one, would be very interested to see more details here on what changes you propose.  Then, at least, we can keep a mailing-list history record of the discussion.

--

Curtis

--

You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.

To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.

To post to this group, send email to django-d...@googlegroups.com.

Visit this group at https://groups.google.com/group/django-developers.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/a31b7f78-2e13-4190-aa58-9db2f00ac909%40googlegroups.com.

[James Bennett]

On Mon, Jul 15, 2019 at 10:27 PM Curtis Maloney <cur...@tinbrain.net> wrote:

I think there is certainly a strong case based on "secure by default" to include this in core, where it would otherwise face the "it works fine as a 3rd party app" barrier to entry.

IMHO it would require, however, that the solutions be sufficiently generic as to not enforce an overly restrictive world view.

I, for one, would be very interested to see more details here on what changes you propose.  Then, at least, we can keep a mailing-list history record of the discussion.

I had an attack of Real Life™ a while back which prevented following up on this thread, but I have some thoughts I'd be happy to write up and share here, and can at least try to find time to put in some work on implementation.

I'll try to get something more detailed when the weekend rolls around again, but the short version is that I'd like to spin up a third-party project to do the implementation work in, and then look at integrating it back into Django at a later time once it's been able to mature a bit. That's been a successful model for a few other larger projects in the past, and I think is also the right approach for doing this particular type of security work, since there's still a decent amount of flux in the relevant standards and their implementations (to take one example, the Referrer-Policy header has had some consistency issues with browser implementations) which would make me wary of putting it straight into Django and enabled or even recommended by default.

[Jonathon Sumner]

Hi Curtis,

It sounds like James is going to get things rolling, but to answer your question the third-party app we set up to get to A+ on securityheaders.com integrated the following:

1. Adds the 'Referrer-Policy' header with a default policy of 'same-origin' 
2. Adds the 'Feature-Policy' header with reasonable defaults
3. Adds the 'X-Frame-Options' header with a default policy of 'deny'... the difference here from standard Django is that the app exposes a model in the admin whereby users can define 'safe' domains for which 'X-Frame-Options' should be 'allow-from <domain>'
4. Loads django-csp with reasonable defaults
5. For Django <2.1, loads the django-cookies-samesite package to set the SameSite flag 
6. Exposes a view to run the Mozilla http observatory locally (python3 only) using django-sslserver as a way to check Django-based security settings prior to deployment

Repo is here.

Cheers!

Jonathon

To unsubscribe from this group and stop receiving emails from it, send an email to django-d...@googlegroups.com.

[James Bennett]

I haven't forgotten about this, but it'll likely be another day or two before I can lay out a proper plan.