Testing for Input Validation
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 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.
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.
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.
We split Data Validation into this macro categories:
Testing for Cross site scripting
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
The following kind of XSS are described in this guide:
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
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
SQL Injection field comprises:
18.104.22.168 Oracle Testing
22.214.171.124 MySQL Testing
126.96.36.199 SQL Server Testing
188.8.131.52 MS Access Testing
184.108.40.206 Testing PostgreSQL
4.8.6 LDAP Injection
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:
Input -> Query LDAP == LDAP injection
4.8.7 ORM Injection
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.
4.8.8 XML Injection
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.
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 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.
4.8.10 XPath Injection
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.
4.8.11 IMAP/SMTP Injection
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.
An IMAP/SMTP Injection breaks the following pattern:
Input -> IMAP/SMPT command == IMAP/SMTP Injection
4.8.12 Code Injection
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.
A Code Injection breaks the following pattern:
Input -> malicius Code == Code Injection
4.8.13 OS Commanding
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.
An OS Commanding 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:
220.127.116.11 Heap overflow
18.104.22.168 Stack overflow
22.214.171.124 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 valition vulnerability to work.
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.