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

Testing for Input Validation

From OWASP
Revision as of 01:26, 10 November 2006 by Mmeucci (talk | contribs) (Data Validation Testing)

Jump to: navigation, search

[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" 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:

4.6.1 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 builded. A XSS breaks the following pattern: Input -> Output == cross-site scripting

4.6.1.1 HTTP Methods and XST
Cross Site Tracing (XST) is a particular XSS testing inwhich we check that the web server is not configured to allow potentially dangerous HTTP commands (methods) and that XST is not possible. A XST breaks the following pattern: Input -> HTTP Methods == XST

4.6.2 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 DB informations that represent the core of sensitive data of every Company. An SQL Injection breaks the following pattern: Input -> Query SQL == 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

Input -> Query LDAP == LDAP injection

4.6.4 LDAP Injection

Input -> System == command injection
4.6.3 ORM 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

Input -> Fixed buffer or format string == overflow
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
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 from the application before trust it and execute it. Our goal is to test if the application really do that.



OWASP Testing Guide v2 Table of Contents