Upgrade to Pro — share decks privately, control downloads, hide ads and more …

From OWASP Top 10 to Secure Applications

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).

4c26df6922fa4f5d4c1783b7da4e771e?s=128

Roberto Velasco

May 16, 2019
Tweet

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