Shiny, Let’s Be Bad Guys: Exploiting and Mitigating the Top 10 Web App Vulnerabilities
2 likes3,569 views
This document provides an agenda for a session on exploiting and mitigating the top 1 web application vulnerabilities according to OWASP. The session will run from 9:00 AM to 12:20 PM with a 20 minute break at 10:50 AM and a lunch break from 12:20 PM to 1:20 PM. The session will discuss injection attacks, broken authentication and session management, cross-site scripting, insecure direct object references, security misconfiguration, sensitive data exposure, missing function level access control, cross-site request forgery, using known vulnerable components, and unvalidated redirects and forwards. Prevention strategies and Django-specific advice will also be provided for each vulnerability.
Shiny, Let’s Be Bad Guys: Exploiting and Mitigating the Top 10 Web App Vulnerabilities
- 1. Shiny, Let’s Be Bad Guys! Exploiting and Mitigating the Top 1 Web App Vulnerabilities 0 Mike Pirnat - @mpirnat David Stanek - @dstanek Text
- 3. Schedule & Lunch • This session will run 9:00 AM - 12:20 PM • 20-minute break at 10:50 AM • Lunch 12:20 PM - 1:20 PM • Lunch moved to Exhibit Hall D
- 4. Volunteering Opportunities • Low-commitment! Fun! • SWAG bagging: Thursday 4-8 PM • Just do 10 bags! (~1/2 hr) • Registration Desk: any time • 1-2 hours helps • Friday => meet everyone!
- 5. Volunteering Info • Current needs: http://bit.ly/pycon-volunteering-status • More information: http://bit.ly/pycon2013-volunteer
- 6. Tutorial Feedback • Go here: • https://www.surveymonkey.com/s/ pycon2013_tutorials or • https://goo.gl/PvHDc • Be honest!
- 8. QWho here has vulnerable apps?
- 9. Why it Matters • Your users • Your data • Your business
- 10. OWASP • http://www.owasp.org • Open Web Application Security Project • Non-profit focused on improving software security • Documentation and tools to help learn about security and protect your apps
- 11. OWASP Top Ten • Based on risk data from 8 firms • Over 500,000 vulnerabilities, hundreds of orgs, thousands of apps • Selected & prioritized by prevalence data combined with estimates of exploitability, detectability, and impact • Recently updated for 2013!
- 12. Today • Background on a type of vulnerability • Exploit it! • Discuss prevention • Django-specific advice where possible
- 13. Disclaimer
- 14. Setup: 1 Make a virtualenv: $ virtualenv badguys $ cd badguys $ source bin/activate
- 15. Setup: 2 Clone our repository: $ git clone https://github.com/ mpirnat/lets-be-bad-guys src Or pull the latest changes: $ cd src $ git pull
- 16. Setup: 3 Install dependencies: $ cd src $ pip install -r requirements.txt
- 17. Setup: 2 & 3 (Offline/USB) • Extract the project: $ mkdir src $ unzip /Volumes/BADGUYS/project/ badguys.zip -d src/ • Install dependencies: $ cd src $ pip install -r requirements.txt -i file:///Volumes/BADGUYS/software
- 18. Setup: 4 Start up the app: $ python manage.py runserver
- 19. Find a Partner
- 20. 1 Injection
- 21. Injection Attacks • When an application sends untrusted data to an interpreter • Can result in data loss/corruption, lack of accountability, denial of access • Can lead to complete host takeover
- 22. Trust No One • External users • Internal users • Administrators
- 23. Attack Vectors • GET parameters • POST parameters • PATH_INFO • Some HTTP headers: Cookie, Host • Uploaded Files
- 24. Possible Consequences • Creation of malicious SQL (or other queries) • Accessing private files on disk • Arbitrary code execution
- 25. Real-World Examples • Sony Playstation Network • Ruby on Rails • http://es.pn/Z0jnoi
- 26. SQL Injection • Unescaped user input causes the premature end of a SQL query and allows a malicious query to be executed... """ select * from users where username='%s'; """ • http://localhost:8000/injection/sql
- 27. Accessing Private Files • File system access + unvalidated user input allows attackers to navigate the file system • http://localhost:8000/injection/file- access
- 28. Arbitrary Code Execution • Unsafe input is dynamically evaluated or executed • http://localhost:8000/injection/code- execution
- 29. Prevention • Validate ALL user input • Sign cookies, don’t accept if signature is bogus/missing • Use ORMs or bind variables when talking to the database • Don’t use eval or exec, beware of pickle, user-supplied YAML, etc.
- 30. Django Advice • Make sure data types for your model are tight • Use Forms instead of ModelForms for stronger validation • Make new validators as needed for your application • Make sure your URL regexes for dynamic URLs are tight
- 31. Django Advice • Use the ORM when you can • When you can’t, use extreme caution! • Bind variables • No string concatenation/formatting of anything that came from the client
- 32. 2 Broken Authentication & Session Management
- 33. Broken Auth & Session Management • Attacker uses leaks or flaws in authentication or session management to impersonate users • Roll-your-own solutions contribute to the difficulty of finding these flaws
- 34. Possible Consequences • Compromised user accounts • Compromised administrative accounts • Unauthorized use of privileged functionality
- 35. Prevention • Hash or encrypt passwords • Don’t let credentials be easily overwritten • Don’t put session IDs in URLs • Allow session IDs to timeout/log out • Rotate session IDs after successful login • TLS connections for passwords, session IDs
- 36. Django Advice • Use django.contrib.auth • Consider https://github.com/yourlabs/ django-session-security middleware for timing out sessions • We’ll talk about transport layer security later on...
- 37. 3 Cross-Site Scripting (XSS)
- 38. XSS Attacks • Cross-Site Scripting (XSS) • The most prevalent web app security flaw • App includes user-supplied data in content sent to the browser without properly validating or sanitizing it
- 39. XSS Attacks • Stored: injected code permanently stored in database, message forum, comment, etc. • Reflected: injected code in live request to server, reflected back in error message or search result • DOM: injected code in browser DOM environment that causes scripts to run in unexpected ways (eg, reading from URL)
- 40. Possible Consequences • Execute scripts in a victim’s browser • Hijack sessions • Deface sites • Insert hostile content • Redirect users • Hijack browser (install malware)
- 41. Most Often Seen... • Places where user-created text is displayed to other users (comments, messages) • Form inputs where value is populated with user-supplied data • Script tags where user-supplied data is populated into script variables
- 42. XSS in Dynamic URLs • Part of the URL path is variable, isn’t validated, and gets included into the page • http://localhost:8000/cross-site- scripting/path-matching/your-path- here
- 43. XSS in Query String Parameters • Unvalidated user input from a query string parameter is included in the page • http://localhost:8000/cross-site- scripting/query-params?qs=awesome
- 44. XSS in Form Fields • The value part of an input is prematurely terminated, allowing Javascript to be injected into the element (eg, adding an onclick) • http://localhost:8000/cross-site- scripting/form-field
- 45. Q Can you trust the database?
- 46. Prevention • Escape all untrusted data based on the HTML context the data will be placed into • Whitelist input validation • Consider auto-sanitization libraries for rich content (eg, OWASP’s AntiSamy) • Update your parents’/in-laws’ browsers!
- 47. Django Advice • Be careful with the safe filter, django.utils.safestring, etc. • Be careful with your own template tags; django.utils.html.escape is your friend! • Use form.as_p, form.as_table, form.as_ul
- 48. 4 Insecure Direct Object References
- 49. Insecure Direct Object Reference • Expose a reference to an internal implementation object without verifying authorization • Attacker changes URL or GET/POST parameters, cookies
- 50. Possible Consequences • Compromise of all data that can be referenced by the vulnerable parameter • Unless the namespace is sparse, an attacker can easily access all available data of that type
- 51. Exercises • Manipulate parameters in the URL to access data that doesn’t belong to you • http://localhost:8000/direct-object- references
- 52. Prevention • Implement access controls on any direct references to restricted resources • Implement per-user or per-session indirect object references
- 53. Django Advice • Use permissions architecture to lock down views • Customize queryset for looking up objects that involve user ownership
- 54. 5 Security Misconfiguration
- 55. Security Misconfiguration • Insecure application settings • Unpatched flaws • Unused pages
- 56. Possible Consequences • Unauthorized access to some system data or functionality • Potential complete system compromise
- 57. Exercises • Demos and discussion • http://localhost:8000/misconfiguration
- 58. Prevention • Have a repeatable hardening process • Have a process for keeping on top of updates and patches • Architecture that provides secure separation between components • Periodic scans and audits
- 59. Django Advice • Don’t run in debug mode in production • Keep your SECRET_KEY secret! • Keep Python code out of webserver’s root • Don’t run admin publicly (if you can help it) • Don’t use the built-in admin for normal user admin tasks
- 60. Q Gateway to Social Engineering?
- 61. 6 Sensitive Data Exposure
- 62. Sensitive Data Exposure • Failure to properly protect credit cards, tax ids, authentication credentials, etc. • Sensitive data deserves extra protection such as encryption at rest or in transit, special precautions when exchanged with the browser
- 63. Insecure Cryptographic Storage • Not encrypting worthy data • Unsafe key generation & storage, failure to rotate keys • Weak algorithms • Weak or unsalted hashes
- 64. Insufficient Transport Layer Protection • May not authenticate, encrypt, and protect the confidentiality and integrity of sensitive network traffic • May use weak algorithms • May use expired or invalid certificates • May use certificates incorrectly
- 65. Possible Consequences • Compromise of all data that should have been encrypted • This can be highly sensitive information: credentials, credit cards, personal data, health records, etc.
- 66. Possible Consequences • Expose individual users’ data • Account theft • Compromise an admin account?! • Poor SSL setup can facilitate phishing and man-in-the-middle attacks
- 67. Attack Vectors • Attacker monitors network traffic of your users • Maybe in public places (Starbucks, conference wi-fi, etc.) • Maybe back end connections • Maybe inside your network (!!!)
- 68. Prevention • Encrypt sensitive data at rest • Encrypt offsite backups; manage keys separately • Use strong standard algorithms, strong keys • Hash passwords with strong standard algorithm & use appropriate salt • Protect passwords & keys from unauthorized access
- 69. Prevention • Require SSL for all sensitive pages; redirect non-SSL requests to SSL • Set the “secure” flag on sensitive cookies • Use only strong SSL algorithms • Ensure your cert is valid, not expired, not revoked, and matches your domain • SSL/encryption on the back end too
- 70. Django Advice • Use django.contrib.auth for proper password salting and hashing • Require SSL in Apache or Nginx • Require SSL using middleware: • http://www.redrobotstudios.com/blog/2010/02/06/ requiring-https-for-certain-paths-in-django/ • http://djangosnippets.org/snippets/2833/ • http://djangosnippets.org/snippets/1467/
- 71. 7 Missing Function Level Access Control
- 72. Missing Function Level Access Control • Application doesn’t protect its functions properly • Misconfiguration • Forgot proper code checks
- 73. Attack Vectors • Authorized user changes a URL or parameter to a privileged function • Anonymous users could access private functions that aren’t protected
- 74. Possible Consequences • Compromised user accounts • Compromised administrative accounts • Unauthorized use of privileged functionality
- 75. Exercises • Manipulate the URL to access privileged functionality • http://localhost:8000/missing-access- control
- 76. Prevention • Consider every page; public or private? • If authentication is required, make sure that checks are in place • If additional authorization is required, make sure that checks are in place • Deny all by default; explicitly grant access to users or roles
- 77. Django Advice • Use the permissions architecture to lock down views • Don’t use the built-in admin for normal user admin tasks
- 78. 8 Cross-Site Request Forgery
- 79. CSRF Attacks • Cross-Site Request Forgery (CSRF) • Attacker tricks victim into submitting forged HTTP requests • Attack succeeds if user is authorized/ authenticated
- 80. Attack Vectors • Image tags • Cross-Site Scripting (XSS) • Fake buttons • Phishing forms • Other techniques
- 81. Possible Consequences • Cause victim to change any data the victim is allowed to change • Cause victim to perform any function the victim is authorized to use • Impact varies based on victim’s role • Think of some possibilities...
- 82. Real-World Examples • Facebook: http://amolnaik4.blogspot.com/ 2012/08/facebook-csrf-worth- usd-5000.html • Google/Gmail: http://cryptogasm.com/2012/02/does- google-understand-csrf/
- 83. CSRF via Image • Craft an “image” link that triggers some site functionality • http://localhost:8000/csrf/image
- 84. What if... <img src="http://example.com/ transferFunds?amount=1500& destinationAccount=attackersAcct#" width="0" height="0" />
- 85. CSRF via Form Post • Create an innocuous-looking form that POSTs to a vulnerable location • http://localhost:8000/csrf/third-party- site
- 86. Prevention • Don’t “do” things on a GET • Include a unique token in a hidden field (often used in concert with a cookie) • Validate token to make sure the request is from on-site • Avoid putting the token into a query string
- 87. Django Advice • Don’t change the built-in settings! • Do use the CSRF middleware and template tag in forms • Be VERY CAREFUL about deactivating it (csrf_exempt decorator) • Be careful about APIs (Tastypie, oauth)
- 88. 9 Using Known Vulnerable Components
- 89. Components with Known Vulnerabilities • Libraries, frameworks, and other modules almost always run with full privilege • Hard to stay up to date on everything • Do you even know all the components in use, let alone their versions? • Components with known problems can be identified & exploited with automated tools
- 90. Attack Vectors • Attacker identifies a weak component through scanning or manual analysis • Customize exploit as needed • More difficult the deeper the component is in the application
- 91. Possible Consequences • Full range of weaknesses are possible • Impact could be minimal, or... • Complete host takeover! • Data compromise!
- 92. Prevention • Don’t use components you don’t write (unrealistic) • Keep components up to date • Identify all components and versions • Monitor security of these components
- 93. Django Advice When @jacobian says there are new security releases for Django, upgrade!
- 94. 10 Unvalidated Redirects & Forwards
- 95. Redirection Abuse • Attacker tricks user into visiting a URL that redirects or forwards the request without validating the redirect location • Users prone to click because the link is to a legitimate site
- 96. Possible Consequences • Install malware • Phishing/information disclosure • Bypass access controls
- 97. External Redirection • Use a redirection URL to redirect to an external location • http://localhost:8000/redirects-and- forwards/redirects
- 98. Forwards • Manipulate a forward parameter to gain access to privileged functionality • http://localhost:8000/redirects-and- forwards/forwards
- 99. Prevention • Don’t use redirects or forwards • Don’t involve user-supplied data to build the redirect location • Ensure the supplied value is valid and authorized for the user
- 100. Django Advice • Use django.utils.http.is_safe_url to check redirect URLs • Used by django.contrib.auth internally • Consider wrapping is_safe_url if you have to allow other off-domain URLs
- 101. QWho here has vulnerable apps?
- 102. Parting Thoughts
- 103. Think Like a Bad Guy
- 104. Don’t Stop at Ten
- 105. Constant Change
- 106. Think Positive
- 107. Announcements • Lunch—moved to Exhibit Hall D • Feedback—https://goo.gl/PvHDc • Volunteer: http://bit.ly/pycon2013-volunteer http://bit.ly/pycon-volunteering-status
- 108. Links • http://www.owasp.org • https://www.owasp.org/index.php/ Category:OWASP_Top_Ten_Project • https://docs.djangoproject.com/en/dev/ topics/security/ • https://github.com/mpirnat/lets-be-bad-guys
- 109. Contact Us Mike Pirnat http://mike.pirnat.com @mpirnat David Stanek http://traceback.org @dstanek