Another good security improvement would be to allow the database password and other database information to support AWS Secrets Manager, Goolge Secrets Management, and HashiCorp vault (+ others). I have done this in a private package used at the National Library of Medicine, but my package is both private and limited to RDS PostgreSQL and AWS Secrets Manager.
On Tue, Dec 31, 2019 at 11:25 AM Dan Davis <dansm...@gmail.com> wrote: > Taymon Beal writes: > > 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.) > > What secrets management systems are you thinking about? I wrote > confsecrets, whose Django integration never worked right, assuming that I'd > port it to support the following: > * HashiCorp vault > * AWS Secrets Manager > * Google Secrets Management > > I also need to switch it from cryptdome to cryptography or make it > agnostic on these. > > P.S. - I have some very limited applied cryptography knowledge - couple > chapters of Bruce Schneier and some hands-on learning, such as securing > single license features with signatures based on my employer's license > signing private key, and discovering that a customer literally pulled one > set of feature.xml/feature.sig files from one tarball, and another from > another tarball to game my home-grown licensing system. I helped that > company eventually move to a Secure USB dongle, and that was my last moment > of systems software development :) > > On Sat, Dec 28, 2019 at 11:23 PM Taymon A. Beal <taymonb...@gmail.com> > wrote: > >> (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 <auv...@gmail.com> >> 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 >>> <https://groups.google.com/d/msgid/django-developers/3c2cb15c-3c55-431c-8ee7-a5a207051389%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- >> 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 >> <https://groups.google.com/d/msgid/django-developers/CAHRQ%3D87016c3XEJSje1i%2BHZBfag%2BiyGVQXr5OX7xKr3QH2i_nA%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > -- 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/CAFzonYb9WeOq7DdowvGre4%2ByMTxJPw%3DVZE5pR_zsJxr7hOL7iQ%40mail.gmail.com.
