Hacking Django websites

#django #webdev #python #security

Django docs suggests SecurityMiddleware is placed near the top of your MIDDLEWARE settings for good reason: it performs a suite of security checks and enhancements that would otherwise leave your website to the mercy of some simple hacks.

Ready for a Django security challenge? Play our Django security challenge.

X-Content-Type-Options

SecurityMiddleware sets the X-Content-Type-Options header to nosniff to prevent hackers from tricking your website into executing a malicious javascript file that they uploaded.

This header indicate to the browser that the MIME types advertised in the Content-Type headers should not be changed (by "sniffing" the content). The sniffing feature is the browser being helpful when a developer or server misconfiguration misidentified the Content-Type. If the browser respected an incorrect MIME type then a javascript, css, or image file would not work and the website would break. Very helpful feature. But it can be abused, as the following simple proof of concept shows:




# settings.py
MIDDLEWARE = [
    # "django.middleware.security.SecurityMiddleware",
    "django.middleware.common.CommonMiddleware",
    "django.contrib.sessions.middleware.SessionMiddleware",
    ...
]

SECURE_CONTENT_TYPE_NOSNIFF = False  # pre-Django 3.0 it was False by default. Post 3.0 it's True

# views.py
class HomePage(View):
    def get(self, *args, **kwargs):
        # simulate a misconfgured server that returns a response that has no content type
        response = HttpResponse("<script>alert('hello world')</script>")
        del response['Content-Type']
        return response

The outcome when navigating to HomePage shows the "hack" worked:

This simple proof of concept simulated the following more complex situation:

A bad actor uploaded HTML containing javascript (maybe pretending to be an image file).
The file was served by your website but does not set MIME type in the Content-Type header
The browser inferred the MIME type based on the content
The browser executed the javascript

This would be avoided if we the SecurityMiddleware is present and the nosniff feature is active:



# settings.py
MIDDLEWARE = [
    "django.middleware.security.SecurityMiddleware",
    "django.middleware.common.CommonMiddleware",
    "django.contrib.sessions.middleware.SessionMiddleware",
    ...
]

SECURE_CONTENT_TYPE_NOSNIFF = True

Then the browser does not fall for the trick:

X-XSS-Protection

SecurityMiddleware sets the X-XSS-Protection header to 1; mode=block when SECURE_BROWSER_XSS_FILTER is True to enable the browser's built-in XSS protection.

This XSS protection has been mostly superseded by CSP. Older browsers still support this feature, but many browsers have removed this feature. Users with older browsers are still important to cater for because security of your website cannot assume everyone is running the latest version of Chrome.

Without the SecurityMiddleware and SECURE_BROWSER_XSS_FILTER then the website will not receive the benefit of being protected against the many possible XSS attacks.

Referrer Policy

SecurityMiddleware sets the referer policy header based on SECURE_REFERRER_POLICY, which impacts user privacy and is an attack vector for bad actors that aim to dupe users into thinking they are still on your website.

The referer header can be abused by the target website: maybe secrets in the your website URL is leaked. More convolutedly, maybe a bad actor can add a link to their website. The target can then read the referer header and style their website to look like your website. A user not paying attention may think they're still on your website because:

your website linked to it
it looks like your website

So the user may then input credentials and personal details in the bad actor's website.

This can be prevented by not exposing the referer header by settings SECURE_REFERRER_POLICY, which is then handled by the SecurityMiddleware.

Clickjacking

See Hacking Django websites part 2: clickjacking

Cross Site Request Forgery

See Hacking Django websites part 3: CSRF

SSL Redirect

SecurityMiddleware can redirect HTTP connections to HTTPS if SECURE_SSL_REDIRECT is set to True.

If you do not redirect HTTP to HTTPS then passwords and personal information will be transported over plaintext, and a Man In The Middle could read them.

See Hacking Django websites part 4: Man In The Middle

Does your website have security vulnerabilities?

Over time it's easy for security vulnerabilities and tech debt to slip into your codebase. I can check that for you at django.doctor, or can review your GitHub PRs: