SECRET_KEY
a secret.Django's development team is strongly committed to responsible reporting and disclosure of security-related issues, as outlined in Django's security policies.As part of that commitment, they maintain an historical list of issues which have been fixed and disclosed. For the up to date list, see the archive of security issues (https://docs.djangoproject.com/en/1.8/releases/security/).
The golden rule of web application security is to never trust data from untrusted sources. Sometimes it can be useful to pass data through an untrusted medium. Cryptographically signed values can be passed through an untrusted channel safe in the knowledge that any tampering will be detected.Django provides both a low-level API for signing values and a high-level API for setting and reading signed cookies, one of the most common uses of signing in web applications.You may also find signing useful for the following:
When you create a new Django project using startproject
, the settings.py
file is generated automatically and gets a random SECRET_KEY
value. This value is the key to securing signed data-it is vital you keep this secure, or attackers could use it to generate their own signed values.
Django's signing methods live in the django.core.signing
module. To sign a value, first instantiate a Signer
instance:
>>> from django.core.signing import Signer >>> signer = Signer() >>> value = signer.sign('My string') >>> value 'My string:GdMGD6HNQ_qdgxYP8yBZAdAIV1w'
The signature is appended to the end of the string, following the colon. You can retrieve the original value using the unsign
method:
>>> original = signer.unsign(value) >>> original 'My string'
If the signature or value have been altered in any way, a django.core.signing.BadSignature
exception will be raised:
>>> from django.core import signing >>> value += 'm' >>> try: ... original = signer.unsign(value) ... except signing.BadSignature: ... print("Tampering detected!")
By default, the Signer
class uses the SECRET_KEY
setting to generate signatures. You can use a different secret by passing it to the Signer
constructor:
>>> signer = Signer('my-other-secret') >>> value = signer.sign('My string') >>> value 'My string:EkfQJafvGyiofrdGnuthdxImIJw'
django.core.signing.Signer
returns a signer which uses key
to generate signatures and sep
to separate values. sep
cannot be in the URL safe base64 alphabet. This alphabet contains alphanumeric characters, hyphens, and underscores.
If you do not wish for every occurrence of a particular string to have the same signature hash, you can use the optional salt
argument to the Signer
class. Using a salt will seed the signing hash function with both the salt and your SECRET_KEY
:
>>> signer = Signer() >>> signer.sign('My string') 'My string:GdMGD6HNQ_qdgxYP8yBZAdAIV1w' >>> signer = Signer(salt='extra') >>> signer.sign('My string') 'My string:Ee7vGi-ING6n02gkcJ-QLHg6vFw' >>> signer.unsign('My string:Ee7vGi-ING6n02gkcJ-QLHg6vFw') 'My string'
Using salt in this way puts the different signatures into different namespaces. A signature that comes from one namespace (a particular salt value) cannot be used to validate the same plaintext string in a different namespace that is using a different salt setting. The result is to prevent an attacker from using a signed string generated in one place in the code as input to another piece of code that is generating (and verifying) signatures using a different salt.
Unlike your SECRET_KEY
, your salt argument does not need to stay secret.
TimestampSigner
is a subclass of Signer
that appends a signed timestamp to the value. This allows you to confirm that a signed value was created within a specified period of time:
>>> from datetime import timedelta >>> from django.core.signing import TimestampSigner >>> signer = TimestampSigner() >>> value = signer.sign('hello') >>> value 'hello:1NMg5H:oPVuCqlJWmChm1rA2lyTUtelC-c' >>> signer.unsign(value) 'hello' >>> signer.unsign(value, max_age=10) ... SignatureExpired: Signature age 15.5289158821 > 10 seconds >>> signer.unsign(value, max_age=20) 'hello' >>> signer.unsign(value, max_age=timedelta(seconds=20)) 'hello'
sign(value)
signs value
and appends the current timestamp.
unsign(value, max_age=None)
checks if value
was signed less than max_age
seconds ago, otherwise raises SignatureExpired
. The max_age
parameter can accept an integer or a datetime.timedelta
object.
If you wish to protect a list, tuple or dictionary you can do so using the signing module's dumps
and loads
functions. These imitate Python's pickle module, but use JSON serialization under the hood. JSON ensures that even if your SECRET_KEY
is stolen an attacker will not be able to execute arbitrary commands by exploiting the pickle format:
>>> from django.core import signing >>> value = signing.dumps({"foo": "bar"}) >>> value 'eyJmb28iOiJiYXIifQ:1NMg1b:zGcDE4-TCkaeGzLeW9UQwZesciI' >>> signing.loads(value) {'foo': 'bar'}
Because of the nature of JSON (there is no native distinction between lists and tuples) if you pass in a tuple, you will get a list from signing.loads(object)
:
>>> from django.core import signing >>> value = signing.dumps(('a','b','c')) >>> signing.loads(value) ['a', 'b', 'c']
django.core.signing.dumps(obj, key=None, salt='django.core.signing', compress=False)
Returns URL-safe, sha1 signed base64 compressed JSON string. Serialized object is signed using TimestampSigner
.
django.core.signing.loads(string, key=None, salt='django.core.signing', max_age=None)
Reverse of dumps()
, raises BadSignature
if signature fails. Checks max_age
(in seconds) if given.
If your deployment situation allows, it's usually a good idea to have your front-end web server perform the functionality provided by the SecurityMiddleware
. That way, if there are requests that aren't served by Django (such as static media or user-uploaded files), they will have the same protections as requests to your Django application.
The django.middleware.security.SecurityMiddleware
provides several security enhancements to the request/response cycle. Each one can be independently enabled or disabled with a setting.
SECURE_BROWSER_XSS_FILTER
SECURE_CONTENT_TYPE_NOSNIFF
SECURE_HSTS_INCLUDE_SUBDOMAINS
SECURE_HSTS_SECONDS
SECURE_REDIRECT_EXEMPT
SECURE_SSL_HOST
SECURE_SSL_REDIRECT
For more on security headers and these settings, see Chapter 17, Django Middleware.
In the next chapter, we will expand on the quick install guide from Chapter 1, Introduction to Django and Getting Started and look at some additional installation and configuration options for Django.