1.
Django Web Application Security<br />By<br />Levi Gross<br />

2.
About Me<br />Blog: http://www.levigross.com/<br />Twitter:@levigross<br />Email: levi@levigross.com<br />Python for 5 years<br />Django for 2 ½<br />Computer Security for 8 years<br />Python and Django are amazing!<br />

3.
Who is attacking us<br />Bots<br />Malicious <br />SEO<br />Steal user info<br />Hackers<br />ScriptKiddies<br />Hackers<br />ÜberHackers<br />We will bankrupt ourselves in the vain search for absolute security. — Dwight D. Eisenhower<br />

4.
Django from a security standpoint <br />Django Rocks!<br />Salted SHA1 Hashes (Yummy)<br />sha1 $ e3164 $ 9595556c4f693158c232f0885d266fe30671ca8a<br />Take that Gawker!<br />Secure session framework<br />Automatic variable escaping<br />XXS<br />SQL Injection<br />CSRF (Cross Site Request Forgery) Protection<br />Protection against Email Header injection<br />Protection against Directory Traversal attacks<br />“If you think technology can solve your security problems, then you don’t understand the problems and you don’t understand the technology”. — Bruce Schneier<br />

5.
Web Vulnerabilities<br />Information Disclosure<br />Input Validation<br />Click Jacking<br />Session Hijacking<br />CSRF<br />Passwords<br />Denial of Service<br />0 days<br />In theory, one can build provably secure systems. In theory, theory can be applied to practice but in practice, it can't. — M. Dacier, Eurecom Institute<br />

6.
Information Disclosure<br />Your Parts are showing<br />

7.
Attack Surface<br />Admin Site<br />Defaults to /admin<br />Views & URLS<br />Can give someone an intimate view of your application.<br />File Locations<br />REST<br />Use Piston<br />Sentry<br />

8.
How to protect yourself<br />Never deploy with the default settings<br />Long URLS are the best (but your not out of the woods)<br />Change the file name/location of user content<br />Validate uploads<br />Remove unneeded software<br />if not chroot<br />

9.
Input Validation<br />XXS<br />SQL Injection<br />HTTP Response Splitting<br />Directory Traversal<br />CRLF Injection<br />

10.
Cross Site Scripting<br />Django Protects us by autoescaping output<br />return mark_safe(force_unicode(html).<br />replace('&', '&amp;').<br />replace('<', '&lt;').<br />replace('>', '&gt;').<br />replace(' " ', '&quot;').<br />replace(" ' ", '&#39;'))<br />|safe/{% autoescape off %} is not Safe<br />

11.
Here comes the sleep deprivation<br />My Template Code<br />Secure:<span class={{value}}>{{ value }}</span><br />Not Secure:<span class="{{value|safe}}">{{value|safe}}</span> <br />Using this value -> " onclick=alert(document.cookie) type="<br />Secure: <span class=&quot; onclick=alert(document.cookie) type=&quot;>&quot; onclick=alert(document.cookie) type=&quot;</span><br />Not Secure:<span class="" onclick=alert(document.cookie) type="">" onclick=alert(document.cookie) type="</span><br />Oops… <br />

12.
How to protect yourself <br />Use the ESAPI (Enterprise Security API)<br />" onclick=alert(document.cookie) type="<br />'&quot; onclick&#x3d;alert&#x28;document.cookie&#x29; type&#x3d;&quot;’<br />http://code.google.com/p/owasp-esapi-python/<br />Use Quotes<br />Use Sanitizers<br />lxml<br />html5lib<br />Use Whitelists<br />Use Markdown<br />

13.
SQL Injection<br />Python protects us<br />Parameterized queries according to PEP 249<br />Django’s ORM Protects us<br />parameterized queries<br />Person.objects.filter(first_name__icontains=fname,last_name__icontains=lname)<br />fname = % output -> <br />SELECT "secpre_person"."id", "secpre_person"."first_name", "secpre_person"."last_name" FROM "secpre_person" WHERE ("secpre_person"."first_name" LIKE % % ESCAPE 'apos; AND "secpre_person"."last_name" LIKE %s% ESCAPE 'apos; )<br />smart_unicode(x).replace("", "").replace("%", "").replace("_", "")<br />NEVER BUILD QUERYIES USING STRING FORMATTING<br />query = 'SELECT * FROM secpre_personWHERE last_name = %s' % lnamePerson.objects.raw(query) <br />UseParameterizedqueries<br />Person.objects.raw('SELECT * FROM secpre_personWHERE last_name = %s', [lname]) <br />

14.
HTTP Response Splitting<br />New Lines in the HTTP Headers<br />HTTP/1.1 302 Moved Temporarily<br />Date: Wed, 24 Dec 2003 15:26:41 GMT <br />Location: http://10.1.1.1/someview/?lang=foobar<br />Content-Length: 0 <br />HTTP/1.1 200 OK<br />Content-Type: text/html<br />Content-Length: 19 <html>Control</html> <br />Server: Apache<br />Content-Type: text/html <br />This was just found on Reddit last week<br />Kudos to Neal Poole from Matasano<br />Django to the rescue <br />Every HttpResponse object has this code<br /> if '' in value or '' in value:<br /> raise BadHeaderError("Header values can't contain newlines (got %r)" % (value))<br />

15.
CRLF Injection<br />Hijack email forms<br />to:”me@myaddress.comcc:bill.gates@microsoft.comcc:paul.allen@microsoft.com”<br />Django to the rescue<br /> if '' in val or '' in val:<br /> raise BadHeaderError("Header values can't contain newlines (got %r for header %r)" % (val, name))<br />

16.
Directory Traversal<br />../../../../../../../../../etc/passwd<br />Django should never serve static files<br />Your webserver should serve all static files and be locked into the web root directory<br />Never allow users to dictate what happends<br />Django Static Serve isn’t powerless<br />drive, part = os.path.splitdrive(part)<br /> head, part = os.path.split(part)<br /> if part in (os.curdir, os.pardir):<br /> # Strip '.' and '..' in path.<br /> continue<br />

17.
Click Jacking<br />Use X-FRAME<br />HTTP header X-FRAME-OPTIONS: DENY<br />https://github.com/paulosman/django-xframeoptions<br />Use a Framekiller<br /><script type="text/javascript"> if(top != self) top.location.replace(location); </script> <br />Beware of sites that you visit<br />

18.
Session Hijacking<br />FireSheep<br />Cookie info not sent over HTTPS<br />Pass the hash<br />SESSION_COOKIE_SECURE = True<br />SESSION_COOKIE_HTTPONLY = True<br />Sessions<br />Never store private data in clear text<br />Never display session data without escaping it<br />

19.
Cross Site Request Forgery<br /><imgsrc="http://bank.example.com/withdraw?account=bob&amount=1000000&for=mallory"><br />We are logged in so it works<br />Django protects us (unless we are really stupid)<br />HTTP/1.0 200 OK<br />Date: Mon, 17 Jan 2011 21:55:14 GMT<br />Server: WSGIServer/0.1 Python/2.7.1<br />Expires: Mon, 17 Jan 2011 21:55:14 GMT<br />Vary: Cookie<br />Last-Modified: Mon, 17 Jan 2011 21:55:14 GMT<br />ETag: "4030d6e6a6c31292791e61e8bc58b6e8"<br />Cache-Control: max-age=0<br />Content-Type: text/html; charset=utf-8<br />Set-Cookie: csrftoken=9260e87b366dd2be2515bffffec5a746; Max-Age=31449600; Path=/<br />

20.
Denial Of Service<br />Everything is vulnerable <br />Impossible to defend against every variant<br />Harden your server<br />Rate limiting<br />Do this on a server level<br />If you need to do this on a view level<br />https://gist.github.com/719502<br />Fine tune access methods for your views<br />restrict the HTTP method to the appropriate view<br />

21.
Passwords<br />Passwords are your biggest nightmare<br />Don’t trust them<br />Make sure that you are using SHA1<br />Even though it works md5 and crypt shouldn’t be used. <br />crypt should NEVER be used!!! <br />Rate limiting<br />Use Django-axes<br />http://code.google.com/p/django-axes/<br />Never rely on just a password<br />If you can use 2 factor authentication do it.<br />

22.
0 Day Protection<br />Run for the hills<br />Good security is like a big onion<br />Many layers<br />Bitter<br />Limit your exposure<br />Server monitoring<br />Remember a good programmer looks both ways before crossing a one way street.<br />

23.
Security Tips<br />Be wary of updates<br />Update on security releases<br />Beware of 3rd party apps<br />Separate work from play<br />Don’t rely on passwords<br />Fail2Ban<br />Stick with Django<br />Be careful where you stray<br />Scan often<br />Skipfish<br />

24.
Questions? <br />