DjangoCon Europe 2019: Pentesting your Django apps

rixx

2019-04-11

Writeup of the DjangoCon Europe 2019 talk »Pentesting your Django apps« by Keira and Sky

Keira Paterson and Sky Christensen: We're Django developers from Australia with a passion for appsec and run a free, not-for-profit app for activist groups. (They are not security professionals.)

First off: This talk will not make you a security professional. Use professional services if and where you can.

What is pentesting?

Pentesting is short for penetration testing. It involves scanning for vulnerabilities (by automation, by review, …), attacking to exploit those vulnerabilities, with the purpose of securing the app, and with the permission of the owner.

"If you fail a penetration test you know you have a very bad problem indeed. If you pass a penetration test you do not know that you don't have a very bad problem." Gary McGraw

Why should learn?

Developer unemployment is currently no problem at all. Generally speaking, we have more work to do than we can do. Because we're so busy, we are not being pushed to learn pentesting. But we should!

First off, having knowledge about vulnerabilities, their workings, their exploits, puts us in a very good place regarding introducing them accidentally ourselves – even while Django does a very good job keeping us from introducing vulnerabilities at least in the beginning.

Also, budgets: tech has a lot of money currently, but there never is enough money for everything. If you can take on part of pentesting, you'll have to pay less for the actual thing. It's fun! You get to break stuff! And also, it helps dealing with the fear of introducing security issues in your app.

This knowledge will improve the quality of your code. It will be better in weird unexpected use cases, by making you fix any crash issues.

And in the end, empathy and responsibility prompt us to make our apps as safe as possible: It's up to us to make sure the data and credentials of our users are safe, not stolen or ransomwared, or published. It's 2019, and software is infrastructure now. When we look at software, we have to look at it like at a bridge, or a road, or other public infrastructure. We build this infrastructure, so it is up to us to secure them.

How do you pentest a Django app?

Some things can be integrated with automated tests, other things can be done manually. One of the tools usable for this is Zap – it's a free, open source tool by OWASP. It gives clear actionable alerts, and it saves time. It looks at your site, it scans it, and then it attacks your page. In the end it shows you alerts with full context (requests executed, issues encountered, documentation at OWASP), and produces a final scanning report.

ZAP is an intercepting proxy to run passive scans, or it can attack directly. It comes with a GUI, but it also comes with Python bindings, which you can use easily, e.g. in your tests.

Using behave (with selenium and firefox against gunicorn). Zap slips in between Firefox and gunicorn. You'll have to start ZAP before starting your tests, as Zap learns from your test behaviour! Don't skimp on the gunicorn either, since you'll get a lot of false alerts otherwise, and you'll want to be as close to production behaviour as possible.

Django integration

You want to look at the example commit they produced to integrate ZAP.

You'll want to use behave's environment.py and call zap by calling subprocess.Popen(['zaproxy', 'deamon', '-config', 'api.disablekey=true']); sleep(10).

Then you'll have your start_firefox function – insert a desired_capabilities['proxy'] = { … }.

In the very end, using the after_all method, you'll call zap:

def after_all(context):
    zap = ZAPv2(apikey=None)
    base_url = 'https://localhost:8000'
    zap.spider.scan(base_url)  # find urls
    zap.ascan.scan(base_url)  # takes some time
    with open('report.html', 'w') as f:
        f.write(zap.report…)

Set up ssl by generating a certificate and telling gunicorn to use it.

Custom scripts

You'll need a couple of independent scripts to patch further Django issues. Take their example instead. (See below)

When to get started

Now. Do not start after a breach. Do not start after release. Do not start next month. Start now.

Read the OWASP Top 10, which reports the top 10 most common issues in web applications.
Zap has docs
Simon Bennett(?) has great video tutorials.
Look at the Testing Guide (224 pages, oh boy), which discusses testing mechanics and strategies

Resources:

Their app, with intentional vulns, and instructions on those vulns