Django Security

About Me⌘ Levi Gross

⌘ Chapter Leader at OWASP NYC

⌘ Security Consultant at Matasano

⌘ Previously responsible for the development and security of a large Django application.

What is Django⌘ A web application framework written in

Python• MVC

⌘ “Secure” by default⌘ Loosely coupled by default⌘ Batteries included

• Admin• Auth• Sessions• Permissions

Frameworks are Taking over⌘ ORMS

• With Parameterized Queries⌘ Automatic escaping on “unsafe” data

• Output encoding⌘ Robust handling of HTTP headers

• Eliminates HTTP Response splitting⌘ Pain free secure session handling

What is new in Django 1.4

⌘HTTPonly cookies by default⌘The SECRET_KEY is required⌘Enhanced CSRF protection⌘Cryptographic Helpers⌘Password Hashers⌘ CSRF protection in the Admin

Application⌘A Page dedicated to security

• Finally!!

What is new in Django 1.4 Cont.⌘ @sensitive_variables

• 'API|TOKEN|KEY|SECRET|PASS|PROFANITIES_LIST|SIGNATURE’

⌘ Session Cookie can be modified⌘ Hashed passwords shielded with the

Admin⌘ Protection against cryptographic timing

attacks• Somewhat

⌘ Generic views prevent HTTP verb tampering and enhance CSRF protection

⌘ Automatic Clickjacking protection

Password Hashers⌘ Salted SHA1 hashes are gone! (Kinda)

⌘ PBKDF2 with 10000 iterations by default

⌘ Easy to extend and enhance

⌘ Bcrypt support built-in

Example

Signed Cookies⌘ Signed not encrypted

⌘ Open to replay attacks• Cookie refreshes every 2 weeks by default

⌘ Cookie is compressed using zlib

Enhanced CSRF Protection⌘ Random SHA256 hash⌘ Cross HTTP/HTTPS protection⌘ Rejects all “safe” methods

• 'GET', 'HEAD', 'OPTIONS', 'TRACE’⌘ Now you can customize the cookie

• Name• Domain• Path• Secure

Cryptographic Helpers

• The key defaults to your SECRET_KEY

• Uses Pythons built-in HMAC • SHA1

• Custom key/salt• Time based signing as well

View Protection⌘ HTTP Verb manipulation

• Generic views require a specific method for every HTTP method• def get(self, request,*args, **kwargs):• Don’t use function based views

⌘ Automatic CSRF protection without any “extras”• no more dealing with request context

⌘ Regex based URL routing

Things aren’t perfect just yet⌘ Invalid logic⌘ Issues with timing attacks⌘ Confusing code constructs

• user.set_password(UNUSABLE_PASSWORD)⌘ CRUD Permissions

• Not object based⌘ Insecure usage of standard libraries

• Serialized data isn’t signed or encrypted• Pickle• YAML is loaded insecurely

⌘ Mass Assignment?• Django’s model forms

XSS Even with Autoescaping

⌘ This is still vulnerable if you use the input as a HTML tag attribute• <span class={{user_input}} >

• Queryset().order_by • Queryset().extra() does not support

parameterized queries

SQLi in Django

Blind Redirect on Login⌘ Functionality relies on urlparse which

does not decode the URL

Solution?⌘ Framework only go so far

⌘ Even engines cannot help us

⌘ We don’t educate developers properly

⌘ We don’t provide them with the right resources

⌘ We need to give them a boost!

Webpwny

DjanGoat!

What is DjanGoat⌘ A Learning Tool To Help Pen Testers Learn

How To Break Django Based Web Application

⌘ A Point Of Reference To Learn How to Write Secure Django Applications

⌘ Unlike WebGoat, Djangoat Better Simulates A Real-World Application

Why DjanGoat⌘ Developers always making the same

mistakes• Lack of GOOD examples

⌘ I am a fan of Django

Why a real web application?⌘ This will be a banking application

• Developers will identify with code and constraints that they encounter daily

⌘ This puts the developer in the pen testers chair

⌘ Great for Students

⌘ Pen testers love full applications

Layers of insecurity⌘ There will be a range of challenges

provided

⌘ Useful for both a developer and a pen tester

The Goal⌘ Developers need to learn how

vulnerabilities are introduced into applications.

⌘ Pen testers need an example of insecure Django code

⌘ Django needs to grow.⌘ Django needs to be used in a security

conscious way.

Questions