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