Difference between revisions of "Testing for Input Validation"

From OWASP
Jump to: navigation, search
(4.6 Data Validation Testing)
(Final edit)
(48 intermediate revisions by 4 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}}
+
  
=== 4.6 Data Validation Testing ===
+
''' 4.8 Data Validation Testing '''
 
----
 
----
  
The most common web application security weakness is the failure to properly validate input from the client or environment. This weakness leads to almost all of the major vulnerabilities in applications, such as interpreter injection, locale/Unicode attacks, file system attacks and buffer overflows.<br>
+
The most common web application security weakness is the failure to properly validate input coming from the client or from the environment before using it. This weakness leads to almost all of the major vulnerabilities in web applications, such as cross site scripting, SQL injection, interpreter injection, locale/Unicode attacks, file system attacks, and buffer overflows.
Data from any external entity/client should never be trusted for an external entity/client has every possibility to tamper with the data: "All Input is Evil" says Michael Howard in his famous book "Writing Secure Code". That's rule number one. The problem is that in a complex application the points of access for an attacker increase and it is easy that you forget to implement this rule.
+
<br>
+
In this chapter we describe how to test all the possible forms of input validation to understand if the application is strong enough against any type of data input.<br>
+
We split Data Validation into this macro categories:<br>
+
  
[[Testing for Cross site scripting|4.6.1 Cross Site Scripting]]<br>
 
We talk about Cross Site Scripting (XSS) testing when try to manipulate the parameters that the application receive in input. We find a XSS when the application doesn't validate our input and creates an output that we have built. A XSS breaks the following pattern: Input -> Output  == cross-site scripting<br>
 
  
[[Testing for HTTP Methods and XST|4.6.1.1 HTTP Methods and XST ]]<br>
+
Data from an external entity or client should never be trusted, since it can be arbitrarily tampered with by an attacker. "All Input is Evil", says Michael Howard in his famous book "Writing Secure Code". That is rule number one. Unfortunately, complex applications often have a large number of entry points, which makes it difficult for a developer to enforce this rule. This chapter describes Data Validation testing. This is the task of testing all the possible forms of input to understand if the application sufficiently validates input data before using it.
Cross Site Tracing (XST) is a particular XSS testing inwhich we check that the web server is not configured to allow potentially dangerous HTTP commands (methods) and that XST is not possible.
+
A XST breaks the following pattern:
+
Input -> HTTP Methods == XST <br>
+
  
[[Testing for SQL Injection|4.6.2 SQL Injection ]]<br>
 
We talk about SQL Injection testing when we try to inject a particular SQL query to the Back end DB whithout that the application make an appropriate data validation. The goal is to manipulate data in the database that represents the core of every company. An SQL Injection breaks the following pattern:
 
Input -> Query SQL == SQL injection<br>
 
SQL Injection field comprises:<br>
 
[[Testing for Oracle|4.6.2.1 Oracle Testing ]]<br>
 
[[Testing for MySQL |4.6.2.2 MySQL Testing ]]<br>
 
[[Testing for SQL Server |4.6.2.3 SQL Server Testing ]]
 
  
[[Testing for LDAP Injection |4.6.3 LDAP Injection]]<br>
+
Data validation testing is split into the following categories:<br>
LDAP Injection Testing is similar to SQL Injection Testing: the differences are that we use LDAP protocol instead of SQL and the target is an LDAP Server instead of an SQL Server.  
+
 
An LDAP Injection breaks the following pattern:<br>
+
'''Testing for Cross site scripting'''<br>
 +
Cross Site Scripting (XSS) testing checks if it is possible to manipulate the input parameters of the application so that it generates malicious output. Testers find an XSS vulnerability when the application does not validate their input and creates an output that is under their control. This vulnerability leads to various attacks, for example, stealing confidential information (such as session cookies) or taking control of the victim's browser. An XSS attack breaks the following pattern: Input -> Output  == cross-site scripting.
 +
 
 +
 
 +
In this guide, the following types of XSS testing are discussed in details:<br>
 +
[[Testing for Reflected Cross site scripting (OWASP-DV-001) |4.8.1 Testing for Reflected Cross Site Scripting (OWASP-DV-001) ]]<br>
 +
[[Testing for Stored Cross site scripting  (OWASP-DV-002) |4.8.2 Testing for Stored Cross Site Scripting(OWASP-DV-002) ]]<br>
 +
[[Testing for DOM-based Cross site scripting  (OWASP-DV-003)|4.8.3 Testing for DOM based Cross Site Scripting(OWASP-DV-003) ]]<br>
 +
[[Testing for Cross site flashing  (OWASP-DV-004)|4.8.4 Testing for Cross Site Flashing(OWASP-DV-004) ]]
 +
 
 +
 
 +
'''[[Testing for SQL Injection (OWASP-DV-005)|4.8.5 SQL Injection  (OWASP-DV-005)]]<br>'''
 +
SQL injection testing checks if it is possible to inject data into the application so that it executes a user-controlled SQL query in the back-end database. Testers find an SQL injection vulnerability if the application uses user input to create SQL queries without proper input validation. A successful exploitation of this class of vulnerability allows an unauthorized user to access or manipulate data in the database. Note that application data often represents the core asset of a company. An SQL
 +
 
 +
Injection attack breaks the following pattern:
 +
Input -> Query SQL == SQL injection
 +
 
 +
 
 +
SQL Injection testing is further broken down into:<br>
 +
[[Testing for Oracle |4.8.5.1 Oracle Testing]]<br>
 +
[[Testing for MySQL |4.8.5.2 MySQL Testing ]]<br>
 +
[[Testing for SQL Server |4.8.5.3 SQL Server Testing ]]<br>
 +
[[Testing for MS Access|4.8.5.4 MS Access Testing]]<br>
 +
[[OWASP_Backend_Security_Project_Testing_PostgreSQL|4.8.5.5 Testing PostgreSQL]]<br>
 +
 
 +
 
 +
'''[[Testing for LDAP Injection (OWASP-DV-006) |4.8.6 LDAP Injection  (OWASP-DV-006)]]<br>'''
 +
LDAP injection testing is similar to SQL Injection testing. The differences are that testers use the LDAP protocol instead of SQL and the target is an LDAP Server instead of a SQL Server.  
 +
An LDAP Injection attack breaks the following pattern:<br>
 
Input -> Query LDAP == LDAP injection<br>
 
Input -> Query LDAP == LDAP injection<br>
  
[[Testing for ORM Injection |4.6.4 ORM Injection]]<br>
 
Also ORM Injection Testing is similar to SQL Injection Testing, but in this case we use an SQL Injection against an ORM generated data access object model. From the point of view of a tester, this attack is virtually identical to a SQL Injection attack: however, the injection vulnerability exists in code generated by the ORM tool.<br>
 
  
[[Testing for XML Injection |4.6.5 XML Injection]]<br>
+
'''[[Testing for ORM Injection  (OWASP-DV-007) |4.8.7 ORM Injection  (OWASP-DV-007)]]<br>'''
We talk about XML Injection testing when we try to inject a particular XML doc to the application: if the XML parser fails to make an appropriate data validation the test will results positive.<br>
+
ORM injection testing is similar to SQL Injection Testing. In this case, testers use a SQL Injection against an ORM-generated data access object model. From the tester's point of view, this attack is virtually identical to a SQL Injection attack. However, the injection vulnerability exists in the code generated by an ORM tool.<br>
An XML Injection breaks the following pattern:<br>
+
 
 +
 
 +
'''[[Testing for XML Injection (OWASP-DV-008) |4.8.8 XML Injection (OWASP-DV-008)]]<br>'''
 +
XML injection testing checks if it possible to inject a particular XML document into the application. Testers find an XML injection vulnerability if the XML parser fails to make appropriate data validation.<br>
 +
An XML Injection attack breaks the following pattern:<br>
 
Input -> XML doc == XML injection<br>
 
Input -> XML doc == XML injection<br>
  
[[Testing for SSI Injection |4.6.6 SSI Injection]]<br>
 
Web servers usually give to the developer the possibility to add small pieces of dynamic code inside static html pages, without having to play with full-fledged server-side or client-side languages. This feature is incarnated by the Server-Side Includes (SSI), a very simple extensions that can enable an attacker to inject code into html pages, or even perform remote code execution.<br>
 
  
[[Testing for XPath Injection |4.6.7 XPath Injection]]<br>
+
'''[[Testing for SSI Injection (OWASP-DV-009) |4.8.9 SSI Injection (OWASP-DV-009)]]<br>'''
XPath is a language that has been designed and developed to operate on data that is described with XML. The goal of XPath injection Testing is to inject XPath elements in a query that uses this language. Some of the possible targets are to bypass authentication or access information in an unauthorized manner.<br>
+
Web servers usually give developers the ability to add small pieces of dynamic code inside static HTML pages, without having to deal with full-fledged server-side or client-side languages. This feature is incarnated by Server-Side Includes (SSI) Injection. In SSI injection testing, testers check if it is possible to inject into the application data that will be interpreted by SSI mechanisms. A successful exploitation of this vulnerability allows an attacker to inject code into HTML pages or even perform remote code execution.<br>
  
[[Testing for IMAP/SMTP Injection|4.6.8 IMAP/SMTP Injection]]<br>
 
This threat affects all those applications that communicate with mail servers (IMAP/SMTP), generally webmail applications. The aim of this test is to verify the capacity to inject arbitrary IMAP/SMTP commands into the mail servers, due to input data not properly sanitized. <br>
 
An IMAP/SMTP Injection breaks the following pattern:<br>
 
Input -> IMAP/SMPT command == IMAP/SMTP Injection<br>
 
  
[[Testing for Code Injection|4.6.9 Code Injection]]<br>
+
'''[[Testing for XPath Injection (OWASP-DV-010) |4.8.10 XPath Injection (OWASP-DV-010)]]<br>'''
This section describes how a tester can check if it is possible to enter code as input on a web page and have it executed by the web server.<br>
+
XPath is a language that has been designed and developed primarily to address parts of an XML document. In XPath injection testing, testers check if it is possible to inject data into an application so that it executes user-controlled XPath queries. When successfully exploited, this vulnerability may allow an attacker to bypass authentication mechanisms or access information without proper authorization.<br>
A Code Injection breaks the following pattern:<br>
+
Input -> malicius Code == Code Injection<br>
+
  
[[Testing for Command Injection|4.6.10 OS Commanding]]<br>
+
 
In this paragraph we describe how to test an application for OS commanding testing: this means try to inject an on command throughout an HTTP request to the application.<br>
+
'''[[Testing for IMAP/SMTP Injection (OWASP-DV-011)|4.8.11 IMAP/SMTP Injection  (OWASP-DV-011)]]<br>'''
An OS Commanding Injection breaks the following pattern:<br>
+
This threat affects all the applications that communicate with mail servers (IMAP/SMTP), generally web mail applications. In IMAP/SMTP injection testing, testers check if it possible to inject arbitrary IMAP/SMTP commands into the mail servers, due to input data not properly sanitized. <br>
 +
An IMAP/SMTP Injection attack breaks the following pattern:<br>
 +
Input -> IMAP/SMTP command == IMAP/SMTP Injection<br>
 +
 
 +
 
 +
'''[[Testing for Code Injection  (OWASP-DV-012)|4.8.12 Code Injection  (OWASP-DV-012)]]<br>'''
 +
Code injection testing checks if it is possible to inject into an application data that will be later executed by the web server.<br>
 +
A Code Injection attack breaks the following pattern:<br>
 +
Input -> malicious Code == Code Injection<br>
 +
 
 +
 
 +
'''[[Testing for Command Injection  (OWASP-DV-013)|4.8.13 OS Commanding  (OWASP-DV-013)]]<br>'''
 +
In command injection testing testers will try to inject an OS command through an HTTP request into the application.<br>
 +
An OS Command Injection attack breaks the following pattern:<br>
 
Input -> OS Command == OS Command Injection<br>
 
Input -> OS Command == OS Command Injection<br>
  
[[Testing for Buffer Overflow|4.6.11 Buffer overflow Testing ]]<br>
+
 
In these tests we check for different types of buffer overflow vulnerabilities. Here are the testing methods for the common types of buffer overflow vulnerabilities:
+
'''[[Testing for Buffer Overflow (OWASP-DV-014)|4.8.14 Buffer overflow (OWASP-DV-014)]]<br>'''
[[Testing for Heap Overflow |4.6.11.1 Heap overflow ]]<br>
+
In these tests, testers check for different types of buffer overflow vulnerabilities. Here are the testing methods for the common types of buffer overflow vulnerabilities:<br>
[[Testing for Stack Overflow |4.6.11.2 Stack overflow ]]<br>
+
[[Testing for Heap Overflow |4.8.14.1 Heap overflow ]]<br>
[[Testing for Format String |4.6.11.3 Format string ]]<br>
+
[[Testing for Stack Overflow |4.8.14.2 Stack overflow ]]<br>
 +
[[Testing for Format String |4.8.14.3 Format string ]]<br>
 +
 
 
In general Buffer overflow breaks the following pattern:<br>
 
In general Buffer overflow breaks the following pattern:<br>
 
Input -> Fixed buffer or format string == overflow<br>
 
Input -> Fixed buffer or format string == overflow<br>
  
[[Testing for Incubated Vulnerability |4.6.12 Incubated vulnerability testing]] <br>
 
Incubated testing is a complex testing that need more that one data valition vulnerability to work.<br>
 
  
In every pattern showed the data must be validated by the application before its trusted and processed. Our goal is to test if the application actually does what is meant to do and does not do what its not.
+
'''[[Testing for Incubated Vulnerability (OWASP-DV-015) |4.8.15 Incubated vulnerability (OWASP-DV-015)]] <br>'''
 +
Incubated testing is a complex testing that needs more than one data validation vulnerability to work.<br>
  
  
 +
[[Testing for HTTP Splitting/Smuggling  (OWASP-DV-016)|4.8.16 Testing for HTTP Splitting/Smuggling  (OWASP-DV-016)]]<br>
 +
Describes how to test for an HTTP Exploit, as HTTP Verb, HTTP Splitting, HTTP Smuggling.
  
  
{{Category:OWASP Testing Project AoC}}
+
In every pattern shown, the data should be validated by the application before it's trusted and processed. The goal of testing is to verify if the application actually performs validation and does not trust its input.

Revision as of 03:43, 18 May 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


4.8 Data Validation Testing


The most common web application security weakness is the failure to properly validate input coming from the client or from the environment before using it. This weakness leads to almost all of the major vulnerabilities in web applications, such as cross site scripting, SQL injection, interpreter injection, locale/Unicode attacks, file system attacks, and buffer overflows.


Data from an external entity or client should never be trusted, since it can be arbitrarily tampered with by an attacker. "All Input is Evil", says Michael Howard in his famous book "Writing Secure Code". That is rule number one. Unfortunately, complex applications often have a large number of entry points, which makes it difficult for a developer to enforce this rule. This chapter describes Data Validation testing. This is the task of testing all the possible forms of input to understand if the application sufficiently validates input data before using it.


Data validation testing is split into the following categories:

Testing for Cross site scripting
Cross Site Scripting (XSS) testing checks if it is possible to manipulate the input parameters of the application so that it generates malicious output. Testers find an XSS vulnerability when the application does not validate their input and creates an output that is under their control. This vulnerability leads to various attacks, for example, stealing confidential information (such as session cookies) or taking control of the victim's browser. An XSS attack breaks the following pattern: Input -> Output == cross-site scripting.


In this guide, the following types of XSS testing are discussed in details:
4.8.1 Testing for Reflected Cross Site Scripting (OWASP-DV-001)
4.8.2 Testing for Stored Cross Site Scripting(OWASP-DV-002)
4.8.3 Testing for DOM based Cross Site Scripting(OWASP-DV-003)
4.8.4 Testing for Cross Site Flashing(OWASP-DV-004)


4.8.5 SQL Injection (OWASP-DV-005)
SQL injection testing checks if it is possible to inject data into the application so that it executes a user-controlled SQL query in the back-end database. Testers find an SQL injection vulnerability if the application uses user input to create SQL queries without proper input validation. A successful exploitation of this class of vulnerability allows an unauthorized user to access or manipulate data in the database. Note that application data often represents the core asset of a company. An SQL

Injection attack breaks the following pattern: Input -> Query SQL == SQL injection


SQL Injection testing is further broken down into:
4.8.5.1 Oracle Testing
4.8.5.2 MySQL Testing
4.8.5.3 SQL Server Testing
4.8.5.4 MS Access Testing
4.8.5.5 Testing PostgreSQL


4.8.6 LDAP Injection (OWASP-DV-006)
LDAP injection testing is similar to SQL Injection testing. The differences are that testers use the LDAP protocol instead of SQL and the target is an LDAP Server instead of a SQL Server. An LDAP Injection attack breaks the following pattern:
Input -> Query LDAP == LDAP injection


4.8.7 ORM Injection (OWASP-DV-007)
ORM injection testing is similar to SQL Injection Testing. In this case, testers use a SQL Injection against an ORM-generated data access object model. From the tester's point of view, this attack is virtually identical to a SQL Injection attack. However, the injection vulnerability exists in the code generated by an ORM tool.


4.8.8 XML Injection (OWASP-DV-008)
XML injection testing checks if it possible to inject a particular XML document into the application. Testers find an XML injection vulnerability if the XML parser fails to make appropriate data validation.
An XML Injection attack breaks the following pattern:
Input -> XML doc == XML injection


4.8.9 SSI Injection (OWASP-DV-009)
Web servers usually give developers the ability to add small pieces of dynamic code inside static HTML pages, without having to deal with full-fledged server-side or client-side languages. This feature is incarnated by Server-Side Includes (SSI) Injection. In SSI injection testing, testers check if it is possible to inject into the application data that will be interpreted by SSI mechanisms. A successful exploitation of this vulnerability allows an attacker to inject code into HTML pages or even perform remote code execution.


4.8.10 XPath Injection (OWASP-DV-010)
XPath is a language that has been designed and developed primarily to address parts of an XML document. In XPath injection testing, testers check if it is possible to inject data into an application so that it executes user-controlled XPath queries. When successfully exploited, this vulnerability may allow an attacker to bypass authentication mechanisms or access information without proper authorization.


4.8.11 IMAP/SMTP Injection (OWASP-DV-011)
This threat affects all the applications that communicate with mail servers (IMAP/SMTP), generally web mail applications. In IMAP/SMTP injection testing, testers check if it possible to inject arbitrary IMAP/SMTP commands into the mail servers, due to input data not properly sanitized.
An IMAP/SMTP Injection attack breaks the following pattern:
Input -> IMAP/SMTP command == IMAP/SMTP Injection


4.8.12 Code Injection (OWASP-DV-012)
Code injection testing checks if it is possible to inject into an application data that will be later executed by the web server.
A Code Injection attack breaks the following pattern:
Input -> malicious Code == Code Injection


4.8.13 OS Commanding (OWASP-DV-013)
In command injection testing testers will try to inject an OS command through an HTTP request into the application.
An OS Command Injection attack breaks the following pattern:
Input -> OS Command == OS Command Injection


4.8.14 Buffer overflow (OWASP-DV-014)
In these tests, testers check for different types of buffer overflow vulnerabilities. Here are the testing methods for the common types of buffer overflow vulnerabilities:
4.8.14.1 Heap overflow
4.8.14.2 Stack overflow
4.8.14.3 Format string

In general Buffer overflow breaks the following pattern:
Input -> Fixed buffer or format string == overflow


4.8.15 Incubated vulnerability (OWASP-DV-015)
Incubated testing is a complex testing that needs more than one data validation vulnerability to work.


4.8.16 Testing for HTTP Splitting/Smuggling (OWASP-DV-016)
Describes how to test for an HTTP Exploit, as HTTP Verb, HTTP Splitting, HTTP Smuggling.


In every pattern shown, the data should be validated by the application before it's trusted and processed. The goal of testing is to verify if the application actually performs validation and does not trust its input.