DjangoCon 2011 – Advanced security topics

After a great lunch at the food trucks we’re starting off with a talk on “Advanced Security Topcis” by Paul McMillan. I’ve been excited for this talk for a while, it looks like it’s going to be great.

An in-depth look (with demonstrations) at the how and why of several advanced security topics. Discussion of ways to improve security of the framework moving forward.

You’ll be able to find the slides at once they’re up.

Updates Below:


The talk is now wrapped up. Stay tuned for “Deployment, Daemons and Datacenters”


Django-secure has a command called check_secure which tells you what you need to change.


Django Core should have a more secure hashing algorithm by default. BCrypt or something similar


Talk has ended. Answering questions now. A reading he suggested was Web Application Hackers Handbook


The TL;DR:

  • Redirect non-SSL to SSL. Use HSTS if you can
  • Follow the advice of django-secure
  • Configure request rate-limiting for key urls
  • Set URLField.verify_exists == False
  • Don’t send wildcard host requests to Django
  • Avoid random.Random(). Use random.SystemRandom() instead
  • Use django.utils.crypto.salted_hmac() instead of plain MD5 and SHA1 in most cases
  • Namespace cache keys. Namespace hmac
  • Use django.utils.crypto.constant_time_compare()
  • Consider information leakages before they are an issue
  • Never unpickle user-supplied pickles
  • THINK before you use a snippet. Don’t bypass built in protections
  • Don’t assume sane defaults


Be careful with Pickle

  • Stores object static
  • Sace efficient
  • Runs arbitrary code #BAD


For random numbers use random.SystemRandio()

  • Cryptographically secure
  • not supported everywhere (jython)
# Bad
import random
token = ''.join([random.choice(allowed_chars) for in in range(length)])


Never use random.Random() for security purposes. It’s fast but not cryptographically secure.


Rate limit your login and APIs

Apache – mod_evasive
Nginx – HttpLimitReqModule


You can poll a Django admin, unsuccessful username takes slightly longer than usernames that don’t exist


With a decent computer (personal) you could try roughly 500,000,000 hashes per second with the Django password hashing


Timing Attacks

Derive information from how long the function takes to return.


Security Tip #1: Never put a full database dump in a Github repo (or any repo)


Use django-secure to help identify security issues.


Must use HTTP cookies.


Paul is trying to get a demo going. Has opened kismet.


SSL – safe and secure (when implemented properly).


Paul taking the stage