Slide 1

Slide 1 text

Roberto Velasco @hdivroberto From OWASP Top 10 to Secure Applications

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

About OWASP • OWASP = Open Web Application Security Project •Non profit organization that offers free documentation and tools

Slide 4

Slide 4 text

Some OWASP Projects

Slide 5

Slide 5 text

OWASP Top 10 2013 à OWASP Top 10 2017

Slide 6

Slide 6 text

OWASP Top 10 2017 – OWASP A1 – Injection •Allows the injection of commands (executable code) •Examples: • SQL Injection • CMD Injection • LDAP Injection

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

•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

Slide 9

Slide 9 text

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)

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

OWASP Proactive Controls

Slide 13

Slide 13 text

Proactive Controls – C3 – Secure DB Access

Slide 14

Slide 14 text

Proactive Controls – C7 – Enforce Access Control

Slide 15

Slide 15 text

Proactive Controls – Summary •It is not complete •It can be used as an awareness tool but is not enough

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

ASVS – V5 – Validation, Sanitization, Encoding

Slide 19

Slide 19 text

ASVS – V5 – Validation, Sanitization, Encoding

Slide 20

Slide 20 text

ASVS – V4.2 – Operation Access Control

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

OWASP Benchmark •OWASP project that measures the quality of detection solutions:

Slide 23

Slide 23 text

How do we Develop Secure Applications?

Slide 24

Slide 24 text

Automation and Design are the Key

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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.

Slide 27

Slide 27 text

Software Security Definition

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

DEMO DETECTION

Slide 31

Slide 31 text

• 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

Slide 32

Slide 32 text

• 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¶m=data https:/www.bank.com/orderDetails/20500 Protection Tools – Example: Integrity Checks 2 3

Slide 33

Slide 33 text

1 2 Validation Filter Libraries Extension 2 Protection Tools – Example: Integrity Checks 2 3

Slide 34

Slide 34 text

• Hdiv Community for Spring MVC • Officially integrated within Spring since 2012 Protection Tools – Spring Integration 2 3

Slide 35

Slide 35 text

DEMO PROTECTION

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

Roberto Velasco Thanks! Q&A @hdivroberto