From OWASP Top 10 to Secure Applications

Many people focus their attention solving OWASP top 10 risks, but unfortunately they only represent a part of existing application security issues. In consequence it’s necessary to have a global knowledge of existing risks going beyond the OWASP top ten. This talk review the recently published OWASP top 10 2017 and other OWASP standards such as OWASP Application Security Verification standard (ASVS) that completes the partial view of the OWASP top 10 offering a more advanced vision of the security providing a lis of requirements for secure development.

During the talk we will show practical examples of how to address existing risk, using manual or programmatic solutions within Spring Applications, as well as security providers solutions such as Application Security Testing (AST), Web Application Firewalls (WAF) and Runtime Application Self protection (RASP).

Transcript

1. Roberto Velasco @hdivroberto From OWASP Top 10 to Secure Applications
2. About me Roberto Velasco Working as Java Software Architect since 2004 Involved in Software Security since 2001 Hdiv open-source project founder Founder & CEO at Hdiv Security
3. About OWASP • OWASP = Open Web Application Security Project •Non profit organization that offers free documentation and tools
4. Some OWASP Projects
5. OWASP Top 10 2013 à OWASP Top 10 2017
6. OWASP Top 10 2017 – OWASP A1 – Injection •Allows the injection of commands (executable code) •Examples: • SQL Injection • CMD Injection • LDAP Injection
7. OWASP Top 10 2017 – A1 – SQL Injection •Bad example: String data= request.getParameter(“orderId”); String sql= “select * from order where orderId=” + data; sqlStatement.executeQuery(sql); •Good example: String data = request.getParameter(“orderId”); PreparedStament pstmt= “select * from order where orderId=?”; pstmt.setString(1,data);
8. •Bad example: String orderId= request.getParameter(“orderId”); hql = session.createQuery(“select * from order where orderId=”+ orderId); •Good example: String orderId= request.getParameter(“orderId”); hql = session.createQuery(“select * from order where orderId=:orderid”); hql.setParameter(“orderId”,orderId); OWASP Top 10 2017 – A1 – HQL Injection
9. OWASP Top 10 2017 – A5 - Broken Access Control •Currently A5 integrates previous: • OWASP 2013 – Insecure Direct Object Reference (A4) • OWASP 2013 – Missing Function Access Level (A7) •Basic access control is usually well implemented, but not low level access control (domain level or database row level)
10. OWASP Top 10 2017 – Broken Access Control •Bad Example: https://www.bank.com/orderDetails/20500 select * from order where orderId=20500 •Good Example: https://www.bank.com/orderDetails/20500 select * from order where orderId=20500 and owner=authenticatedUser
11. OWASP Top 10 – Summary •It is not complete •The top ten is created mainly using security vendors information (also community) •Detectable risks by tools are prevalent in the top 10
12. OWASP Proactive Controls
13. Proactive Controls – C3 – Secure DB Access
14. Proactive Controls – C7 – Enforce Access Control
15. Proactive Controls – Summary •It is not complete •It can be used as an awareness tool but is not enough
16. OWASP Application Security Verification Standard (ASVS) V1 - Architecture, Design and Threat Modeling V8 - Data Protection V2 - Authentication V9 - Communication V3 - Session management V10 - Malicious Code V4 - Access Controls V11 - Business Logic V5 - Validations, Sanitization and Encoding V12 - File and Resources V6 - Stored Cryptography V13 - API and Web Service V7 - Error Handling and Logging V14 - Configuration
17. Level Target applications Testing methodology Detection Tools Level 1 Entry Level Black box is enough DAST, IAST Level 2 Applications that contains sensitive data Black box + White Box SAST, IAST Level 3 Most Critical Applications (high value transactions, medical data, etc) Black box + White Box SAST, IAST OWASP ASVS – Verification Levels
18. ASVS – V5 – Validation, Sanitization, Encoding
19. ASVS – V5 – Validation, Sanitization, Encoding
20. ASVS – V4.2 – Operation Access Control
21. OWASP ASVS – Summary •Unlike OWASP Top 10 or Proactive controls, it is complete •Start gradually: Level 1, Level 2 and finally Level 3 •Take it as reference and fork if necessary to cover custom needs
22. OWASP Benchmark •OWASP project that measures the quality of detection solutions:
23. How do we Develop Secure Applications?
24. Automation and Design are the Key
25. ASVS - Security Tools references • A significant part of ASVS can be automated using Application Security Testing (AST) tools: ASVS 4.0, page 10 “We strongly encourage the use of security tools, but within the development process itself, such as DAST and SAST” • But some of the issues can not be: ASVS 4.0, page 10 “Business logic flaws and access control testing is only possible using human assistance.”
26. Software Security Issues • SQL Injection • Cross-Site Scripting (XSS) • Directory Traversal • Weak Crypto Algorithm • Java Object Deserialization • etc. • Access Control • Binding attacks • Race condition • Step N of workflow can be skipped • etc.
27. Software Security Definition
28. How to Develop Secure Applications: DevSecOps Use OWASP ASVS as reference and complete with custom needs Use Detection tools (DAST, SAST, IAST) Architecture Review + Integrate Protection solutions in the architecture Pen-Testing 2 2 2 3 2 4 2 1
29. Detection Tools • Use within the whole SDLC (Development, QA, Production) • Use Accurate solutions (100% OWASP Benchmark coverage) • Analyze third party software (vulnerable dependencies) 2 2
30. DEMO DETECTION
31. • The issues that can not be detected with tools (Access control + Business Logic) are protected mainly through custom input validation • It can be significantly automated using contract enforcement approaches: what you see is what you get • Implemented thanks to the integration into technologies (web frameworks, APIs frameworks and a validation filter (RASP approach) Protection Tools 2 3
32. • Traditional manual access control: https:/www.bank.com/orderDetails/20500 select * from order where orderID=20500 and owner=authenticatedUser • If we verify the integrity of the link we avoid the access control issue and we actually get more security: https:/www.bank.com/orderDetails/20501 https:/www.bank.com/orderDetails/20500&param=data https:/www.bank.com/orderDetails/20500 Protection Tools – Example: Integrity Checks 2 3
33. 1 2 Validation Filter Libraries Extension 2 Protection Tools – Example: Integrity Checks 2 3
34. • Hdiv Community for Spring MVC • Officially integrated within Spring since 2012 Protection Tools – Spring Integration 2 3
35. DEMO PROTECTION
36. Summary • Use OWASP ASVS as reference, OWASP Top 10 is not enough • Automation (Tools) and Architecture Review are mandatory: security that depends only on people does not work • Finish your security process with pen-testing, instead of starting with it
37. Roberto Velasco Thanks! Q&A @hdivroberto