Proposal: security enhancements

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

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,



--
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 [hidden email].
To post to this group, send email to [hidden email].
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.
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: security enhancements

Jacob Kaplan-Moss-2
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 <[hidden email]> 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

--
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 [hidden email].
To post to this group, send email to [hidden email].
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/CAK8PqJG-xF6zJXwrm-SBifUgTUtjd8_rrn_-2rO8AaDthbL9Jw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: security enhancements

Josh Smeaton
In reply to this post by James Bennett
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.

On Tuesday, 1 May 2018 17:28:21 UTC+10, James Bennett wrote:
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
<a href="http://securityheaders.com" target="_blank" rel="nofollow" onmousedown="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fsecurityheaders.com\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEDisSnNjXUe-cZrnwZYeki3ZbUCA&#39;;return true;" onclick="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fsecurityheaders.com\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEDisSnNjXUe-cZrnwZYeki3ZbUCA&#39;;return true;">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 <a href="http://securityheaders.com" target="_blank" rel="nofollow" onmousedown="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fsecurityheaders.com\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEDisSnNjXUe-cZrnwZYeki3ZbUCA&#39;;return true;" onclick="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fsecurityheaders.com\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEDisSnNjXUe-cZrnwZYeki3ZbUCA&#39;;return true;">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,
<a href="http://requires.io" target="_blank" rel="nofollow" onmousedown="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Frequires.io\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNE8NvGiDEHsGCmUSahPtFhpS6ZxHw&#39;;return true;" onclick="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Frequires.io\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNE8NvGiDEHsGCmUSahPtFhpS6ZxHw&#39;;return true;">requires.io, etc.


[1] <a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fdeveloper.mozilla.org%2Fen-US%2Fdocs%2FWeb%2FHTTP%2FCSP\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGXA4YXApT1s_9v_q-b_Eea-nWmiw&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fdeveloper.mozilla.org%2Fen-US%2Fdocs%2FWeb%2FHTTP%2FCSP\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGXA4YXApT1s_9v_q-b_Eea-nWmiw&#39;;return true;">https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP
[2] <a href="https://pypi.org/project/django_csp/" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fpypi.org%2Fproject%2Fdjango_csp%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNF9PWg8JT4RARSDb5G_vcrTvPC1XQ&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fpypi.org%2Fproject%2Fdjango_csp%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNF9PWg8JT4RARSDb5G_vcrTvPC1XQ&#39;;return true;">https://pypi.org/project/django_csp/
[3] <a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referrer-Policy" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fdeveloper.mozilla.org%2Fen-US%2Fdocs%2FWeb%2FHTTP%2FHeaders%2FReferrer-Policy\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFt1goL4kwHp5RP8igX5NXP24Gdig&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fdeveloper.mozilla.org%2Fen-US%2Fdocs%2FWeb%2FHTTP%2FHeaders%2FReferrer-Policy\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFt1goL4kwHp5RP8igX5NXP24Gdig&#39;;return true;">https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referrer-Policy
[4] <a href="https://pypi.org/project/django-referrer-policy/" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fpypi.org%2Fproject%2Fdjango-referrer-policy%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGcQbwo3PQiq0RoptRCAwkeozpSdw&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fpypi.org%2Fproject%2Fdjango-referrer-policy%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGcQbwo3PQiq0RoptRCAwkeozpSdw&#39;;return true;">https://pypi.org/project/django-referrer-policy/
[5] <a href="https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fdeveloper.mozilla.org%2Fen-US%2Fdocs%2FWeb%2FSecurity%2FSubresource_Integrity\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFo7dYNDbr05HIPzcsEo4inK2dy3A&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fdeveloper.mozilla.org%2Fen-US%2Fdocs%2FWeb%2FSecurity%2FSubresource_Integrity\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFo7dYNDbr05HIPzcsEo4inK2dy3A&#39;;return true;">https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity
[6] <a href="https://pypi.org/project/django-cors-headers/" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fpypi.org%2Fproject%2Fdjango-cors-headers%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGr3XJEUoHka7q8JGrKFw2MDzayPA&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fpypi.org%2Fproject%2Fdjango-cors-headers%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGr3XJEUoHka7q8JGrKFw2MDzayPA&#39;;return true;">https://pypi.org/project/django-cors-headers/
[7] <a href="https://mathiasbynens.github.io/rel-noopener/" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fmathiasbynens.github.io%2Frel-noopener%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGeU3Cb0owcEp8Ap7-ictWK45BfQQ&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fmathiasbynens.github.io%2Frel-noopener%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGeU3Cb0owcEp8Ap7-ictWK45BfQQ&#39;;return true;">https://mathiasbynens.github.io/rel-noopener/
[8] <a href="https://pypi.org/project/safety/" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fpypi.org%2Fproject%2Fsafety%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGCxOKbOHo7yiLyI_QWRaybA8IfVA&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fpypi.org%2Fproject%2Fsafety%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGCxOKbOHo7yiLyI_QWRaybA8IfVA&#39;;return true;">https://pypi.org/project/safety/
[9] <a href="https://docs.djangoproject.com/en/2.0/topics/security/" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fdocs.djangoproject.com%2Fen%2F2.0%2Ftopics%2Fsecurity%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHpgOlGmaQpycdoaqfbtGFtB24wWw&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fdocs.djangoproject.com%2Fen%2F2.0%2Ftopics%2Fsecurity%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHpgOlGmaQpycdoaqfbtGFtB24wWw&#39;;return true;">https://docs.djangoproject.com/en/2.0/topics/security/

--
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 [hidden email].
To post to this group, send email to [hidden email].
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/bd37b3b3-e23e-42bb-b320-458c6786dbc6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: security enhancements

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

--
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 [hidden email].
To post to this group, send email to [hidden email].
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/ba75344d-1dcf-4085-bb62-ae4b4e3b8d83%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: security enhancements

Ran Benita
In reply to this post by James Bennett
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.

--
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 [hidden email].
To post to this group, send email to [hidden email].
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/CANeXs%3D3EP9RcGaFBBQ6Q3JPQaBNpaF7DzB9twBp-_cwjwYPncQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: security enhancements

Tom Forbes
In reply to this post by James Bennett

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




On 1 May 2018 at 08:28:18, James Bennett ([hidden email]) wrote:

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,



--
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 [hidden email].
To post to this group, send email to [hidden email].
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.

--
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 [hidden email].
To post to this group, send email to [hidden email].
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/CAFNZOJO8yS5ZM%2B2qvqO3MXh3gqXveYSxHHiB-S%2BP_tF_1mvtxw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: security enhancements

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

--
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 [hidden email].
To post to this group, send email to [hidden email].
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_S%2Bt4s4JN3pRxQbsqbguGExnyiNn8sgHwSJFOO2HqAtQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.