Re: Google Patch Rewards program

[Taymon A. Beal]

(Disclosure: I'm on Google's security team, and my views on this topic are
informed by what kinds of things we tend to look for in Web frameworks, but
here I don't speak for them, only for myself.)

Beyond those already mentioned, here are some potential security
improvements I'd like to see in Django:

   - Support for contextual autoescaping in the template system. The
   current autoescaping behavior is better than nothing, but it still makes
   XSS far too easy, since different kinds of strings are XSS sinks in
   different contexts.
   
https://github.com/google/closure-templates/blob/master/documentation/concepts/auto-escaping.md
shows
   an example of how to do this sort of thing more securely.
   - First-class integration with one or more secrets management systems,
   both to generally contain secrets better and more specifically so people
   aren't so tempted to check SECRET_KEYs and database passwords into source
   control. (I think this was mentioned in the list of GSoC project ideas.)
   - Capability-based authorization. Right now, you have to explicitly
   check for all relevant permissions everywhere, and if you forget, or even
   if you accidentally include the wrong variable in a template, you can leak
   data or worse. It'd be much safer if the allowed permissions could be
   defined at a single choke point, and from there, all model access within a
   request could be mediated by the specified authorization rules. Ideally
   data that the current user isn't supposed to see would not even be fetched
   from the database.

Taymon

On Sat, Dec 21, 2019 at 11:29 PM Asif Saif Uddin  wrote:

> Really good plans Adam!
>
> On Saturday, December 21, 2019 at 11:51:11 PM UTC+6, Adam Johnson wrote:
>>
>> I just saw Google is expanding their Patch Rewards program for open
>> source security improvements:
>> https://security.googleblog.com/2019/12/announcing-updates-to-our-patch-rewards.html
>>
>> They are offering two tiers of rewards - $5,000 or $30,000 - for  open
>> source projects making security improvements. I think Django would find it
>> hard to fit in the "small" tier - we generally fix known vulnerabilities
>> quickly - but we could use the "large" tier to fund a bigger GSoC style
>> project. I suspect it would need active involvement from a DSF member to
>> push it through. Not sure how the funding would work in terms of DSF and
>> paying for development time on the project.
>>
>> Some projects that could fit:
>>
>>- 2FA built-in to django.contrib.auth (as suggested for GSoC as well
>>in this thread:
>>
>> https://groups.google.com/forum/#!msg/django-developers/ifYT6lX8nmg/1nVO3As1AwAJ
>>)
>>- Adding CSP to SecurityMiddleware and shipping some default
>>(django-csp is a good start but requires users to actively seek it:
>>https://django-csp.readthedocs.io/en/latest/ )
>>- Adding CORS to Django itself (I'm maintaining django-cors-headers,
>>but its design is a bit pants
>>https://github.com/adamchainz/django-cors-headers )
>>- Other things in James Bennett's list of suggestions from this
>>thread in May 2018:
>>
>> https://groups.google.com/forum/#!msg/django-developers/DDpkrvFdnvk/J46ZbakxAgAJ
>>
>> Thoughts?
>> --
>> Adam
>>
> --
> 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-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/3c2cb15c-3c55-431c-8ee7-a5a207051389%40googlegroups.com
> 
> .
>

-- 
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-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAHRQ%3D87016c3XEJSje1i%2BHZBfag%2BiyGVQXr5OX7xKr3QH2i_nA%40mail.gmail.com.

Re: django-admin startproject settings.py has some security holes

[Taymon A. Beal]

The number of default-generated SECRET_KEYs that can be found publicly on
GitHub alone suggests to me that no, the existence of that page is not
sufficient to protect users from making this mistake.

Deploying to production already requires worrying about things more
complicated than a SECRET_KEY, like having a database that actually durably
persists your data (yes, SQLite does this in some deployment environments,
but in many popular ones it doesn't). And if your Django site is accessible
to the public internet, and its SECRET_KEY is compromised, then so is the
site itself. So I'm not convinced that making it easier for users to
quickly get a vulnerable site up and running on the public internet is in
their interest.

Local development is, of course, a different story. Have we considered
letting Django run with a blank SECRET_KEY in local scenarios? I guess
DEBUG = True might be an okay way to handle that, though I can't help but
wonder if there's a better alternative for making doing the safe thing the
path of least resistance. We certainly don't want to push users to enable
DEBUG in production...

Taymon

On Sat, Nov 16, 2019 at 7:14 AM Adam Johnson  wrote:

> There is such a link since 2013:
> https://github.com/django/django/commit/912b5d2a6bc78067d6a7e130f10514c51bd1a58f
>
> On Thu, 24 Oct 2019 at 23:31, Olivier Dalang 
> wrote:
>
>> Hi,
>>
>> Just a reminder about this page in the docs:
>> https://docs.djangoproject.com/en/2.2/howto/deployment/checklist/
>> It basically already covers it all. Maybe a direct link to that page from
>> the settings file would be good enough?
>>
>> Cheers,
>>
>> Olivier
>>
>> On Thu, Oct 24, 2019, 04:45 Josh Smeaton  wrote:
>>
>>> A quick idea from the top of my head, is to change the assignment of
>>> SECRET_KEY in the generated settings to something like:
>>>
>>> SECRET_KEY = os.environ.get("DJANGO_SECRET_KEY",
>>> "insecure-")
>>>
>>> It signals that secrets in the environment are a good idea, that the
>>> default generated value is insecure, and it still has a random part so that
>>> default sites aren't automatically hackable when deployed. There's no
>>> impact to people just getting started.
>>>
>>> We could go a small step forward and use `check --deploy` to check for
>>> the substring `insecure` (even though I believe the KEY is technically
>>> bytes?).
>>>
>>> Just throwing something out there.
>>>
>>>
>>> On Monday, 21 October 2019 23:48:59 UTC+11, Taymon A. Beal wrote:

 Is the requirement here to avoid introduce additional barriers to
 getting up and running in local development, or to deploying a site so that
 it's accessible from the public internet?

 Both of these are important goals, but trading off security against the
 latter worries me. I don't think we're doing beginners any favors if we
 make it easier for them to deploy sites with security issues, especially
 since they won't be in a good position to appreciate the consequences.
 Ideally we'd make it easy for beginners to deploy sites without security
 issues, but that's a hard problem given the diversity of production
 environments; in the meantime, I think we need to accept the reality that
 figuring out how to store secrets *is* a prerequisite to deploying Django
 in production, notwithstanding how much we wish it weren't.

 I'd be interested in trying to contribute a solution more secure than
 the status quo without introducing more barriers to local development, if
 it would have a chance of being accepted.

 Taymon

 On Friday, October 11, 2019 at 8:00:59 AM UTC-7, Carlton Gibson wrote:
>
> It's just scope:
>
>* Not clear we need to _replace_ the space for books, and blog
> posts, and so on, in the main docs.
>
> and bandwidth:
>
>* These things are difficult to get right, and it needs someone to
> do them. (PRs always warmly received!)
>
> On balance, I have to say, I think the default project template does
> very well.
> Taking a beginner, say, and adding, "As well as the million things
> you're already dealing with, there are these things called environment
> variable and..." is a step I'd be very cautious about taking.
>
> Yes, granted, for professional deployment, you might want different —
> but we have to serve everyone.
>
 --
>>> 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-developers+unsubscr...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/django-developers/3443dbe6-1a6a-45af-b5ec-08cf78426869%40googlegroups.com
>>> 
>>>