Difference between revisions of "Testing for Input Validation"

Revision as of 16:25, 22 August 2008

OWASP Testing Guide v3 Table of Contents

This article is part of the OWASP Testing Guide v3. The entire OWASP Testing Guide v3 can be downloaded here.

OWASP at the moment is working at the OWASP Testing Guide v4: you can browse the Guide here

4.8 Data Validation Testing

The most common web application security weakness is the failure to properly validate input coming from the client or 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.
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.
We split data validation testing into the following categories:

Testing for Cross site scripting
In Cross Site Scripting (XSS) testing, we test if it possible to manipulate the input parameters of the application so that it generates malicious output. We find a XSS vulnerability when the application does not validate our input and creates an output that is under our control. This vulnerability leads to various attacks, for example, stealing confidential information (such as session cookies) or taking control of the victim's browser. A XSS breaks the following pattern: Input -> Output == cross-site scripting
In this guide, we describe the following types of XSS testing:
4.8.1 Testing for Reflected Cross Site Scripting
4.8.2 Testing for Stored Cross Site Scripting
4.8.3 Testing for DOM based Cross Site Scripting
4.8.4 Testing for Cross Site Flashing

4.8.5 SQL Injection
In SQL injection testing, we test if it possible to inject data into the application so that it executes a user-controlled SQL query in the back-end DB. We find a 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 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
LDAP injection testing is similar to SQL Injection Testing. The differences are that we use the LDAP protocol instead of SQL and that the target is an LDAP Server instead of an SQL Server. An LDAP Injection breaks the following pattern:
Input -> Query LDAP == LDAP injection

4.8.7 ORM Injection
ORM injection testing is similar to SQL Injection Testing, as well. In this case, we use an SQL Injection against an ORM-generated data access object model. From the tester 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
In XML injection testing, we test if it possible to inject a particular XML document into the application. We find a XML injection vulnerability if the XML parser fails to make appropriate data validation.
An XML Injection breaks the following pattern:
Input -> XML doc == XML injection

4.8.9 SSI Injection
Web servers usually give to the developer the possibility 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 the Server-Side Includes (SSI). In SSI injection testing, we test if it possible to inject data into the application 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
XPath is a language that has been designed and developed primarily to address parts of an XML document. In XPath injection testing, we test if it 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
This threat affects all the applications that communicate with mail servers (IMAP/SMTP), generally webmail applications. In IMAP/SMTP injection testing, we test if it possible to inject arbitrary IMAP/SMTP commands into the mail servers, due to input data not properly sanitized.
An IMAP/SMTP Injection breaks the following pattern:
Input -> IMAP/SMPT command == IMAP/SMTP Injection

4.8.12 Code Injection
In code injection testing, we check if it is possible to inject into an application data that will be later executed by the web server.
A Code Injection breaks the following pattern:
Input -> malicius Code == Code Injection

4.8.13 OS Commanding
In command injection testing, we will try to inject an OS command throughout an HTTP request into the application.
An OS Command Injection breaks the following pattern:
Input -> OS Command == OS Command Injection

4.8.14 Buffer overflow Testing
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:
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 testing
Incubated testing is a complex testing that need more that one data validation vulnerability to work.

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