Hi all, I think finally integrating django-secure is a great step. Making a separate deploy check also makes sense to me. However, I think we should be very cautious with pushing people to enable HSTS.
Some of our security headers can cause things to break. For example redirecting to SSL when your HTTPS is broken, will break your site. Enabling strict X-Frame-Options when you do use external iframes, will break your site. However, if you then fix the setting, everything will work again. Inconvenient, but easy to recover. Also, these effects are limited to the Django site you are working on. If I were hosting a Django site on example.com, and enable HSTS with includeSubdomains and a lifetime of 6 months, as seems to be common now, I might not only break my own site, but also every other side under example.com. Upon discovering the error it can be corrected, but not before a unknown set of users has memorized that all of example.com and any site under it must use HTTPS. So, although I encourage anyone to enable HSTS, we should not recommend people to just "switch it on". They should be well aware of the consequences as it can affect an unknown set of users beyond their Django site, long after the change has been reverted. The possible seriousness should be reflected in any encouragement we make for HSTS to be enabled. Erik On 28 Aug 2014, at 02:25, Tim Graham <[email protected]> wrote: > After I wrote the original email, I found #17101 which is where the > checkdeploy idea came from. We can just close that ticket (or modify it) if > we decide on a different solution. It was created before the checks framework > was merged and I agree a separate command may not be ideal, although it may > make the implementation slightly easier. I'll look into using DEBUG tomorrow. > One issue is that we don't want these checks run during testing (and DEBUG is > often False there). Maybe if these checks are registered with something like > checks.register(foo, deploy=True), we can skip any checks registered like > that during testing. I'll have to see if there's some way to make this work > with 'manage.py test' as well as with 3rd party test runners. If we had a > separate checkdeploy command, avoiding this problem might be somewhat easier. > > I am fine with putting it in core instead of contrib. That just means we need > to figure out what to do about settings since we cannot put them on an > AppConfig. Assuming we don't want to add them as normal settings, we may be > able to use the approach proposed on this mailing list for the CSRF settings > -- using attributes on the middleware class (PR). In that case, the check > could work by iterating through MIIDDLEWARE_CLASSES until it finds a subclass > of SecurityMiddleware and then check the attributes (settings) on that class. > I will look into this approach tomorrow. > > Thanks for the feedback! > > On Wednesday, August 27, 2014 8:47:26 PM UTC-4, Curtis Maloney wrote: > For what it's worth, I agree with Russ. > > Having security as an optional extra [which is how it will look to outsiders] > is a bad look for Django, and certainly doesn't fit with the "Secure by > default" philosophy. > > -- > Curtis > > > On 28 August 2014 10:34, Russell Keith-Magee <[email protected]> wrote: > Hi Tim, > > On Thu, Aug 28, 2014 at 3:35 AM, Tim Graham <[email protected]> wrote: > I've started tackling one of the ideas that's been on our GSoC ideas > page for a couple years now: integrating django-secure. I chatted with > Carl about the idea and he's onboard. There are a couple of design > decisions we'll need to make. > > +1 to the idea. It was part of Chris' original proposal; we just didn't get > around to it with the available time. > > 1. How to integrate django-secure with the checks framework > django-secure essentially implements its own checks framework (which > predates the one in Django). The tricky part is that django-secure's > checks are not ones that generally should pass on a > development instance; they're checks that only make sense to run on a > production server (or at least against a production settings file). > I'm thinking to have some way to skip these new checks by default and > run them only when requested (e.g. manage.py check secure > --settings=prod_settings). Other options include an entirely separate > command like django-secure implements (curently called checksecure), > but perhaps could be called checkdeploy and eventually extended with > other checks that are relevant only in production. Idea/insight from > those more familiar with the checks framework (Chris, Russ), would be > welcome. > > Generally, I'd be opposed to the idea of Yet Another Command to run checks - > if you make it optional, it won't get run, and this is something we want to > be forced in front of everyone. > > We use DEBUG as a proxy for "In Production" in other locations in the > codebase - e.g., whether ALLOWED_HOSTS checks are run. If we were to > supplement that with a --production=true/false flag to the checks command (to > override the rare legitimate occasions where DEBUG=True in production, or > DEBUG=False in development), wouldn't that meet all the needs here? > > 2. How to add settings for django-secure > As discussed in the thread below, I'm going to explore developing an > API for storing settings on an AppConfig to avoid adding more global > settings. > https://groups.google.com/d/topic/django-developers/qnnCLppwA3o/discussion > > I have imported django-secure into django.contrib.secure and started > work on integrating it with the built-in checks framework as well as > removing some bits of it that have since been added to Django > (frame-deny, SSL-proxy support). > > Is it appropriate for this to be a contrib package? That implies it needs to > be added to INSTALLED_APPS; I'm not convinced that this is a desirable > approach. > > If django-secure is important enough to include as part of Django's codebase > (and I fully agree it is), I'd consider security to be part of core, not > something you can opt out of. Including it as django.core.checks.security (or > similar) would make more sense to me. > > Russ %-) > > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" 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 http://groups.google.com/group/django-developers. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/CAJxq84_Tq1Fnm_pG4pMSy98DOLsnLtVp9jEgTo6X8%2BH%2BJYi1dQ%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" 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 http://groups.google.com/group/django-developers. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/2d66a232-1f19-4bcc-8178-7e1e060f497b%40googlegroups.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" 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 http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/2316E343-8EEF-40B3-B043-CA64FA555382%40solidlinks.nl. For more options, visit https://groups.google.com/d/optout.
