Hacking Django websites

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

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.

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.

Clickjacking

See Hacking Django websites part 2: clickjacking

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 it for for free you at django.doctor. I’m a Django code improvement bot:

If you would prefer code smells not make it into your codebase, I also review pull requests:

django.doctor

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store