Preventive Approach for Web Applications Security Testing OWASP 10/30/2009. The OWASP Foundation

(1)

Permission is granted to copy, distribute and/or modify this document under the terms of the OWASP License.

OWASP

Preventive Approach for Web Applications Security Testing

Luiz Otávio Duarte

Ferrucio de Franco Rosa Walcir M. Cardoso Jr.

Renato Archer Information Technology Center Brazilian Ministry of Science and Technology +55-19-37466241

10/30/2009

(2)

Agenda

Introduction Key Points

Techniques for software testing Software Quality

Web application security testing approach Practical demonstration

Conclusions

(3)

Agenda

Conclusions

(4)

Motivation

The concern with security in developing projects for the Web is essential for the protection of information and business continuity.

In recent years the Web has grown significantly

and complexity of applications and services even

more. New technologies, tools and architectures

are adopted without properly concern for

security.

(5)

Statistics data

@Risk/SANS Statistics

• SysAdmin, Audit, Network, Security Institute

maintains @RISK a weekly vulnerability consensus digest.

NVD/NIST Statistics

• National Vulnerability Database - repository of vulnerability resources (USA).

OSVDB Statistics

Top 10 vulnerabilities by OWASP

(6)

Statistics data

@Risk/SANS Statistics NVD/NIST Statistics OSVDB Statistics

• Open Source Vulnerability Database, that aims to provide accurate, detailed, current, and unbiased technical information on security vulnerabilities.

Top 10 vulnerabilities by OWASP

• Open Web Application Security Project, provides the top 10 most critical web application vulnerabilities.

(7)

@Risk/SANS

0 200 400 600 800 1000 1200 1400

Web Application Cross Plataform Windows Others OS Others

@Risk Vulnerabilites Distribution 01/01/2009 – 08/20/2009

(8)

Statistics data – OSVDB

0 500 1000 1500 2000 2500 3000 3500 4000 4500

All; 4497

Web Related;

2880

All Others;

1617

OSVDB Vulnerabilities Distribution

01/01/2009 - 08/23/2009 - All Categories

(9)

NVD/NIST

740; 18%

544; 14%

2775; 68%

NVD/NIST

01/01/2009 - 09/01/2009

SQL Injection: Cross Site Scripting: Others:

(10)

@Risk/SANS

0 5 10 15 20 25 30 35 40

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34

@Risk - Web Application Related Vulnerabilities 01/01/2009 – 08/20/2009

Web Application - Cross Site Scripting Web Application - SQL Injection Web Application - Others

(11)

OWASP- Top 10 Web app. vulns. for 2007

A1 - Cross Site Scripting (XSS) A2 - Injection Flaws

A3 - Malicious File Execution

A4 - Insecure Direct Object Reference A5 - Cross Site Request Forgery (CSRF)

A6 - Information Leakage and Improper Error Handling A7 - Broken Authentication and Session Management A8 - Insecure Cryptographic Storage

A9 - Insecure Communications

(12)

Aspects of the problem

Developers/Architects are making the same kind of mistakes.

Many of software development life cycles (SDLC) do not provide an effectively approach for security aspects.

How to spot web vulnerabilities and the correct then are well known, but repairing could be expensive.

Applications are not properly tested in terms of security.

Lack of a de facto standard or approach to conduct a good software security testing for web applications.

Know-how on penetration test is far from a good software security testing.

(13)

Goal

Software

Testing Software

Quality

Process

Documentation Real Test Cases

(14)

Goal

Software

Testing Software

Quality

Process

(15)

Initial Concepts

Mistake Defect Error Fail

• A human action that can introduce some kind of defect in the software.

Mistake

• It is a deficiency (step, process or incorrect

definition) resident in the software. The defect when executed can cause an error.

Defect, Fault

(16)

Initial Concepts

Mistake Defect Error Fail

• It is caused by the execution of a defect and is characterized by an unexpected or inconsistent program state. It is the incorrect value in a given state of the program.

Error

• It is an observable event that the software infringed its specification. It is the noticed spread of an error.

Fail

(17)

Initial Concepts

• A weakness in a computing system which can be exploited and harmed by one or more threats.

Making the system do what it was not designed to do.

Vulnerability

• Is an application coded in a browser-supported

language that is acessed via a web browser over a network such as Internet. Some times we will use webapp as a synonymous of Web Application.

Web Application (In this presentation)

(18)

Agenda

Conclusions

(19)

Web Application Vulnerabilities Life-Cicle

Web Application Defect Correction Defect detection (Reactive Fashion)

By Software Security Testing Ocasional Not spoted

Software Deploy with Several Defects (In the Wild)

Affects the quality Affects the security

Web Application Development

Bad design/development Poor or not tested

(20)

Web Application Vulnerabilities Life-Cicle

Web Application Defect Correction Defect detection (Reactive Fashion)

By Software Security Testing Ocasional Not spoted

Software Deploy with Several Defects (In Wild)

Affect the quality Affect the security

Web Application Development

Bad design/development Poor or not tested

Preventive Approach, before software deploy

(21)

Preventive Approaches – Line Fronts

• Secure Design

• Secure Coding

• Education

Secure Development

• Structural

• Functional

Software Security Testing

(22)

Preventive Approaches – Line Fronts

• Secure Design

• Secure Coding

• Education

Secure Development

• Structural

• Functional

Software Security Testing

(23)

Agenda

Conclusions

(24)

Software Testing

Software testing is the process of running the software in a controlled way to

evaluate whether it behaves as specified.

The main goal of software testing is to

detect software failures so defects

may be uncovered and corrected.

(25)

Software Testing - Aspects

A fundamental software testing problem is that testing all possible test cases is not feasible. (combinatorial

explosion)

The solution is the definition of a good test criterion, that selects a reduced set of test cases that have high probability to find defects.

• Test criteria;

• Test case selection criteria;

• Adequacy criteria;

• …

There are several criteria types and objectives:

(26)

Software Testing

• Yes.

• We can not conclude that the software is free from defects, even after running several test cases.

• The cost of testing to ensure that software has no defects can overcome the project budget.

We test the software only partially?

• The targets must be critical points, those most vulnerable, more susceptible to defects, which offer greater risk to the business.

We should plan what to test:

(27)

Technical aspects of software testing

• Functionality Testing

• Interface Testing

• Stress Testing

• Usability Testing

• Security Testing

• ...

What to test – Types of testing

How to test – Test Criteria When to test - SDLC

(28)

Technical aspects of software testing

What to test – Types of testing

• Functional Testing

• Equivalence Partition

• Boundary Value Analysis

• ...

• Structural Testing

• Branch Testing

• Condition Testing

• Function Testing

• ...

How to test – Test Criteria

When to test - SDLC

(29)

Technical aspects of software testing

What to test – Types of testing How to test – Test Criteria

• Unit Testing

• Integration/Module Testing

• System Testing / Validation Testing

• Acceptance Testing

• Regression Testing When to test - SDLC

(30)

Software Test Documentation – IEEE STD 829-2008

Defines several documents to make the testing more reliable.

• Test Plan;

• Test Design Specification;

• Test Case Specification;

• Test Procedure Specification;

• Test Item Transmittal Report;

• Test Log;

• Test Incident Report;

• Test Summary Report.

(31)

Software Test Documentation – IEEE STD 829-2008

Defines several documents to make the testing more reliable.

• Test Plan;

• Test Design Specification;

• Test Case Specification;

• Test Procedure Specification;

• Test Item Transmittal Report;

• Test Log;

• Test Incident Report;

• Test Summary Report.

Those documents can introduce unnecessary overhead to testing.

We can use a different and more effective approach to deal with documentation.

(32)

Agenda

Conclusions

(33)

Software Quality

Is the degree in which the software product meets

stated and implied needs when used under specified conditions.

• Software product Quality Requirements and Evaluation (SQuaRE) – Quality models for software product quality and system quality in use.

ISO/IEC 25010 Draft

• Information technology - Software product evaluation - Part 1:

General overview.

• Software product evaluation - Part 5: Process for evaluators.

ISO/IEC 14598

(34)

ISO/IEC 25010 Draft

Software product quality model

Sec urit y Func tional Suitabil ity R eliabi lity Perf orm ance Ef ficienc y Oper abil ity Com patibil ity Maintai nabil ity Port abil ity

(35)

Security

Confidentiali ty In tegri ty Non -repudiation Ac coun tabili ty Auth entici ty

(36)

ISO/IEC 14598-1 (ISO/IEC 14598-5)

Provides basis for a systematic evaluation process and general software quality.

• Repeatability / Reproducibility / Impartiality / Objectivity (RRIO).

Establishes evaluation process, such as:

Estabilish evaluation requirements

Specify the

evaluation Design the

evaluation Execute the evaluation

Conclusion of the evaluation

(37)

Agenda

Conclusions

(38)

Proposed Approach

Software

Testing Software

Quality

Process

(39)

Proposed Approach

• Will define the web application security testing criteria;

• Will define the test case selection criteria;

• Will define the adequacy criteria.

Software Testing - Security

• The evaluation phases are extends to software security testing, defining The process:

• Establish security testing requirements;

• Especify the security testing;

• Design the security testing;

• Execute the security testing;

• Conclusion of the security testing.

• Based on ISO/IEC 14598-5:

Software Quality – Security

(40)

Proposed Approach

• When not based on IEEE 829-2008, is based on the documentation of each ISO/IEC 14598-5 evaluation phase.

Process Documentation – Security

• The easiest part for security guys. We

have several test cases to identify different types of vulnerabilities.

Real Test Cases – Security

(41)

Web Application Security Testing Approach

SDLC 1

Aims to be SDLC and STM independent.

SDLC 3 SDLC 2

STM 1

STM 2 STM N

SDLC N

(42)

Web Application Security Testing Approach

Security Test Case Selection Criteria

Web Application Security Test Cases / Tools Web Application Security Testing Methodologies

Web Application Security Test Criteria

Adequacy Criteria

. . .

Documentation Process

(43)

AdCrit

. . . . . .

DocumentaProcess

A web application security testing criterion

The webapp security testing criterion will define what is the prioritization of security control or threat that must be exercised in the testing, based on security requirements. Furthermore will establish security metrics for testing.

What security testing criterion can we use?

Web Application Risk Analisys?

Web Application Threat Modeling?

Web Application Security Use Cases?

...

(44)

AdCrit

. . . . . .

DocumentaProcess

A web application security testing criterion

Almost all security test case will cause an abnormal behavior in the structure under testing. The oracle must be able to determine if this abnormal behavior is related or not with some kind of security flaw.

If the system's behavior is "normal“ then, either

the flaw was not spotted or does not exists.

(45)

A web application security testing criterion

Is any of those webapp security testing criteria a valid criterion?

All of those criteria, in addition to an adequate test case set, have the ability to identify security flaws presence. But we have not yet been able to prove that all flaws (defined by the criterion) can be exercised.

Once established the webapp security testing

criterion, we must determine the set of case

tests. This is the test case select criterion.

(46)

A security test case selection criterion

We already know what kind of security control or threat to prioritize, now we need to determine a criterion to select good test cases.

How to define the test data selection criterion?

How to select properly “real test cases” and automated test case generation tools, so those threats and security controls can be well exercised?

AdCrit

. . . . . .

DocumentaProcess

(47)

A security test case selection criterion

We can:

Derive vulnerabilities from threat;

Derive attack trees from security use cases or risk analysis, defining vulnerabilities;

The aim is to reduce the testing efforts to the identified vulnerabilities that could be exploited by threats or could be present on security controls.

AdCrit

. . . . . .

DocumentaProcess

(48)

The Adequacy Criterion

The adequacy criterion is used to determine whether a “program” has been tested “enough”.

It is based on the evaluation of the security test case set: the set is adequate if and only if it satisfies each sequence defined by the webapp security testing criterion.

In other words: is the confrontation of test case set and webapp security test criterion requirements.

AdCrit

. . . . . .

DocumentaProcess

AdCrit

(49)

The Adequacy Criterion

It is a hard work to state the adequacy of a selected set of security test case. But we can estimate the coverage test:

Were all attack surface tested?

Were all defined threat tested?

Were all defined security controls tested?

Were all defined vulnerabilities spottable?

Were all attach tree tested?

…

AdCrit

. . . . . .

DocumentaProcess

AdCrit

(50)

Web Application Security Test Case / Tools

We select the security test case and tools based on the security test case criterion, because on the security field we have many ways/techniques and tools that helps the process to spot a vulnerability.

What we need to do is to generate test cases from those huge quantity of ways/techniques and tools.

Remember the testing must be RRIO.

We can use pentest techniques, but in a structured way.

AdCrit

. . . . . .

DocumentaProcess

Web Application Security Test Cases / Tools

(51)

Web Application Security Test Case / Tools

So now it is time to use the security skills to generate test cases. Who can save us?

OSSTMM;

OWASP;

Pentesting techniques;

Exploitation techniques;

Security testing tools.

AdCrit

. . . . . .

DocumentaProcess

Web Application Security Test Cases / Tools

(52)

Web Application Security Test Case / Tools

As the used approach is broad, there might have methodologies that allow the use of the

suggested approach.

 As our goal is a preventive approach, the methodology must be defined during the development of the software product. That is, during the SDLC.

 Let's take the Vee model as an example.

AdCrit

. . . . . .

DocumentaProcess

Web Application Security Testing Methodologies

(53)

Software Testing – Vee model (Generic)

(54)

Requeriment Analysis

System Design

Architecture Specification

Module Specification

Coding

(55)

System Design

Coding Acceptance Test Design

System Test Design Integration Test Design Test DesignUnit

(56)

System Design

Coding Acceptance Test Design

System Test Design Integration Test Design Test DesignUnit

(57)

System Design

Coding

Acceptance Testing

System Testing

Integration Testing

TestingUnit Acceptance

Test Design System Test Design Integration Test Design Test DesignUnit

(58)

System Design

Coding

Acceptance Testing

System Testing

Integration Testing

(59)

System Design

Coding

Acceptance Testing

System Testing

Integration Testing

(60)

System Design

Coding

Acceptance Testing

System Testing

Integration Testing

(61)

Documentation Process

The documentation process is the base of RRIO.

It is important to use a well-established process of testing so the documentation process is naturally achieved.

Remember ISO/IEC 14598-5? We extended it to security testing. So the process of testing follows this ISO and so does documentation.

AdCrit

. . . . . .

DocumentaProcess DocumentaProcess

(62)

Testing phases, based on ISO/IEC 14598-5

• Establish the purpose of the test - SECURITY

• Identify types of product(s) to be evaluated - WEBAPPS

• Specify quality model – WebApp secure testing criterion

Estabilish testing requirements

• Select Metrics

• Establish rating levels for metrics

• Establish criteria for assessment

Specify the testing

• Produce evaluation plan

Design the testing

• Take measures

• Compare with criteria – did the adequacy criterion Worked?

• Assess results

Execute the testing

• Generate a reviewed security testing report

Conclusion of the evaluation

(63)

Testing phases, based on ISO/IEC 14598-5

 Depending on what is being tested (acceptance, system, integration, unit) we must use the test phases in different ways.

For example, the test criteria may be different for each phase;

The test case selection criterion for unit testing uses

knowledge of the webapps source-code, code review and inspection tools might be used as well as patterns of input validation.

The criterion for selection of test cases for integration testing can involve manipulation of input and

communication between modules.

That is, for each type of test this set of phases

should be re-drawn, re-structured, re-thought.

(64)

Testing phases, based on ISO/IEC 14598-5

The steps should be repeated until the program reaches the desired level of security. (Maturity models?)

 Remember:

New risk analysis should be made;

New types of threats;

New security use cases;

New attacks trees;

New tests case.

AdCrit

. . . . . .

DocumentaProcess Documentation

(65)

Agenda

Conclusions

(66)

Agenda

Conclusions

(67)