carljm/django-secure

This project was merged into Django 1.8, and is now unsupported and unmaintained as a third-party app.

django-secure

Warning

This project was merged into Django 1.8. It does not provide any additional checks beyond those included in Django 1.8+, so there is no reason to use it with Django 1.8+. Since Django 1.8 is now the lowest supported Django version, this project is now unsupported and un-maintained.

Helping you remember to do the stupid little things to improve your Django site's security.

Inspired by Mozilla's Secure Coding Guidelines, and intended for sites that are entirely or mostly served over SSL (which should include anything with user logins).

Quickstart

Dependencies

Tested with Django 1.4 through trunk, and Python 2.6, 2.7, 3.2, and 3.3. Quite likely works with older versions of both, though; it's not very complicated.

Installation

Install from PyPI with pip:

pip install django-secure

or get the in-development version:

pip install django-secure==dev

Usage

• Add "djangosecure" to your INSTALLED_APPS setting.
• Add "djangosecure.middleware.SecurityMiddleware" to your MIDDLEWARE_CLASSES setting (where depends on your other middlewares, but near the beginning of the list is probably a good choice).
• Set the SECURE_SSL_REDIRECT setting to True if all non-SSL requests should be permanently redirected to SSL.
• Set the SECURE_HSTS_SECONDS setting to an integer number of seconds and SECURE_HSTS_INCLUDE_SUBDOMAINS to True, if you want to use HTTP Strict Transport Security.
• Set the SECURE_FRAME_DENY setting to True, if you want to prevent framing of your pages and protect them from clickjacking.
• Set the SECURE_CONTENT_TYPE_NOSNIFF setting to True, if you want to prevent the browser from guessing asset content types.
• Set the SECURE_BROWSER_XSS_FILTER setting to True, if you want to enable the browser's XSS filtering protections.
• Set SESSION_COOKIE_SECURE and SESSION_COOKIE_HTTPONLY to True if you are using django.contrib.sessions. These settings are not part of django-secure, but they should be used if running a secure site, and the checksecure management command will check their values.
• Ensure that you're using a long, random and unique SECRET_KEY.
• Run python manage.py checksecure to verify that your settings are properly configured for serving a secure SSL site.

Warning

If checksecure gives you the all-clear, all it means is that you're now taking advantage of a small selection of easy security wins. That's great, but it doesn't mean your site or your codebase is secure: only a competent security audit can tell you that.

Documentation

See the full documentation for more details.

django-secure's Issues

Crazy idea: experimentally verify that SECURE_SSL_PROXY_HEADER is set correctly

From IRC discussion with Paul McMillan: "checksecure" could take an option to specify the public-facing URL of the deployed site you're currently running it on. If this option is set, it would actually send a request to that external URL, attempting to spoof the header you have listed in SECURE_SSL_PROXY_HEADER. If it succeeds, it gives you a big fat warning that you should not rely on that header in SECURE_SSL_PROXY_HEADER.

Document some typical possible values for SECURE_PROXY_SSL_HEADER

We already show X-Forwarded-Protocol; we could also mention X-Forwarded-Ssl, X-Forwarded-Proto, and Front-End-Https. At least according to comments on https://code.djangoproject.com/ticket/14597 those are all in use.

For each of those, if we document it, we need to document the possible values for the header, too (or at least the value that indicates "yes this is SSL").

Enforce SECRET_KEY

Today I was bitten hard by a project that had an empty SECRET_KEY. It turns out that Django <1.5 won't alert you about this.

I suggest having django-secure alert you about an empty SECRET_KEY. In fact, I'd suggest checking the entropy of SECRET_KEY in some simple way and warning if it's too low. (It can be as simple as checking the number of characters in it. Not trying to make a bullet-proof check, just defending against someone accidentally using a really really short SECRET_KEY.)

Document status versus 1.8

It seems that all or most of the features of this package have made it into the mainline of Django. However, whether it is all or most is not clear. Also, it is not clear whether this package will be maintained in some form or other.

It would be great to find this back in the README and/or other documentation.

Thanks!

TypeError: 'unicode' object does not support item assignment

I sometimes get this error from the middleware:

Stacktrace (most recent call last):

  File "django/core/handlers/base.py", line 188, in get_response
    response = middleware_method(request, response)
  File "djangosecure/middleware.py", line 44, in process_response
    response["x-frame-options"] = "DENY"

This is a Django 1.4 based site and the error seems to occur on redirect.

400 error

I get 400 error, I try to google find the solution, found out someone has same problem on stackoverflow but no solution.

need a help!

https://stackoverflow.com/questions/14297691/django-security-middleware-is-crashing-the-site

the check_frame_deny check should pass if Django's new X_FRAME_OPTIONS setting is set to DENY and the XFrameOptions middleware is installed

If X_FRAME_OPTIONS is SAMEORIGIN, I think we should still warn that DENY is better unless you know that your site needs frames internally.

Detect versions of Django that support SECURE_PROXY_SSL_HEADER setting and skip the request.is_secure monkeypatch

warn if Django's new USE_X_FORWARDED_HOST setting is set to True

This setting should be set to True in certain proxied situations, but generally False is the safe setting. So we should warn by default if its True, explain the situation, and people can turn the check off if they know they need it True in their case.

Reminder to Make a Release with Subdomains HSTS

:D

django-secure should discourage cookie backed session stores

It's not terribly likely that people will be using cookie backed session stores if they're worried about security, but they might. To the best of my knowledge, the signing on these is secure. Nonetheless, django-secure should probably discourage their use.

(This might not quite fall into the "you're doing it wrong" category... maybe there should be a different set of tests that will tell you "be very very careful if you're doing any of these things". More of a django-security-lint kind thing.)

consider warning on .extra() and .raw()

Django advises developers to avoid using QuerySet.extra() and QuerySet.raw(), and to use bound parameters when they must use these. However, they're still a pretty potent avenue for mistakes, and so it might be worthwhile for django-secure to warn when they are in use at all.

You say "a developer knows if they're using these, and they have been warned by the docs!" This is true. However, a bit more warning isn't going to hurt someone, especially if they're concerned enough about security to use django-secure.

This code would be most useful when a developer pulls a reusable third-party module into their project. They are unlikely to go audit the whole code themselves, but getting a warning when these are in use would help discourage "it wasn't my fault" security breaches.

Middleware throws TypeError under Django 1.10.4 and Python 3.5.2

Starting development server at http://127.0.0.1:8000/
Quit the server with CONTROL-C.
Unhandled exception in thread started by <function check_errors.<locals>.wrapper at 0x7f5d731ed840>
Traceback (most recent call last):
  File "/home/aaron/.virtualenvs/intranet/lib/python3.5/site-packages/django/utils/autoreload.py", line 226, in wrapper
    fn(*args, **kwargs)
  File "/home/aaron/.virtualenvs/intranet/lib/python3.5/site-packages/django/core/management/commands/runserver.py", line 142, in inner_run
    handler = self.get_handler(*args, **options)
  File "/home/aaron/.virtualenvs/intranet/lib/python3.5/site-packages/django/contrib/staticfiles/management/commands/runserver.py", line 27, in get_handler
    handler = super(Command, self).get_handler(*args, **options)
  File "/home/aaron/.virtualenvs/intranet/lib/python3.5/site-packages/django/core/management/commands/runserver.py", line 64, in get_handler
    return get_internal_wsgi_application()
  File "/home/aaron/.virtualenvs/intranet/lib/python3.5/site-packages/django/core/servers/basehttp.py", line 49, in get_internal_wsgi_application
    return import_string(app_path)
  File "/home/aaron/.virtualenvs/intranet/lib/python3.5/site-packages/django/utils/module_loading.py", line 20, in import_string
    module = import_module(module_path)
  File "/home/aaron/.virtualenvs/intranet/lib/python3.5/importlib/__init__.py", line 126, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
  File "<frozen importlib._bootstrap>", line 986, in _gcd_import
  File "<frozen importlib._bootstrap>", line 969, in _find_and_load
  File "<frozen importlib._bootstrap>", line 958, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 673, in _load_unlocked
  File "<frozen importlib._bootstrap_external>", line 665, in exec_module
  File "<frozen importlib._bootstrap>", line 222, in _call_with_frames_removed
  File "/tank/code/intranet/intranet/wsgi.py", line 13, in <module>
    application = get_wsgi_application()
  File "/home/aaron/.virtualenvs/intranet/lib/python3.5/site-packages/django/core/wsgi.py", line 14, in get_wsgi_application
    return WSGIHandler()
  File "/home/aaron/.virtualenvs/intranet/lib/python3.5/site-packages/django/core/handlers/wsgi.py", line 153, in __init__
    self.load_middleware()
  File "/home/aaron/.virtualenvs/intranet/lib/python3.5/site-packages/django/core/handlers/base.py", line 82, in load_middleware
    mw_instance = middleware(handler)
TypeError: __init__() takes 1 positional argument but 2 were given

Removing 'debug_toolbar.middleware.DebugToolbarMiddleware', from MIDDLEWARE fixes the problem but obviously leaves the site unprotected.

Support Python 3

Possible features: Check database security?

I wonder if you've considered checking whether the user to which the app connects has "too many" privileges in the database, and whether the DB connection itself is secure.

I just went through the process of testing whether my app on heroku was connecting to an Amazon RDS instance over SSL or not. It turns out that you can check this with the following code:

from django.db import connection
cursor = connection.cursor()
cursor.execute("show ssl")
assert  cursor.fetchone()[0] ==  "on"

Provided the sslinfo extension is running (see http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_PostgreSQL.html#PostgreSQL.Concepts.General.SSL)

It did also make me thing whether there are easy pickings, eg. to check that the app is not connecting to the DB as an admin user? It's kind of relevant when many people are doing their own sysadmin and dbadmin for small hobby projects.

Add optional support for Heartbleed headers

Add support for heartbleed-specific headers some utilities are checking for to ascertain a site's susceptibility to Heartbleed, if it's fixed or not, and a date when the fixes were applied:
http://heartbleedheader.com/

Add TravisCI/drone.io and coveralls.io support

Check for CSRF_COOKIE_SECURE

This should be set to True

HSTS needs subdomains option

Strict Transport Security is only respected on a per-domain basis if you don't add the includeSubDomains parameter. This should be enabled (or at least, configurable), because without it, cookies can be used on subdomains to attack the primary domain.

See pages 4 and 5 of this paper for more info:

http://w2spconf.com/2011/papers/session-integrity.pdf

SSL redirect optionally for GET requests only

I was wondering if it were useful for others as well if the SSL redirect mechanism could be restricted to GET requests only. This would be helpful for a site that would like to enable the SSL redirect, but receives non-HTTPS POST requests to a lot of different endpoints. Some clients would either not follow the redirect or switch to GET when making the second request using the new HTTPS location, which would not result in the intended action.

Put differently, what do you think adding the following config option?
ssl_redirect_supported_http_methods = GET

Move tests to a sub-package so manage.py test doesn't discover them in pre-1.6 Django