This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org

Difference between revisions of "Testing: Introduction and objectives"

From OWASP
Jump to: navigation, search
m (Change Data Validation to Input Validation)
 
(38 intermediate revisions by 10 users not shown)
Line 1: Line 1:
[[http://www.owasp.org/index.php/Web_Application_Penetration_Testing_AoC Up]]<br>
+
{{Template:OWASP Testing Guide v4}}
{{Template:OWASP Testing Guide v2}}
 
  
This Chapter describes the OWASP Web Application Penetration testing methology and explains how to test each vulnerabilities.
+
This section describes the OWASP web application security testing methodology and explains how to test for evidence of vulnerabilities within the application due to deficiencies with identified security controls.
  
'''What is Web Application Penetration Testing?'''<br>
+
'''What is Web Application Security Testing?'''<br>
A penetration test is a method of evaluating the security of a computer system or network by simulating an attack. A Web Application Penetration Testing focalize only on evaluating the security of a web application.<br>
+
A security test is a method of evaluating the security of a computer system or network by methodically validating and verifying the effectiveness of application security controls. A web application security test focuses only on evaluating the security of a web application. The process involves an active analysis of the application for any weaknesses, technical flaws, or vulnerabilities. Any security issues that are found will be presented to the system owner, together with an assessment of the impact, a proposal for mitigation or a technical solution.
The process involves an active analysis of the application for any weaknesses, technical flaws or vulnerabilities. Any security issues that are found will be presented to the system owner together with an assessment of their impact and often with a proposal for mitigation or a technical solution.
 
  
'''What is a vulnerability?'''<br>
 
  
Given an application that own a set of assets (resources of value such as the data in a database or on the file system), a vulnerability is a weakness on a asset that makes a threat possible.
+
'''What is a Vulnerability?'''<br>
So a threat is a potential occurrence that may harm an asset exploiting
+
A vulnerability is a flaw or weakness in a system's design, implementation, operation or management that could be exploited to compromise the system's security objectives.
Vulnerability.
+
 
A test is an action that tends to show a vulnerability in the application.
+
 
 +
'''What is a Threat?'''<br>
 +
A threat is anything (a malicious external attacker, an internal user, a system instability, etc) that may harm the assets owned by an application (resources of value, such as the data in a database or in the file system) by exploiting a vulnerability.  
 +
 
 +
 
 +
'''What is a Test?'''<br>
 +
A test is an action to demonstrate that an application meets the security requirements of its stakeholders.
 +
 
 +
 
 +
'''The Approach in Writing this Guide'''
 +
 
 +
The OWASP approach is open and collaborative:
 +
* Open: every security expert can participate with his or her experience in the project. Everything is free.
 +
* Collaborative: brainstorming is performed before the articles are written so the team can share ideas and develop a collective vision of the project. That means rough consensus, a wider audience and increased participation.<br>
  
'''Our approach in writing this guide'''
 
  
The OWASP approach is Open and Collaborative:
 
* Open: Every security expert can partecipate with his experience at the project. Everything is free
 
* Collaborative: we usually make a brainstorming before write down the articles. So we can share our ideas and develop a collective vision of the project. That means rough consensus, wider audience and participation.<br>
 
 
This approach tends to create a defined Testing Methodology that will be:
 
This approach tends to create a defined Testing Methodology that will be:
 
* Consistent
 
* Consistent
 
* Reproducible
 
* Reproducible
 +
* Rigorous
 
* Under quality control<br>
 
* Under quality control<br>
The problems that we want to be addressed are:
 
* Document all
 
* Test all
 
  
'''What is the OWASP testing methology?'''<br>
 
  
Penetration testing will never be an exact science where a complete list of all possible issues that should be tested can be defined. Indeed, penetration testing is only an appropriate technique for testing the security of web applications under certain circumstances.  
+
The problems to be addressed are fully documented and tested. It is important to use a method to test all known vulnerabilities and document all the security test activities.<br>
Our goal is to collect all the possible testing techniques, explain it and mantain it updated.<br>
+
 
The OWASP Web Application Penetration Testing is based on black box approach. The tester know nothing or a few informations about the application to test.
+
 
The testing model is like this:
+
'''What is the OWASP testing methodology?'''<br>
* Tester: who make the testing activities
+
 
* Tools and methodology: the core of this Testing Guide project
+
Security testing will never be an exact science where a complete list of all possible issues that should be tested can be defined. Indeed, security testing is only an appropriate technique for testing the security of web applications under certain circumstances. The goal of this project is to collect all the possible testing techniques, explain these techniques, and keep the guide updated. The OWASP Web Application Security Testing method is based on the black box approach. The tester knows nothing or has very little information about the application to be tested.
* Application: the black box to test
+
 
The test is divided in 2 phases:
 
* Passive mode: in the passive mode the tester try to understand the application's logic, play with the application, he uses tool for information gathering and HTTP proxy to observ all the HTTP requests and responses. At the end of this phase the tester will know all the access point (gate) of the application (e.g. Header HTTP, parameters, cookies). For example the tester could find the following:
 
<pre>
 
https://www.example.com/login/Autentic_Form.html
 
</pre>
 
Indicates an authentication form in which the application request a username and a password. These paramaters represents two access points (gates) to the application.
 
<pre>
 
http://www.example.com/Appx.jsp?a=1&b=1
 
</pre>
 
In this case the application shows two gates (parameters a and b).
 
All the gates finded in this phase represent a point of testing. A spreadsheet with the directory tree of the application and all tha access points will be useful for the second phase.<br> <br>
 
* Active mode: in this phase the tester begin to test using the methodology described in the follow paragraphs.
 
  
After done application discovery
+
The testing model consists of:
Play with application: look at the HTTP Request/Response
+
* Tester: Who performs the testing activities
Understand the access point of the application
+
* Tools and methodology: The core of this Testing Guide project
 +
* Application: The black box to test
  
Access Gate:
 
Show the model
 
  
In general (web app no AJAX, WS)
+
The test is divided into 2 phases:
 +
* Phase 1 Passive mode:
 +
In the passive mode the tester tries to understand the application's logic and plays with the application. Tools can be used for information gathering. For example, an HTTP proxy can be used to observe all the HTTP requests and responses. At the end of this phase, the tester should understand all the access points (''gates'') of the application (e.g., HTTP headers, parameters, and cookies). The Information Gathering section explains how to perform a passive mode test.
  
Header HTTP
+
For example the tester could find the following:
parameters: authentication parameters
+
<pre>
Cookie
+
https://www.example.com/login/Authentic_Form.html
 +
</pre>
  
From this manipulation
+
This may indicate an authentication form where the application requests a username and a password. <br>
can derived the following testing
 
  
We have categorized:
 
- Authentication
 
.....
 
  
 +
The following parameters represent two access points (gates) to the application:
 +
<pre>
 +
http://www.example.com/Appx.jsp?a=1&b=1
 +
</pre>
  
We have splitted the test in 8 sub-categories:
 
*Information Gathering
 
*Business logic testing
 
*Authentication Testing
 
*Session Management Testing
 
*Data Validation Testing
 
*Denial of Service Testing
 
*Web Services Testing
 
*AJAX Testing
 
  
 +
In this case, the application shows two gates (parameters a and b).
 +
All the gates found in this phase represent a point of testing. A spreadsheet with the directory tree of the application and all the access points would be useful for the second phase.
  
Here is the list of test that we will explain in the next paragraphs:
 
  
{| border=1
+
* Phase 2 Active mode:
|| '''Category''' || '''Ref Number''' || '''Name '''
+
In this phase the tester begins to test using the methodology described in the follow sections.
|-
 
|| Information Gathering ||  || Application Discovery
 
|-
 
||  ||  || Spidering and googling
 
|-
 
||  ||  || Analisys of error code
 
|-
 
||  ||  || SSL/TLS Testing
 
|-
 
||  ||  || DB Listener Testing
 
|-
 
||  ||  || File extensions handling
 
|-
 
||  ||  || Old, backup and unreferenced files
 
|-
 
||Business logic testing  ||  ||
 
|-
 
|| Authentication Testing ||  || Default or guessable account
 
|-
 
||  ||  || Brute Force
 
|-
 
||  ||  || Bypassing authentication schema
 
|-
 
||  ||  || Directory traversal/file include
 
|-
 
||  ||  || Vulnerable remember password and pwd reset
 
|-
 
||  ||  || Logout and Browser Cache Management Testing
 
|-
 
|| Session Management Testing ||  || Session Management Schema 
 
|-
 
||  ||  || Session Token Manipulation
 
|-
 
||  ||  || Exposed Session Variables
 
|-
 
||  ||  || Session Riding
 
|-
 
||  ||  || HTTP Exploit
 
|-
 
|| Data Validation Testing ||  || Cross site scripting
 
|-
 
||  ||  || HTTP Methods and XST
 
|-
 
||  ||  || SQL Injection
 
|-
 
||  ||  || Stored procedure injection
 
|-
 
||  ||  || ORM Injection
 
|-
 
||  ||  || LDAP Injection
 
|-
 
||  ||  || XML Injection
 
|-
 
||  ||  || SSI Injection
 
|-
 
||  ||  || XPath Injection
 
|-
 
||  ||  || IMAP/SMTP Injection
 
|-
 
||  ||  || Code Injection
 
|-
 
||  ||  || OS Commanding
 
|-
 
||  ||  || Buffer overflow
 
|-
 
||  ||  || Incubated vulnerability
 
|-
 
|| Denial of Service Testing ||  || Locking Customer Accounts
 
|-
 
||  ||  || User Specified Object Allocation
 
|-
 
||  ||  || User Input as a Loop Counter
 
|-
 
||  ||  || Writing User Provided Data to Disk
 
|-
 
||  ||  || Failure to Release Resources
 
|-
 
||  ||  || Storing too Much Data in Session
 
|-
 
|| Web Services Testing  ||  || XML Structural Testing
 
|-
 
||  ||  || XML content-level Testing
 
|-
 
||  ||  || HTTP GET parameters/REST Testing
 
|-
 
||  ||  || Naughty SOAP attachments
 
|-
 
||  ||  || Replay Testing 
 
|-
 
|| AJAX Testing ||  || AJAX Vulnerabilities 
 
|-
 
|}
 
  
  
{{Category:OWASP Testing Project AoC}}
+
The set of active tests have been split into 11 sub-categories for a total of 91 controls:
[[OWASP Testing Guide v2 Table of Contents]]
+
* Information Gathering
 +
* Configuration and Deployment Management Testing
 +
* Identity Management Testing
 +
* Authentication Testing
 +
* Authorization Testing
 +
* Session Management Testing
 +
* Input Validation Testing
 +
* Error Handling
 +
* Cryptography
 +
* Business Logic Testing
 +
* Client Side Testing

Latest revision as of 15:25, 5 August 2014

This article is part of the new OWASP Testing Guide v4.
Back to the OWASP Testing Guide v4 ToC: https://www.owasp.org/index.php/OWASP_Testing_Guide_v4_Table_of_Contents Back to the OWASP Testing Guide Project: https://www.owasp.org/index.php/OWASP_Testing_Project


This section describes the OWASP web application security testing methodology and explains how to test for evidence of vulnerabilities within the application due to deficiencies with identified security controls.

What is Web Application Security Testing?
A security test is a method of evaluating the security of a computer system or network by methodically validating and verifying the effectiveness of application security controls. A web application security test focuses only on evaluating the security of a web application. The process involves an active analysis of the application for any weaknesses, technical flaws, or vulnerabilities. Any security issues that are found will be presented to the system owner, together with an assessment of the impact, a proposal for mitigation or a technical solution.


What is a Vulnerability?
A vulnerability is a flaw or weakness in a system's design, implementation, operation or management that could be exploited to compromise the system's security objectives.


What is a Threat?
A threat is anything (a malicious external attacker, an internal user, a system instability, etc) that may harm the assets owned by an application (resources of value, such as the data in a database or in the file system) by exploiting a vulnerability.


What is a Test?
A test is an action to demonstrate that an application meets the security requirements of its stakeholders.


The Approach in Writing this Guide

The OWASP approach is open and collaborative:

  • Open: every security expert can participate with his or her experience in the project. Everything is free.
  • Collaborative: brainstorming is performed before the articles are written so the team can share ideas and develop a collective vision of the project. That means rough consensus, a wider audience and increased participation.


This approach tends to create a defined Testing Methodology that will be:

  • Consistent
  • Reproducible
  • Rigorous
  • Under quality control


The problems to be addressed are fully documented and tested. It is important to use a method to test all known vulnerabilities and document all the security test activities.


What is the OWASP testing methodology?

Security testing will never be an exact science where a complete list of all possible issues that should be tested can be defined. Indeed, security testing is only an appropriate technique for testing the security of web applications under certain circumstances. The goal of this project is to collect all the possible testing techniques, explain these techniques, and keep the guide updated. The OWASP Web Application Security Testing method is based on the black box approach. The tester knows nothing or has very little information about the application to be tested.


The testing model consists of:

  • Tester: Who performs the testing activities
  • Tools and methodology: The core of this Testing Guide project
  • Application: The black box to test


The test is divided into 2 phases:

  • Phase 1 Passive mode:

In the passive mode the tester tries to understand the application's logic and plays with the application. Tools can be used for information gathering. For example, an HTTP proxy can be used to observe all the HTTP requests and responses. At the end of this phase, the tester should understand all the access points (gates) of the application (e.g., HTTP headers, parameters, and cookies). The Information Gathering section explains how to perform a passive mode test.

For example the tester could find the following:

https://www.example.com/login/Authentic_Form.html

This may indicate an authentication form where the application requests a username and a password.


The following parameters represent two access points (gates) to the application:

http://www.example.com/Appx.jsp?a=1&b=1


In this case, the application shows two gates (parameters a and b). All the gates found in this phase represent a point of testing. A spreadsheet with the directory tree of the application and all the access points would be useful for the second phase.


  • Phase 2 Active mode:

In this phase the tester begins to test using the methodology described in the follow sections.


The set of active tests have been split into 11 sub-categories for a total of 91 controls:

  • Information Gathering
  • Configuration and Deployment Management Testing
  • Identity Management Testing
  • Authentication Testing
  • Authorization Testing
  • Session Management Testing
  • Input Validation Testing
  • Error Handling
  • Cryptography
  • Business Logic Testing
  • Client Side Testing