Here's an idea, but you'll have to ask around if it's eligible for a
patch reward.
Some time ago I wrote fuzzers for Django, which have been running 24/7
on OSS-Fuzz since.
Thanks to this fuzzer, a few DoS bugs were found [2] and it would
likely have caught some historic DoS bugs.
The current fuzzer tests a host of utility functions [3]. If a
time-out, out-of-memory or uncaught exception occurs, the security
team will receive a notification from OSS-Fuzz containing instructions
on how to reproduce the bug, and the bug can be fixed.
Writing additional fuzzers consists of:
- Implement a function 'FuzzerRunOne(FuzzerInput)'
- Do something with FuzzerInput, which is a bytes() object and
consists of pseudo-random data generated by the fuzzing engine
- Raise an (uncaught) exception if something is amiss, eg. a html
escape function that returns valid html tags (try parsing the output
with BeautifulSoup for example) from a crafted input
Some basic constraints: the fuzzer must be:
1. Not very slow
2. Deterministic
3. Preferably not use file/network IO/forking other processes (this
could affect 1 and 2)
If you are keen, I can help you get things set up (and to be clear, I
don't need a cut of the reward for that. Just happy to see my fuzzers
put to good use). You won't need to touch C/C++ or other code;
implementing dynamic tests in Python is sufficient.
[1] https://github.com/google/oss-fuzz
[2] https://www.djangoproject.com/weblog/2019/aug/01/security-releases/
[3] https://github.com/guidovranken/django-fuzzers/blob/master/utils.py
On Sun, Dec 29, 2019 at 5:23 AM Taymon A. Beal 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 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
