OWASP Top Ten Overview. OWASP Top Ten changes from 2013 to 2017.

1. OWASP
Top Ten
2017
Michael Furman
Security Architect

2. What will we cover today?
• What is OWASP?
• OWASP Top Ten Project
• OWASP Top Ten from 2013 to 2017
• Top Ten overview

3. About Me
• 20+ years in software engineering
• 10+ years in application security
• 4+ years Lead Security Architect at Tufin
• www.linkedin.com/in/furmanmichael/
• ultimatesecpro@gmail.com
• Read my blog https://ultimatesecurity.pro/
• Follow me on twitter @ultimatesecpro
• I like to travel, read books and listen to music.

4. About Tufin
• Market Leader in Security Policy Orchestration for
firewalls and cloud
– New Tufin products integrate security into DevOps pipeline
• Established in 2005
• Used in over 2,000 enterprises, including 40 Fortune
100 companies
• We are constantly growing!
www.tufin.com/careers/

5. What is OWASP?
• OWASP - Open Web Application Security Project
• Worldwide not-for-profit organization
• Founded in 2001
• Mission is to make the software security visible.

6. OWASP Projects
• OWASP Top Ten
https://www.owasp.org/index.php/Top_10-2017_Top_10
• Opensamm - Software Assurance Maturity Model
http://www.opensamm.org/

7. OWASP Top Ten
• Most successful OWASP Project
• Ten most critical web application security flaws
• First released in 2004
• Released every 3 years
• 2007, 2010, 2013, 2017 (current)

8. Adopters of OWASP Top Ten
• Microsoft
• Part of the PCI DSS
• Vulnerability scanners
• …

9. OWASP Top Ten 2017
• A1 Injection
• A2 Broken Authentication
• A3 Sensitive Data Exposure
• A4 XML External Entities
• A5 Broken Access Control
• A6 Security Misconfiguration
• A7 Cross-Site Scripting (XSS)
• A8 Insecure Deserialization
• A9 Using Components with Known Vulnerabilities
• A10 Insufficient Logging & Monitoring

10. OWASP Top Ten 2013
• A1 Injection
• A2 Broken Authentication and Session Management
• A3 Cross-Site Scripting (XSS)
• A4 Insecure Direct Object References
• A5 Security Misconfiguration
• A6 Sensitive Data Exposure
• A7 Missing Function Level Access Control
• A8 Cross-Site Request Forgery (CSRF)
• A9 Using Components with Known Vulnerabilities
• A10 Unvalidated Redirects and Forwards

11. 2013 to 2017 - New issues
• A4 XML External Entities
• A8 Insecure Deserialization
• A10 Insufficient Logging & Monitoring

12. 2013 to 2017 - Retired or Merged Issues
• A4 - Insecure Direct Object References and A7 -
Missing Function Level Access Control merged into
A5 - Broken Access Control
• A8 Cross-Site Request Forgery (CSRF) – dropped
• A10 Unvalidated Redirects and Forwards – dropped

13. 2013 to 2017
• A1 Injection - not changed
• A2 Broken Authentication and Session Management renamed to
A2 Broken Authentication
• A3 Cross-Site Scripting (XSS) moved to A7 Cross-Site Scripting (XSS)
• A4 - Insecure Direct Object References and A7 merged into A5 - Broken
Access Control
• A5 Security Misconfiguration moved to A6 Security Misconfiguration
• A6 Sensitive Data Exposure moved to A3 Sensitive Data Exposure
• A7 - Missing Function Level Access Control and A4 merged into A5 -
Broken Access Control
• A8 Cross-Site Request Forgery (CSRF) – dropped
• A9 Using Components with Known Vulnerabilities - not changed
• A10 Unvalidated Redirects and Forwards – dropped

14. Why it changed?
• Over the last few years, the fundamental technology
and architecture of applications has changed
significantly:
• Microservices
• Single page applications

15. What can I do?

16. A1 Injection
• A user input is concatenated with executable code
• SQL injection
• OS Command Injection
• HQL injection

17. A1 Injection
• Example:
String query = "SELECT * FROM accounts
WHERE custID=‘” + request.getParameter("id") + "'";

18. A1 - How to Prevent it
• Do not pass user input directly to executable
statements
• Prepared Statements
• Parameterized Queries
• Hibernate

19. A2 Broken Authentication
• Session IDs aren’t rotated after successful login
• Allow brute force or other automated attacks
• Use default, weak, or well-known passwords

20. A2 - How to Prevent it
• Rotate Session IDs after successful login
• Implement brute force protection
• Implement password complexity

21. A3 Sensitive Data Exposure
• Sensitive data is transmitted or stored in clear text
• Old or weak cryptographic algorithms are used

22. A3 - How to Prevent it
• Encrypt all sensitive data both at rest and in transit
• Use up-to-date and strong standard algorithms,
protocols, and keys

23. A4 XML External Entities
• Attackers can exploit vulnerable XML processors if
they can upload XML or include hostile content in an
XML document
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE foo [
<!ELEMENT foo ANY >
<!ENTITY xxe SYSTEM "file:///etc/passwd" >]>
<foo>&xxe;</foo>

24. A4 - How to Prevent it
• Disable XML external entity and DTD processing in all
XML parsers in the application, as per the OWASP
Cheat Sheet 'XXE Prevention’.
https://www.owasp.org/index.php/XML_External_Entity_(XXE)_Preventio
n_Cheat_Sheet
• For additional details see my XXE presentation:
https://ultimatesecurity.pro/post/xxe-presentation/

25. A5 Broken Access Control
• AKA Privilege Escalation or Elevation of privilege
• A regular user accesses a resource with an admin
permission

26. A5 - How to Prevent it
• Implement access control mechanisms

27. A6 Security Misconfiguration
• Unnecessary features are enabled or installed
• Unnecessary ports
• Services
• Default accounts
• Default passwords

28. A6 - How to Prevent it
• Close unnecessary ports
• Disable unnecessary services
• Remove default accounts
• Change default passwords

29. A7 Cross-Site Scripting (XSS)
• Attackers can execute scripts in a victim’s browser

30. A7 - How to Prevent it
• Input validation for all user input
• White list patterns. E.g. pattern for IPv6 or IPv4.
• Encode output

31. A8 Insecure Deserialization
• Serialization is the process of translating data
structures or object state into a format that can be
stored or transmitted and reconstructed later
(deserialization)
• Insecure Deserialization - an attacker changes the
object between serialization and deserialization

32. A8 Insecure Deserialization
• Example:
• A PHP forum uses PHP object serialization to save a
"super" cookie, containing the user's user ID, role,
password hash, and other state information:
• An attacker changes the serialized object to gain admin
privileges:
a:4:{i:0;i:132;i:1;s:7:"Mallory";i:2;s:4:"user"; i:3;s:32:
"b6a8b3bea87fe0e05022f8f3c88bc960";}
a:4:{i:0;i:1;i:1;s:5:"Alice";i:2;s:5:"admin";
i:3;s:32:"b6a8b3bea87fe0e05022f8f3c88bc960";}

33. A8 Insecure Deserialization
• Mark Reinhold, Oracle
Chief Architect of Java platform group
– Removing serialization is a long-term goal and is part of
project Amber
– Serialization was a “horrible mistake” made in 1997
– At least a third—maybe even half—of Java vulnerabilities
have involved serialization

34. A8 - How to Prevent it
• Don't accept serialized objects from untrusted
sources

35. A9 Using Components with
Known Vulnerabilities
• Software is vulnerable, unsupported, or out of date.
• Is any of your software out of date?
• OS
• Web/App Server
• Database

36. A9 - How to Prevent it
• Update software

37. A10 Insufficient Logging & Monitoring
• Insufficient logging
• Logins
• Failed logins
• High-value transactions

38. A10 - How to Prevent it
• Log important events with sufficient user context
– Username
– Client IP
– Time

39. Take aways
• You understand what OWASP does
• You understand the OWASP Top Ten

40. Thank you!
• Contact me
– www.linkedin.com/in/furmanmichael/
– ultimatesecpro@gmail.com
– https://ultimatesecurity.pro/
– @ultimatesecpro