Testing for Input Validation - Revision history

Wmv: Formatting.

2019-06-09T20:00:05Z

Formatting.

Wmv: Formatting.

2019-06-09T19:51:38Z

Formatting.

Wmv: Added missing sections/subsections: 4.8.12.1, 4.8.12.2, and 4.8.17.

2019-06-09T19:50:40Z

Added missing sections/subsections: 4.8.12.1, 4.8.12.2, and 4.8.17.

Andrew Muller at 12:34, 8 August 2014

2014-08-08T12:34:02Z

Andrew Muller: Amend heading to match Common Numbering

2014-08-05T12:58:06Z

Amend heading to match Common Numbering

Andrew Muller: Andrew Muller moved page Testing for Data Validation to Testing for Input Validation: Amend heading to match Common Numbering

2014-08-05T12:57:07Z

Andrew Muller moved page Testing for Data Validation to Testing for Input Validation: Amend heading to match Common Numbering

Andrew Muller at 15:25, 31 July 2014

2014-07-31T15:25:00Z

Show changes

Jane O'Connor: Final edit

2014-05-18T09:43:46Z

Final edit

Show changes

Mmeucci at 14:51, 9 October 2012

2012-10-09T14:51:04Z

KirstenS at 17:03, 6 February 2009

2009-02-06T17:03:43Z

@@ Line 10: / Line 10: @@
-Input validation testing is split into the following categories:<br>
+Input validation testing is split into the following categories.<br> <br>
 '''Testing for Cross site scripting'''<br>
@@ Line 17: / Line 17: @@
 In this guide, the following types of XSS testing are discussed in details:<br>
-Client side XSS testing, such as DOM XSS and Cross site Flashing is discussed in the Client Side testing section.
+[[Testing for Reflected Cross site scripting (OTG-INPVAL-001) |'''4.8.1 Testing for Reflected Cross Site Scripting (OTG-INPVAL-001)''']]
 '''Testing for HTTP Verb Tampering and Parameter Pollution'''
@@ Line 33: / Line 35: @@
 and HTTP Parameter testing techniques are presented in
 [[Testing for HTTP Parameter pollution (OTG-INPVAL-004)|'''4.8.4 Testing for HTTP Parameter pollution (OTG-INPVAL-004)''']]
-'''[[Testing for SQL Injection  (OTG-INPVAL-005)|4.8.5 SQL Injection  (OTG-INPVAL-005)]]<br>'''
+<br> '''[[Testing for SQL Injection  (OTG-INPVAL-005)|4.8.5 SQL Injection  (OTG-INPVAL-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 by product or vendor:<br>
@@ Line 48: / Line 49: @@
 [[Testing for NoSQL injection|4.8.5.6 Testing for NoSQL injection]]<br>
-'''[[Testing for LDAP Injection  (OTG-INPVAL-006) |4.8.6 LDAP Injection  (OTG-INPVAL-006)]]<br>'''
+<br> '''[[Testing for LDAP Injection  (OTG-INPVAL-006) |4.8.6 LDAP Injection  (OTG-INPVAL-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>
-'''[[Testing for ORM Injection   (OTG-INPVAL-007) |4.8.7 ORM Injection  (OTG-INPVAL-007)]]<br>'''
+<br> '''[[Testing for ORM Injection   (OTG-INPVAL-007) |4.8.7 ORM Injection  (OTG-INPVAL-007)]]<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>
 '''[[Testing for XML Injection (OTG-INPVAL-008) |4.8.8 XML Injection (OTG-INPVAL-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>
 '''[[Testing for SSI Injection  (OTG-INPVAL-009) |4.8.9 SSI Injection  (OTG-INPVAL-009)]]<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 XPath Injection  (OTG-INPVAL-010) |4.8.10 XPath Injection  (OTG-INPVAL-010)]]<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>
 '''[[Testing for IMAP/SMTP Injection  (OTG-INPVAL-011)|4.8.11 IMAP/SMTP Injection  (OTG-INPVAL-011)]]<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  (OTG-INPVAL-012)|4.8.12 Code Injection  (OTG-INPVAL-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>
@@ Line 75: / Line 81: @@
 [[Testing for Remote File Inclusion|4.8.12.2 Testing for Remote File Inclusion]]<br>
 '''[[Testing for Command Injection   (OTG-INPVAL-013)|4.8.13 OS Commanding   (OTG-INPVAL-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>
 '''[[Testing for Buffer Overflow (OTG-INPVAL-014)|4.8.14 Buffer overflow (OTG-INPVAL-014)]]<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 Heap Overflow |4.8.14.1 Heap overflow]] <br>
@@ Line 87: / Line 95: @@
 In general Buffer overflow breaks the following pattern:<br>
 Input -> Fixed buffer or format string == overflow<br>
 '''[[Testing for Incubated Vulnerability (OTG-INPVAL-015) |4.8.15 Incubated vulnerability (OTG-INPVAL-015)]] <br>'''
 Incubated testing is a complex testing that needs more than one data validation vulnerability to work.<br>
 [[Testing for HTTP Splitting/Smuggling  (OTG-INPVAL-016)|'''4.8.16 Testing for HTTP Splitting/Smuggling  (OTG-INPVAL-016)''']]<br>
 Describes how to test for an HTTP Exploit, as HTTP Verb, HTTP Splitting, HTTP Smuggling.
-[[Testing for HTTP Incoming requests (OTG-INPVAL-017)|'''4.8.17 Testing for HTTP Incoming Requests (OTG-INPVAL-017)''']]
+<br> [[Testing for HTTP Incoming requests (OTG-INPVAL-017)|'''4.8.17 Testing for HTTP Incoming Requests (OTG-INPVAL-017)''']]
 Describes how to monitor all incoming/outgoing http requests on both client or web server side. This is in order to verify if there are unnecessary or suspicious HTTP requests being sent in the background.

@@ Line 47: / Line 47: @@
 [[Testing for MS Access|4.8.5.5 MS Access Testing]]<br>
 [[Testing for NoSQL injection|4.8.5.6 Testing for NoSQL injection]]<br>
 '''[[Testing for LDAP Injection  (OTG-INPVAL-006) |4.8.6 LDAP Injection  (OTG-INPVAL-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>
 '''[[Testing for ORM Injection   (OTG-INPVAL-007) |4.8.7 ORM Injection  (OTG-INPVAL-007)]]<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>

@@ Line 17: / Line 17: @@
 In this guide, the following types of XSS testing are discussed in details:<br>
-[[Testing for Reflected Cross site scripting (OTG-INPVAL-001) |4.8.1 Testing for Reflected Cross Site Scripting (OTG-INPVAL-001) ]]<br>
+[[Testing for Reflected Cross site scripting (OTG-INPVAL-001) |'''4.8.1 Testing for Reflected Cross Site Scripting (OTG-INPVAL-001)''']] <br>
-[[Testing for Stored Cross site scripting  (OTG-INPVAL-002) |4.8.2 Testing for Stored Cross Site Scripting (OTG-INPVAL-002) ]]<br>
+[[Testing for Stored Cross site scripting  (OTG-INPVAL-002) |'''4.8.2 Testing for Stored Cross Site Scripting (OTG-INPVAL-002)''']] <br>
 Client side XSS testing, such as DOM XSS and Cross site Flashing is discussed in the Client Side testing section.
 '''Testing for HTTP Verb Tampering and Parameter Pollution'''
 HTTP Verb Tampering tests the web application's response to different HTTP methods accessing system objects. For every system object discovered during spidering, the tester should attempt accessing all of those objects with every HTTP method.
 HTTP Parameter Pollution tests the applications response to receiving multiple HTTP parameters with the same name. For example, if the parameter ''username'' is included in the GET or POST parameters twice, which one is honoured, if any.
@@ Line 28: / Line 29: @@
 HTTP Verb Tampering is described in
-[[Testing for HTTP Verb Tampering (OTG-INPVAL-003)|4.8.3 Testing for HTTP Verb Tampering (OTG-INPVAL-003)]]
+[[Testing for HTTP Verb Tampering (OTG-INPVAL-003)|'''4.8.3 Testing for HTTP Verb Tampering (OTG-INPVAL-003)''']]
 and HTTP Parameter testing techniques are presented in
-[[Testing for HTTP Parameter pollution (OTG-INPVAL-004)|4.8.4 Testing for HTTP Parameter pollution (OTG-INPVAL-004) ]]
+[[Testing for HTTP Parameter pollution (OTG-INPVAL-004)|'''4.8.4 Testing for HTTP Parameter pollution (OTG-INPVAL-004)''']]
 '''[[Testing for SQL Injection  (OTG-INPVAL-005)|4.8.5 SQL Injection  (OTG-INPVAL-005)]]<br>'''
@@ Line 41: / Line 42: @@
 SQL Injection testing is further broken down by product or vendor:<br>
 [[Testing for Oracle |4.8.5.1 Oracle Testing]]<br>
-[[Testing for MySQL |4.8.5.2 MySQL 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 SQL Server |4.8.5.3 SQL Server Testing]] <br>
 [[OWASP_Backend_Security_Project_Testing_PostgreSQL|4.8.5.4 Testing PostgreSQL]]<br>
 [[Testing for MS Access|4.8.5.5 MS Access Testing]]<br>
 [[Testing for NoSQL injection|4.8.5.6 Testing for NoSQL injection]]<br>
 '''[[Testing for LDAP Injection  (OTG-INPVAL-006) |4.8.6 LDAP Injection  (OTG-INPVAL-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>
 '''[[Testing for ORM Injection   (OTG-INPVAL-007) |4.8.7 ORM Injection  (OTG-INPVAL-007)]]<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>
 '''[[Testing for XML Injection (OTG-INPVAL-008) |4.8.8 XML Injection (OTG-INPVAL-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>
 '''[[Testing for SSI Injection  (OTG-INPVAL-009) |4.8.9 SSI Injection  (OTG-INPVAL-009)]]<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 XPath Injection  (OTG-INPVAL-010) |4.8.10 XPath Injection  (OTG-INPVAL-010)]]<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>
 '''[[Testing for IMAP/SMTP Injection  (OTG-INPVAL-011)|4.8.11 IMAP/SMTP Injection  (OTG-INPVAL-011)]]<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  (OTG-INPVAL-012)|4.8.12 Code Injection  (OTG-INPVAL-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>
+Input -> malicious Code == Code Injection
 '''[[Testing for Command Injection   (OTG-INPVAL-013)|4.8.13 OS Commanding   (OTG-INPVAL-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>
 '''[[Testing for Buffer Overflow (OTG-INPVAL-014)|4.8.14 Buffer overflow (OTG-INPVAL-014)]]<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 Heap Overflow |4.8.14.1 Heap overflow ]]<br>
+[[Testing for Heap Overflow |4.8.14.1 Heap overflow]] <br>
-[[Testing for Stack Overflow |4.8.14.2 Stack overflow ]]<br>
+[[Testing for Stack Overflow |4.8.14.2 Stack overflow]] <br>
-[[Testing for Format String |4.8.14.3 Format string ]]<br>
+[[Testing for Format String |4.8.14.3 Format string]] <br>
 In general Buffer overflow breaks the following pattern:<br>
 Input -> Fixed buffer or format string == overflow<br>
 '''[[Testing for Incubated Vulnerability (OTG-INPVAL-015) |4.8.15 Incubated vulnerability (OTG-INPVAL-015)]] <br>'''
 Incubated testing is a complex testing that needs more than one data validation vulnerability to work.<br>
-[[Testing for HTTP Splitting/Smuggling  (OTG-INPVAL-016)|4.8.16 Testing for HTTP Splitting/Smuggling  (OTG-INPVAL-016)]]<br>
+Describes how to monitor all incoming/outgoing http requests on both client or web server side. This is in order to verify if there are unnecessary or suspicious HTTP requests being sent in the background.
 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.

@@ Line 26: / Line 26: @@
 HTTP Parameter Pollution tests the applications response to receiving multiple HTTP parameters with the same name. For example, if the parameter ''username'' is included in the GET or POST parameters twice, which one is honoured, if any.
-'''[[Testing for SQL Injection  (OTG-INPVAL-006)|4.8.5 SQL Injection  (OTG-INPVAL-006)]]<br>'''
+HTTP Verb Tampering is described in
 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
@@ Line 40: / Line 48: @@
-'''[[Testing for LDAP Injection  (OTG-INPVAL-007) |4.8.6 LDAP Injection  (OTG-INPVAL-007)]]<br>'''
+'''[[Testing for LDAP Injection  (OTG-INPVAL-006) |4.8.6 LDAP Injection  (OTG-INPVAL-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>
@@ Line 46: / Line 54: @@
-'''[[Testing for ORM Injection   (OTG-INPVAL-008) |4.8.7 ORM Injection  (OTG-INPVAL-008)]]<br>'''
+'''[[Testing for ORM Injection   (OTG-INPVAL-007) |4.8.7 ORM Injection  (OTG-INPVAL-007)]]<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>
-'''[[Testing for XML Injection (OTG-INPVAL-009) |4.8.8 XML Injection (OTG-INPVAL-009)]]<br>'''
+'''[[Testing for XML Injection (OTG-INPVAL-008) |4.8.8 XML Injection (OTG-INPVAL-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>
@@ Line 56: / Line 64: @@
-'''[[Testing for SSI Injection  (OTG-INPVAL-010) |4.8.9 SSI Injection  (OTG-INPVAL-010)]]<br>'''
+'''[[Testing for SSI Injection  (OTG-INPVAL-009) |4.8.9 SSI Injection  (OTG-INPVAL-009)]]<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 XPath Injection  (OTG-INPVAL-011) |4.8.10 XPath Injection  (OTG-INPVAL-011)]]<br>'''
+'''[[Testing for XPath Injection  (OTG-INPVAL-010) |4.8.10 XPath Injection  (OTG-INPVAL-010)]]<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>
-'''[[Testing for IMAP/SMTP Injection  (OTG-INPVAL-012)|4.8.11 IMAP/SMTP Injection  (OTG-INPVAL-012)]]<br>'''
+'''[[Testing for IMAP/SMTP Injection  (OTG-INPVAL-011)|4.8.11 IMAP/SMTP Injection  (OTG-INPVAL-011)]]<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>
@@ Line 70: / Line 78: @@
-'''[[Testing for Code Injection  (OTG-INPVAL-013)|4.8.12 Code Injection  (OTG-INPVAL-013)]]<br>'''
+'''[[Testing for Code Injection  (OTG-INPVAL-012)|4.8.12 Code Injection  (OTG-INPVAL-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>
@@ Line 76: / Line 84: @@
-'''[[Testing for Command Injection   (OTG-INPVAL-014)|4.8.13 OS Commanding   (OTG-INPVAL-014)]]<br>'''
+'''[[Testing for Command Injection   (OTG-INPVAL-013)|4.8.13 OS Commanding   (OTG-INPVAL-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>
@@ Line 82: / Line 90: @@
-'''[[Testing for Buffer Overflow (OTG-INPVAL-015)|4.8.14 Buffer overflow (OTG-INPVAL-015)]]<br>'''
+'''[[Testing for Buffer Overflow (OTG-INPVAL-014)|4.8.14 Buffer overflow (OTG-INPVAL-014)]]<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 Heap Overflow |4.8.14.1 Heap overflow ]]<br>
@@ Line 92: / Line 100: @@
-'''[[Testing for Incubated Vulnerability (OTG-INPVAL-016) |4.8.15 Incubated vulnerability (OTG-INPVAL-016)]] <br>'''
+'''[[Testing for Incubated Vulnerability (OTG-INPVAL-015) |4.8.15 Incubated vulnerability (OTG-INPVAL-015)]] <br>'''
 Incubated testing is a complex testing that needs more than one data validation vulnerability to work.<br>
-[[Testing for HTTP Splitting/Smuggling  (OTG-INPVAL-017)|4.8.16 Testing for HTTP Splitting/Smuggling  (OTG-INPVAL-017)]]<br>
+[[Testing for HTTP Splitting/Smuggling  (OTG-INPVAL-016)|4.8.16 Testing for HTTP Splitting/Smuggling  (OTG-INPVAL-016)]]<br>
 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.

@@ Line 1: / Line 1: @@
 {{Template:OWASP Testing Guide v4}}
-''' 4.8 Data Validation Testing '''
+''' 4.8 Input Validation Testing '''
 ----
@@ Line 10: / Line 10: @@
-Data validation testing is split into the following categories:<br>
+Input validation testing is split into the following categories:<br>
 '''Testing for Cross site scripting'''<br>

← Older revision	Revision as of 12:57, 5 August 2014
(No difference)

← Older revision		Revision as of 14:51, 9 October 2012
Line 1:		Line 1:
−	{{Template:OWASP Testing Guide v3}}	+	{{Template:OWASP Testing Guide v4}}

	''' 4.8 Data Validation Testing '''		''' 4.8 Data Validation Testing '''

@@ Line 7: / Line 7: @@
 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.
 <br>
-In this chapter, we describe 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.<br>
+In this chapter, we describe 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.<br>
 We split data validation testing into the following categories:<br>