Django Security Talk Notes
Philip James, how long I’ve worked with Python and Django, background at EB
Introduction to the story, and the characters
Safe-ish: Talk about Django’s Security Model and how it tries to provide sane defaults for developers
Run-through of the parts of the django security model
XSS (brief definition)
Django escapes characters by default
How do you turn it off? Mark Safe, | n, safe
CSRF (brief definition)
Django has middleware that checks POST requests for a token
Token is stored in cookie, also
Could be better? Make cookie httponly
Side-effect: harder to JS. Also, only an issue if you’re already owned, so maybe not an issue?
How to get around it? csrf_exempt
SQLi (brief definition)
Django’s ORM makes clean sql, (even when given bad data?)
How to get around it: extra()/RawSQL()
Clickjacking protection (brief definition)
Django has middleware that sets headers browsers are supposed to respect
Which browsers? https://docs.djangoproject.com/en/1.8/ref/clickjacking/#limitations
How to get around it: xframe_options_exempt, xframe_options_deny, xframe_options_sameorigin
This one is less "out of the box" than the others, so won’t be talked about here.
Host Header Validation (brief definition)
Django verifies against allowed hosts in settings
What are django sessions?
Cookie-based by design
How can we make this better?
Overall: Vigilance. Be aware of uses of this within your product
XSS, CSRF, SQLi, Clickjacking: Have them all enabled, write rules to check for "escape-hatch" functions
Set the correct settings
SECURE_SSL_REDIRECT: How does it work?