[Forgot Password]
Login  Register Subscribe












Paid content will be excluded from the download.

Download | Alert*
view XML

Improper Input Validation

ID: 20Date: (C)2012-05-14   (M)2020-10-22
Type: weaknessStatus: USABLE
Abstraction Type: Class


The product does not validate or incorrectly validates input that can affect the control flow or data flow of a program.

Extended Description

When software does not validate input properly, an attacker is able to craft the input in a form that is not expected by the rest of the application. This will lead to parts of the system receiving unintended input, which may result in altered control flow, arbitrary control of a resource, or arbitrary code execution.

Likelihood of Exploit: High

Applicable Platforms
Language Class: Language-independent

Time Of Introduction

  • Architecture and Design
  • Implementation

Related Attack Patterns

Common Consequences

ScopeTechnical ImpactNotes
DoS: crash / exit / restart
DoS: resource consumption (CPU)
DoS: resource consumption (memory)
An attacker could provide unexpected values and cause a program crash or excessive consumption of resources, such as memory and CPU.
Read memory
Read files or directories
An attacker could read confidential data if they are able to control resource references.
Modify memory
Execute unauthorized code or commands
An attacker could use malicious input to modify data or possibly alter control flow in unexpected ways, including arbitrary command execution.

Detection Methods

Automated Static Analysis
Some instances of improper input validation can be detected using automated static analysis.
A static analysis tool might allow the user to specify which application-specific methods or functions perform input validation; the tool might also have built-in knowledge of validation frameworks such as Struts. The tool may then suppress or de-prioritize any associated warnings. This allows the analyst to focus on areas of the software in which input validation does not appear to be present.
Except in the cases described in the previous paragraph, automated static analysis might not be able to recognize when proper input validation is being performed, leading to false positives - i.e., warnings that do not have any security consequences or require any code changes.
Manual Static Analysis
When custom input validation is required, such as when enforcing business rules, manual analysis is necessary to ensure that the validation is properly implemented.
Fuzzing techniques can be useful for detecting input validation errors. When unexpected inputs are provided to the software, the software should not crash or otherwise become unstable, and it should generate application-controlled error messages. If exceptions or interpreter-generated error messages occur, this indicates that the input was not detected and handled within the application logic itself.

Potential Mitigations

Architecture and Design
Input Validation
Libraries or Frameworks
Use an input validation framework such as Struts or the OWASP ESAPI Validation API. If you use Struts, be mindful of weaknesses covered by the CWE-101 category.
Architecture and Design
Identify and Reduce Attack Surface
Understand all the potential areas where untrusted inputs can enter your software: parameters or arguments, cookies, anything read from the network, environment variables, reverse DNS lookups, query results, request headers, URL components, e-mail, files, filenames, databases, and any external systems that provide data to the application. Remember that such inputs may be obtained indirectly through API calls.
Input Validation
Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a whitelist of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does.
When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue."
Do not rely exclusively on looking for malicious or malformed inputs (i.e., do not rely on a blacklist). A blacklist is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, blacklists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.
Architecture and Design
 For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.
Even though client-side checks provide minimal benefits with respect to server-side security, they are still useful. First, they can support intrusion detection. If the server receives input that should have been rejected by the client, then it may be an indication of an attack. Second, client-side error-checking can provide helpful feedback to the user about the expectations for valid input. Third, there may be a reduction in server-side processing time for accidental input errors, although this is typically a small savings.
 When your application combines data from multiple sources, perform the validation after the sources have been combined. The individual data elements may pass the validation step but violate the intended restrictions after they have been combined.
 Be especially careful to validate all input when invoking code that crosses language boundaries, such as from an interpreted language to native code. This could create an unexpected interaction between the language boundaries. Ensure that you are not violating any of the expectations of the language with which you are interfacing. For example, even though Java may not be susceptible to buffer overflows, providing a large argument in a call to native code might trigger an overflow.
 Directly convert your input type into the expected data type, such as using a conversion function that translates a string into a number. After converting to the expected data type, ensure that the input's values fall within the expected range of allowable values and that multi-field consistencies are maintained.
 Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180, CWE-181). Make sure that your application does not inadvertently decode the same input twice (CWE-174). Such errors could be used to bypass whitelist schemes by introducing dangerous inputs after they have been checked. Use libraries such as the OWASP ESAPI Canonicalization control.
Consider performing repeated canonicalization until your input does not change any more. This will avoid double-decoding and similar scenarios, but it might inadvertently modify inputs that are allowed to contain properly-encoded dangerous content.
 When exchanging data between components, ensure that both components are using the same character encoding. Ensure that the proper encoding is applied at each interface. Explicitly set the encoding you are using whenever the protocol allows you to do so.
 Use automated static analysis tools that target this type of weakness. Many modern techniques use data flow analysis to minimize the number of false positives. This is not a perfect solution, since 100% accuracy and coverage are not feasible.
 Use dynamic tools and techniques that interact with the software using large test suites with many diverse inputs, such as fuzz testing (fuzzing), robustness testing, and fault injection. The software's operation may slow down, but it should not become unstable, crash, or generate incorrect results.

CWE-116 and CWE-20 have a close association because, depending on the nature of the structured message, proper input validation can indirectly prevent special characters from changing the meaning of a structured message. For example, by validating that a numeric ID field should only contain the 0-9 characters, the programmer effectively prevents injection attacks.
However, input validation is not always sufficient, especially when less stringent data types must be supported, such as free-form text. Consider a SQL injection scenario in which a last name is inserted into a query. The name "O'Reilly" would likely pass the validation step since it is a common last name in the English language. However, it cannot be directly inserted into the database because it contains the "'" apostrophe character, which would need to be escaped or otherwise neutralized. In this case, stripping the apostrophe might reduce the risk of SQL injection, but it would produce incorrect behavior because the wrong name would be recorded.

Related CWETypeViewChain
CWE-20 ChildOf CWE-896 Category CWE-888  

Demonstrative Examples   (Details)

  1. The following example shows a PHP application in which the programmer attempts to display a user's birthday and homepage.
  2. The following example takes a user-supplied value to allocate an array of objects and then operates on the array. (Demonstrative Example Id DX-34)
  3. This example asks the user for a height and width of an m X n game board with a maximum dimension of 100 squares.
  4. This example demonstrates a shopping interaction in which the user is free to specify the quantity of items to be purchased and a total is calculated.
  5. This function attempts to extract a pair of numbers from a user-supplied string.

Observed Examples

  1. CVE-2008-5305 : Eval injection in Perl program using an ID that should only contain hyphens and numbers.
  2. CVE-2008-2223 : SQL injection through an ID that was supposed to be numeric.
  3. CVE-2008-3477 : lack of input validation in spreadsheet program leads to buffer overflows, integer overflows, array index errors, and memory corruption.
  4. CVE-2008-3843 : insufficient validation enables XSS
  5. CVE-2008-3174 : driver in security product allows code execution due to insufficient validation
  6. CVE-2007-3409 : infinite loop from DNS packet with a label that points to itself
  7. CVE-2006-6870 : infinite loop from DNS packet with a label that points to itself
  8. CVE-2008-1303 : missing parameter leads to crash
  9. CVE-2007-5893 : HTTP request with missing protocol version number leads to crash
  10. CVE-2006-6658 : request with missing parameters leads to information exposure
  11. CVE-2008-4114 : system crash with offset value that is inconsistent with packet size
  12. CVE-2006-3790 : size field that is inconsistent with packet size leads to buffer over-read
  13. CVE-2008-2309 : product uses a blacklist to identify potentially dangerous content, allowing attacker to bypass a warning
  14. CVE-2008-3494 : security bypass via an extra header
  15. CVE-2006-5462 : use of extra data in a signature allows certificate signature forging
  16. CVE-2008-3571 : empty packet triggers reboot
  17. CVE-2006-5525 : incomplete blacklist allows SQL injection
  18. CVE-2008-1284 : NUL byte in theme name cause directory traversal impact to be worse
  19. CVE-2008-0600 : kernel does not validate an incoming pointer before dereferencing it
  20. CVE-2008-1738 : anti-virus product has insufficient input validation of hooked SSDT functions, allowing code execution
  21. CVE-2008-1737 : anti-virus product allows DoS via zero-length field
  22. CVE-2008-3464 : driver does not validate input from userland to the kernel
  23. CVE-2008-2252 : kernel does not validate parameters sent in from userland, allowing code execution
  24. CVE-2008-2374 : lack of validation of string length fields allows memory consumption or buffer over-read
  25. CVE-2008-1440 : lack of validation of length field leads to infinite loop
  26. CVE-2008-1625 : lack of validation of input to an IOCTL allows code execution
  27. CVE-2008-3177 : zero-length attachment causes crash
  28. CVE-2007-2442 : zero-length input causes free of uninitialized pointer
  29. CVE-2008-5563 : crash via a malformed frame structure
  30. CVE-2008-5285 : infinite loop from a long SMTP request
  31. CVE-2008-3812 : router crashes with a malformed packet
  32. CVE-2008-3680 : packet with invalid version number leads to NULL pointer dereference
  33. CVE-2008-3660 : crash via multiple "." characters in file extension

For more examples, refer to CVE relations in the bottom box.

White Box Definitions

Black Box Definitions

Taxynomy Mappings

7 Pernicious Kingdoms  Input validation and representation
OWASP Top Ten 2004 A1
Unvalidated Input
CERT C Secure Coding ERR07-C
Prefer functions that support error checking over equivalent functions that don't
CERT C Secure Coding INT06-C
Use strtol() or a related function to convert a string token to an integer
CERT C Secure Coding MEM10-C
Define and use a pointer validation function
CERT C Secure Coding MSC08-C
Library functions should validate their parameters
Improper Input Handling
CERT C++ Secure Coding INT06-CPP
Use strtol() or a related function to convert a string token to an integer
CERT C++ Secure Coding MEM10-CPP
Define and use a pointer validation function
CERT C++ Secure Coding MSC08-CPP
Functions should validate their parameters


  1. Jim Manico .Input Validation with ESAPI - Very Important. 2008-08-15.
  2. OWASP .OWASP Enterprise Security API (ESAPI) Project.
  3. Joel Scambray Mike Shema Caleb Sima .Hacking Exposed Web Applications, Second Edition. McGraw-Hill. Section:'Input Validation Attacks'. 2006-06-05.
  4. Jeremiah Grossman .Input validation or output filtering, which is better?. 2007-01-30.
  5. Kevin Beaver .The importance of input validation. 2006-09-06.
  6. M. Howard D. LeBlanc .Writing Secure Code 2nd Edition. Microsoft. Section:'Chapter 10, "All Input Is Evil!" Page 341'. Published on 2002.
CVE    8371

© SecPod Technologies