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 for Input Validation"

From OWASP
Jump to: navigation, search
Line 12: Line 12:
 
Testing for Cross site scripting<br>
 
Testing for 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>
 
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>
The following kind of XSS are described in this guide:
+
The following kind of XSS are described in this guide:<br>
[[Testing for Reflected Cross site scripting|4.8.1 Testing for Reflected Cross Site Scripting]]
+
[[Testing for Reflected Cross site scripting|4.8.1 Testing for Reflected Cross Site Scripting]]<br>
[[Testing for Stored Cross site scripting|4.8.2 Testing for Stored Cross Site Scripting]]
+
[[Testing for Stored Cross site scripting|4.8.2 Testing for Stored Cross Site Scripting]]<br>
[[Testing for DOM-based Cross site scripting|4.8.3 Testing for DOM based Cross Site Scripting]]
+
[[Testing for DOM-based Cross site scripting|4.8.3 Testing for DOM based Cross Site Scripting]]<br>
[[Testing for Cross site flashing|4.8.4 Testing for Cross Site Flashing]]
+
[[Testing for Cross site flashing|4.8.4 Testing for Cross Site Flashing]]<br>
  
 
[[Testing for SQL Injection|4.8.5 SQL Injection ]]<br>
 
[[Testing for SQL Injection|4.8.5 SQL Injection ]]<br>
Line 22: Line 22:
 
Input -> Query SQL == SQL injection<br>
 
Input -> Query SQL == SQL injection<br>
 
SQL Injection field comprises:<br>
 
SQL Injection field comprises:<br>
[[Testing for Oracle|4.8.5.1 Oracle Testing ]]
+
[[Testing for Oracle|4.8.5.1 Oracle Testing ]]<br>
[[Testing for MySQL|4.8.5.2 MySQL Testing ]]
+
[[Testing for MySQL|4.8.5.2 MySQL Testing ]]<br>
[[Testing for SQL Server|4.8.5.3 SQL Server Testing]]
+
[[Testing for SQL Server|4.8.5.3 SQL Server Testing]]<br>
[[Testing for MS Access|4.8.5.4 MS Access Testing]]
+
[[Testing for MS Access|4.8.5.4 MS Access Testing]]<br>
[[OWASP_Backend_Security_Project_Testing_PostgreSQL|4.8.5.5 Testing PostgreSQL]]
+
[[OWASP_Backend_Security_Project_Testing_PostgreSQL|4.8.5.5 Testing PostgreSQL]]<br>
  
 
[[Testing for LDAP Injection |4.8.6 LDAP Injection]]<br>
 
[[Testing for LDAP Injection |4.8.6 LDAP Injection]]<br>

Revision as of 14:50, 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 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:
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 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:
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 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.