Pentesting django and rails

10,321 views
9,976 views

Published on

Published in: Technology
0 Comments
9 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
10,321
On SlideShare
0
From Embeds
0
Number of Embeds
1,735
Actions
Shares
0
Downloads
137
Comments
0
Likes
9
Embeds 0
No embeds

No notes for slide

Pentesting django and rails

  1. 1. PentestingDjango and Rails<br />By<br /> Levi Gross<br />
  2. 2. Python<br />Dangerous models<br />Pickle<br />Code execution<br />urllib<br />No SSL verification built in<br />file:// is valid<br />Redirects allow any file to be read (this was fixed in 2.7.2)<br />XSS in Basic HTTPServer<br />A wide open playground<br />But syntax is holy<br />Easy to execute code on the host system<br />eval<br />input<br />Pickle<br />No authentication<br />Code Execution<br />Unicode issues<br />C extensions<br />
  3. 3. Django<br />Auth Framework<br />Secure Session framework<br />Uses salted SHA1 hashes<br />Can use MD5 and crypt but will auto upgrade<br />Basic global permission structure<br />Cache backend uses pickle<br />Default use of Unicode <br />Default URLS<br />Exceptions don’t propagate back to the user<br />If the system is NOT in debug mode<br />Automatic variable escape<br />Built in CSRF protection<br />Unique hashes<br />In web forms, AJAX and the cookie<br />Default Admin site<br />Insecure form wizard<br />Fixed in 1.3<br />Compatible with Python 2.4 – 2.7<br />
  4. 4. Ruby<br />$SAFE isn’t really safe<br />Even layer 4 can be bypassed by exceptions<br />Patched but still insecure<br />SSL verification is disabled by default<br />And encouraged as it slows down you application<br />Global Variables<br />Language syntax isn’t holy<br />C Extensions<br />Eval<br />FileUtils<br />remove_entry_secure<br />WEBrick issues<br />Buffer overflow in ARGF.inplace_mode= <br />
  5. 5. Rails<br />Secure session framework<br />Try not to store data in cookies<br />Remember base64 is not a method of encryption.<br />The database is your friend<br />No information should be put into cookies besides for the hash<br />If you need to put information within the cookie<br />Signed cookies<br />REST<br />Basic permissions<br />Default variable escape<br />Escaping SQL statements<br />CSRF Protection like Django <br />Use of site admin<br />Relies on 3rd party gem (but what doesn’t in rails)<br />
  6. 6. Django Information Disclosure<br />Using the default URLS<br />Default paths for media<br />Admin URLs<br />Putting DB fields in URLs<br />URLS == Views<br />Switching GET and POST<br />Popular Djangoapps don’t always adhere to secure princeables<br />Dajax<br />Exceptions propagate back to the user<br />Celery<br />Pickle<br />Piston<br />Object Level permissions<br />Sentry<br />Default URLS<br />Raw template code in html comments<br />
  7. 7. Rails Information Disclosure<br />Using insecure gems<br />Letting exceptions propagate to a user<br />Raw template code in the page<br />View logic written in Javascript<br />Default URLS<br />Object ID’s in the URL<br />
  8. 8. Countermeasures<br />Never let exceptions propagate to end user<br />Don’t paste your raw tracebacks directly into any public online location.<br />Sanitize them<br />Don’t rely on anything here for security<br />
  9. 9. HTTP Sessions in Django & Rails<br />Django<br />Each session is a unique hash value<br />Cookies can be read via javascript<br />Predictable cookie name ‘sessionid’<br />Uses the pickle model to serialize data<br />Defaults to an insecure cookie<br />Values are stored in the session backend<br />No default cookie domain<br />File backend allows for reading on /tmp folder<br />Immune to classic cookie poisoning <br />Rails<br />Signed cookies<br />Default storage is to the cookie…<br />
  10. 10. Session Hijacking in Django and Rails<br />Once you have the cookie you have the user….<br />
  11. 11. Cookie Poisoning in Django and Rails<br />Django<br />Django defaults to it’s session backend which doesn’t do this.<br />Rails <br />Rails allows you to shoot yourself in the foot.<br />Attack<br />Django<br />People will still use request.COOKIES<br />Server setup can cause issues with session backend<br />Rails<br />Any classic cookie poisoning attack<br />Storing info in cookies<br />Not signing cookies<br />Using cookies to manipulate view logic<br />
  12. 12. Countermeasures<br />General<br />Cycle sessions when user authenticates<br />Use a cryptographic nonce<br />Use Sticky Sessions<br />Django<br />Make sure you use Djangos session Application<br />Use a consistent session backend<br />Escape and Validate all data<br />Make sure you set the following settings<br />HTTP_ONLY (Only in 1.3) <br />Safari ignores this value<br />SECURE<br />Change the cookie name<br />Serialize using JSON or YAML<br />Rails<br />Sign cookies<br />Never trust your user data<br />Make the cookies secure and HTTP only<br />Use the DB/ KV store to store session data<br />Send the user a hash<br />Clear the sessions after login<br />
  13. 13. XSS in Django<br />Auto escapes ‘<>&” with their “safe alternatives”<br />Problems<br />Any other Unicode will bypass this check<br />If items are not properly quoted you can still inject attributes into tags<br />Other special characters aren’t escaped ( )<br />Designers<br />Hate |safe and just use {% autoescape off %}<br />
  14. 14. XSS in Rails<br /> 2.x <br />Variables aren’t automatically escaped<br />Tags are stripped using the strip_tags method<br />3.x<br />Automatic variable escape<br />Unless you use raw<br />or some other function that doesn’t return safe output<br />Attack<br />White lists are useless<br />selselectect <scri<script>pt><br />Sanitizing the HTML special characters has the same issue Django has.<br />Inconsistent sanitization of data<br />link_to , textile, tag, content_tag<br />When faced with ambiguous input (concatenation of safe and unsafe data) will default to unsafe<br />Sanitizing doesn’t always work. <br />AJAX still isn’t escaped<br />RJS isn’t automatically escaped<br />
  15. 15. Countermeasures<br />General<br />Force the browser to use UTF-8<br />Never trust user input<br />Don’t use user input for HTML tag attributes<br />Take a page out of the python zen<br />In the face of ambiguity, refuse the temptation to guess.<br />Django<br />Use the OWASP ESAPI<br />If you need styling<br />Use Sanitizers<br />lxml<br />bleach<br />Use markdown<br />Use whitelists not blacklists<br />Rails<br />Escape all user input<br />before_filter :only => […] instead of :except => […]<br />Explicitly sanitize data<br />sanitize()<br /><=%sanitize {template tag} %><br />
  16. 16. CSRF in Django<br />Built in CSRF protection<br />Recently updated to include AJAX<br />In the form and the HTTP headers/Cookie<br />Attacks<br />It’s annoying so people turn it off<br />document.write() breaks it<br />Only recently do they check AJAX request<br />Doesn’t work for subdomains<br />
  17. 17. CSRF in Rails<br />Recently updated to include AJAX<br />REST makes things harder…<br />Stored in the cookie<br />Attacks<br />People don’t think they need it<br />A XSS exploit renders this protection useless.<br />Same subdomain issue<br />
  18. 18. HTTP Parameter Poisoning<br />Directory Traversal / Local file inclusion<br />http://someserver/somepage/?val=g&file=../../../../../../etc/passwd<br />http://somesite/file_download/file=../config/database.yml<br />HTTP Response Splitting<br />Injecting /r/n into fields splitting the response headers (XXS like affect) <br />Remote file inclusion<br />/myview?someparam=C:ftpuploadexploit<br />Invalid method<br />Using a POST in place of a GET and vis a vis<br />Referrer poisoning<br />http://someserver/somepage/?val=g&referrer=<myurl><br />
  19. 19. HTTP Parameter Poisoning in Django<br />Django is immune to <br />Directory Traversal<br />HTTP Response Splitting<br />Remote file inclusion<br />Referrer Poisoning<br />Forms cleaned_data allows for value escaping<br />Attacks<br />Switching GET and POST are not enforced<br />Not all HTTP Parameters are autoescaped by default<br />Cache and sessions use pickle<br />
  20. 20. HTTP Parameter Poisoning in Rails<br />Blind use of HTTP parameters<br />Invalid file name checking<br />arbitrary file upload and execution<br />XSS<br />Remember use AJAX<br />Privilege escalation<br />SQL Injection<br />Blind Redirection<br />File includes<br />
  21. 21. Exploiting Logic Flaws in Django &Rails <br />Django<br />@login_required<br />Permissions are global<br />Objects are serialized<br />Arbitrary input may have some exciting outcomes<br />Logic manipulation<br />debug=True<br />Remember in python nothing is sacred<br />Rails<br />explicit authentication<br />explicit permission checking<br />Permissions not always object based<br />Ruby syntax is extendable <br />
  22. 22. SQL Injection<br />Cookies<br />HTTP Parameters<br />Logic Flaws<br />XSS<br />
  23. 23. SQL Injection in Django<br />Parameterized queries<br />LIKE queries are escaped<br />Attacks<br />WHERE is still injectable<br />People use cursor.raw() all the time<br />Character escaping is always being broken<br />More python unicode fun….<br />
  24. 24. SQL Injection in Rails<br />Uses regex to “escape” values<br />*.connection.quote<br />Very easy to execute raw SQL<br />where<br />order<br />
  25. 25. Counter Measures<br />Rails<br />Parameterized queries<br />Be wary of what your users give you<br />Validate and sanitize all input<br />Only use permissions that you need<br />Encrypt sensitive data<br />
  26. 26. Passwords in Django<br />Brute force friendly<br />Salted SHA1 hashes<br />The core developers don’t want to upgrade anytime soon.<br />Incompatible with Python 2.4<br />Timing attacks<br />Mitigation added in 1.3 but some implementations flawed due to string interning<br />Compatible with older insecure hashes<br />The Achilles heel of any system<br />
  27. 27. Passwords in Rails<br />No authentication<br />Very popular<br />REST Authentication<br />Blind use of params[:]<br />Clear text passwords in the logs<br />Brute force friendly<br />Salted hashes<br />Good but not perfect<br />Timing attacks<br />
  28. 28. Authentication<br />OAUTH<br />Everyone forgets to use SSL<br />Even if you do your still opening yourself up to a Man In The Middle Attack<br />Permissions<br />Django<br />Not object based<br />Best<br />Worst<br />
  29. 29. Countermeasures<br />Dual factor authentication<br />Rate limit authentication logic<br />Monitoring<br />Tough object level permissions<br />Whitelists/blacklists<br />Certificate authentication to verify the provider<br />
  30. 30. Denial of Service in Django & Rails <br />Remember the GIL (Global Interpreter Lock)<br />No rate limiting<br />Switching HTTP methods<br />Python<br />Virtual methods calls<br />Ruby<br />Slow method dispatch<br />
  31. 31. DDOS Mitigation<br />Rate Limit<br />By IP<br />By View/Process<br />Use Background processing<br />Django<br />Celery<br />Rails<br />Gearman<br />Allow for graceful failure of website services<br />Take a page out of web application scaling<br />
  32. 32. Recommended Resources <br />Django<br />http://www.djangobook.com/en/2.0/chapter20/<br />http://readthedocs.org/docs/playdoh/en/latest/<br />Rails<br />http://www.rorsecurity.info/<br />http://groups.google.com/group/rubyonrails-security<br />
  33. 33. Questions<br />levi@levigross.com<br />

×