Difference between revisions of "Testing for Input Validation"

Revision as of 17:28, 4 November 2006

[Up]
OWASP Testing Guide v2 Table of Contents

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 the client should never be trusted for the client has every possibility to tamper with the data: "All Input is Evil" said 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:
Input -> Output == cross-site scripting
Input -> System == command injection
Input -> Query SQL == SQL injection
Input -> Query LDAP == LDAP injection
Input -> Fixed buffer or format string == overflow
Input -> Integer == overflow
...
In every pattern showed the data must be validated from the application before trust it and execute it.

4.6.1 Cross site scripting
4.6.1.1 HTTP Methods and XST
4.6.2 SQL Injection
4.6.2.1 Stored procedure injection
4.6.2.2 Oracle Testing
4.6.2.3 MySQL Testing
4.6.2.4 SQL Server Testing

4.6.3 ORM Injection
4.6.4 LDAP Injection
4.6.5 XML Injection
4.6.6 SSI Injection
4.6.7 XPath Injection
4.6.8 IMAP/SMTP Injection
4.6.9 Code Injection
4.6.10 OS Commanding

4.6.11 Buffer overflow Testing
4.6.11.1 Heap overflow
4.6.11.2 Stack overflow
4.6.11.3 Format string

4.6.12 Incubated vulnerability testing

OWASP Testing Guide v2 Table of Contents