1 / 24

Django Security

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

thy
Download Presentation

Django Security

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Django Security

  2. 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.

  3. What is Django • A web application framework written in Python • MVC • “Secure” by default • Loosely coupled by default • Batteries included • Admin • Auth • Sessions • Permissions

  4. 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

  5. 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!!

  6. 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

  7. Password Hashers • Salted SHA1 hashes are gone! (Kinda) • PBKDF2 with 10000 iterations by default • Easy to extend and enhance • Bcrypt support built-in

  8. Example

  9. Signed Cookies • Signed not encrypted • Open to replay attacks • Cookie refreshes every 2 weeks by default • Cookie is compressed using zlib

  10. 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

  11. Cryptographic Helpers • The key defaults to your SECRET_KEY • Uses Pythons built-in HMAC • SHA1 • Custom key/salt • Time based signing as well

  12. 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

  13. 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

  14. XSS Even with Autoescaping • This is still vulnerable if you use the input as a HTML tag attribute • <span class={{user_input}} > SQLi in Django • Queryset().order_by • Queryset().extra() does not support parameterized queries

  15. Blind Redirect on Login • Functionality relies on urlparse which does not decode the URL

  16. 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!

  17. Webpwny

  18. DjanGoat!

  19. 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

  20. Why DjanGoat • Developers always making the same mistakes • Lack of GOOD examples • I am a fan of Django

  21. 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

  22. Layers of insecurity • There will be a range of challenges provided • Useful for both a developer and a pen tester

  23. 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.

  24. Questions

More Related