Erik Romijn: Keeping Django chained; seven top security concerns for Django websites
Erik Romijn talks about keeping Django chained (seven top security concerns for Django websites), at PyGrunn.
See the PyGrunn website for more info about this one-day Python conference in Groningen, The Netherlands.
This is not only for Django sites, but may apply to other websites as well.
I have created http://ponycheckup.com and https://www.securedjango.com
1. Improper deployment of HTTPS.
Or: not deploying it at all. Always use https if you have anything non-public. So: anything that requires a login.
Why? Encryption of traffic. Verification of server identity and authenticity of data: nice that no one can listen in on your password, but if you send it securely to an identity thief, it is still not very secure.
- Enable HTTPS with a proper certificate. It need not be expensive, but do not let your users click to accept your certificate: they will just always click to accept it anyway, which is bad.
- Enforce HTTPS on your entire domain: never deploy it partially.
- Configure redirects and HSTS to enforce HTTPS usage. HSTS is a signal to your browser that it may never connect to a certain page via plain HTTP.
- Set the secure flag on all cookies.
- Configure proper ciphers: https://www.ssllabs.com/ssltest/
2. Failure to authorize users
Nice that a user is logged in, but is she allowed to view and do everything? Probably not.
You can filter on owner for some tables:
queryset.filter(owner=self.request.user)
You may generalize this into mixins and decorators, but you should keep them transparent and simple.
Distrust yourself: add tests for this. Do not only test that things work as they should, but also that they break as they should.
3. Cookie backed sessions with secret key leak
This is optional in Django. It is standard in Flask.
In this case the session data is in the cookie, instead of only a session id, as is normal. The server checks it with a secret key. If this key leaks out, anyone can hack any session.
Serialization is performed with pickle or JSON. pickle can serialize more than JSON can, but pickle should not be used on untrusted data. If you use cookie backed sessions and the key is leaked, the data from the cookie will be untrusted and an attacker can execute arbitrary code on your server.
So: do not use pickle for this.
4. SQL injection with Django
It is not needed, but if you really want to, usually for speed reasons, you can use raw SQL queries in Django.
There are safe ways of using execute on a cursor.
Be very careful.
5. Cookie attributes
- Secure: only send over HTTPS.
- HttpOnly: Do not allow access from client-side javascript.
- Domain: Only send to this domain and all subdomains.
[went a bit too fast]
6. Media access
The way we use use uploaded media. If you put uploaded files in a directory and allow access to it, someone may guess a filename and have access to something they should not know about.
You can use django-random-filestorage to mitigate this.
7. Outdated Django versions
I can understand that you are one major version behind, but please keep up to date on the latest minor releases. It is seldom that a security fix has unwanted side effects.
@erikpub at Twitter.