0% found this document useful (0 votes)
88 views4 pages

CWE - CWE-20 - Improper Input Validation (4.14)

Uploaded by

vinaybhadeshiya6
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
88 views4 pages

CWE - CWE-20 - Improper Input Validation (4.14)

Uploaded by

vinaybhadeshiya6
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 4

Common Weakness Enumeration

A community-developed list of SW & HW weaknesses that


can become vulnerabilities

Home About ▼ CWE List ▼ Mapping ▼ Top-N Lists ▼ Community ▼ News ▼ Search

CWE-20: Improper Input Validation


Weakness ID: 20
Vulnerability Mapping: DISCOURAGED
Abstraction: Class

Mapping
View customized information: Conceptual Operational Complete Custom
Friendly

Description
The product receives input or data, but it does not validate or incorrectly validates that the input has the properties that are
required to process the data safely and correctly.
Extended Description
Input validation is a frequently-used technique for checking potentially dangerous inputs in order to ensure that the inputs are
safe for processing within the code, or when communicating with other components. 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.
Input validation is not the only technique for processing input, however. Other techniques attempt to transform potentially-
dangerous input into something safe, such as filtering (CWE-790) - which attempts to remove dangerous inputs - or
encoding/escaping (CWE-116), which attempts to ensure that the input is not misinterpreted when it is included in output to
another component. Other techniques exist as well (see CWE-138 for more examples.)
Input validation can be applied to:

raw data - strings, numbers, parameters, file contents, etc.


metadata - information about the raw data, such as headers or size

Data can be simple or structured. Structured data can be composed of many nested layers, composed of combinations of
metadata and raw data, with other simple or structured data.
Many properties of raw data or metadata may need to be validated upon entry into the code, such as:

specified quantities such as size, length, frequency, price, rate, number of operations, time, etc.
implied or derived quantities, such as the actual size of a file instead of a specified size
indexes, offsets, or positions into more complex data structures
symbolic keys or other elements into hash tables, associative arrays, etc.
well-formedness, i.e. syntactic correctness - compliance with expected syntax
lexical token correctness - compliance with rules for what is treated as a token
specified or derived type - the actual type of the input (or what the input appears to be)
consistency - between individual data elements, between raw data and metadata, between references, etc.
conformance to domain-specific rules, e.g. business logic
equivalence - ensuring that equivalent inputs are treated the same
authenticity, ownership, or other attestations about the input, e.g. a cryptographic signature to prove the source of the
data

Implied or derived properties of data must often be calculated or inferred by the code itself. Errors in deriving properties may
be considered a contributing factor to improper input validation.
Note that "input validation" has very different meanings to different people, or within different classification schemes. Caution
must be used when referencing this CWE entry or mapping to it. For example, some weaknesses might involve inadvertently
giving control to an attacker over an input when they should not be able to provide an input at all, but sometimes this is
referred to as input validation.
Finally, it is important to emphasize that the distinctions between input validation and output escaping are often blurred, and
developers must be careful to understand the difference, including how input validation is not always sufficient to prevent
vulnerabilities, especially when less stringent data types must be supported, such as free-form text. Consider a SQL injection
scenario in which a person's 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, this valid name cannot be directly inserted into the database
because it contains the "'" apostrophe character, which would need to be escaped or otherwise transformed. In this case,
removing the apostrophe might reduce the risk of SQL injection, but it would produce incorrect behavior because the wrong
name would be recorded.
Relationships
Relevant to the view "Research Concepts" (CWE-1000)
Nature Type ID Name
ChildOf 707 Improper Neutralization
ParentOf 179 Incorrect Behavior Order: Early Validation
ParentOf 622 Improper Validation of Function Hook Arguments
ParentOf 1173 Improper Use of Validation Framework
ParentOf 1284 Improper Validation of Specified Quantity in Input
ParentOf 1285 Improper Validation of Specified Index, Position, or Offset in Input
ParentOf 1286 Improper Validation of Syntactic Correctness of Input
ParentOf 1287 Improper Validation of Specified Type of Input
ParentOf 1288 Improper Validation of Consistency within Input
ParentOf 1289 Improper Validation of Unsafe Equivalence in Input
PeerOf 345 Insufficient Verification of Data Authenticity
CanPrecede 22 Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
CanPrecede 41 Improper Resolution of Path Equivalence
CanPrecede 74 Improper Neutralization of Special Elements in Output Used by a Downstream
Component ('Injection')
CanPrecede 119 Improper Restriction of Operations within the Bounds of a Memory Buffer
CanPrecede 770 Allocation of Resources Without Limits or Throttling

Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (CWE-1003)
Relevant to the view "Architectural Concepts" (CWE-1008)
Relevant to the view "Seven Pernicious Kingdoms" (CWE-700)
Memberships

Nature Type ID Name


MemberOf 635 Weaknesses Originally Used by NVD from 2008 to 2016
MemberOf 722 OWASP Top Ten 2004 Category A1 - Unvalidated Input
MemberOf 738 CERT C Secure Coding Standard (2008) Chapter 5 - Integers (INT)
MemberOf 742 CERT C Secure Coding Standard (2008) Chapter 9 - Memory Management (MEM)
MemberOf 746 CERT C Secure Coding Standard (2008) Chapter 13 - Error Handling (ERR)
MemberOf 747 CERT C Secure Coding Standard (2008) Chapter 14 - Miscellaneous (MSC)
MemberOf 751 2009 Top 25 - Insecure Interaction Between Components
MemberOf 872 CERT C++ Secure Coding Section 04 - Integers (INT)
MemberOf 876 CERT C++ Secure Coding Section 08 - Memory Management (MEM)
MemberOf 883 CERT C++ Secure Coding Section 49 - Miscellaneous (MSC)
MemberOf 994 SFP Secondary Cluster: Tainted Input to Variable
MemberOf 1003 Weaknesses for Simplified Mapping of Published Vulnerabilities
MemberOf 1005 7PK - Input Validation and Representation
MemberOf 1163 SEI CERT C Coding Standard - Guidelines 09. Input Output (FIO)
MemberOf 1200 Weaknesses in the 2019 CWE Top 25 Most Dangerous Software Errors
MemberOf 1337 Weaknesses in the 2021 CWE Top 25 Most Dangerous Software Weaknesses
MemberOf 1347 OWASP Top Ten 2021 Category A03:2021 - Injection
MemberOf 1350 Weaknesses in the 2020 CWE Top 25 Most Dangerous Software Weaknesses
MemberOf 1382 ICS Operations (& Maintenance): Emerging Energy Technologies
MemberOf 1387 Weaknesses in the 2022 CWE Top 25 Most Dangerous Software Weaknesses
MemberOf 1406 Comprehensive Categorization: Improper Input Validation
MemberOf 1425 Weaknesses in the 2023 CWE Top 25 Most Dangerous Software Weaknesses

Vulnerability Mapping Notes

Usage: DISCOURAGED (this CWE ID should not be used to map to real-world vulnerabilities)

Reason: Frequent Misuse

Rationale:

CWE-20 is commonly misused in low-information vulnerability reports when lower-level CWEs could be used instead, or
when more details about the vulnerability are available [REF-1287]. It is not useful for trend analysis. It is also a level-1
Class (i.e., a child of a Pillar).
Comments:

Consider lower-level children such as Improper Use of Validation Framework (CWE-1173) or improper validation involving
specific types or properties of input such as Specified Quantity (CWE-1284); Specified Index, Position, or Offset (CWE-
1285); Syntactic Correctness (CWE-1286); Specified Type (CWE-1287); Consistency within Input (CWE-1288); or Unsafe
Equivalence (CWE-1289).
Suggestions:

CWE-ID Comment

CWE-1284 Specified Quantity


CWE-1285 Specified Index, Position, or Offset
CWE-1286 Syntactic Correctness
CWE-1287 Specified Type
CWE-1288 Consistency within Input
CWE-1289 Unsafe Equivalence
CWE-116 Improper Encoding or Escaping of Output

Notes
Relationship
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.
Terminology
The "input validation" term is extremely common, but it is used in many different ways. In some cases its usage can
obscure the real underlying weakness or otherwise hide chaining and composite relationships.
Some people use "input validation" as a general term that covers many different neutralization techniques for ensuring
that input is appropriate, such as filtering, canonicalization, and escaping. Others use the term in a more narrow
context to simply mean "checking if an input conforms to expectations without changing it." CWE uses this more
narrow interpretation.
Taxonomy Mappings

Mapped Taxonomy Name Node ID Fit Mapped Node Name


7 Pernicious Kingdoms Input validation and representation
OWASP Top Ten 2004 A1 CWE More Unvalidated Input
Specific
CERT C Secure Coding ERR07-C Prefer functions that support error checking over
equivalent functions that don't
CERT C Secure Coding FIO30-C CWE More Exclude user input from format strings
Abstract
CERT C Secure Coding MEM10-C Define and use a pointer validation function
WASC 20 Improper Input Handling
Software Fault Patterns SFP25 Tainted input to variable

Related Attack Patterns

CAPEC-ID Attack Pattern Name


CAPEC-10 Buffer Overflow via Environment Variables
CAPEC-101 Server Side Include (SSI) Injection
CAPEC-104 Cross Zone Scripting
CAPEC-108 Command Line Execution through SQL Injection
CAPEC-109 Object Relational Mapping Injection
CAPEC-110 SQL Injection through SOAP Parameter Tampering
CAPEC-120 Double Encoding
CAPEC-13 Subverting Environment Variable Values
CAPEC-135 Format String Injection
CAPEC-136 LDAP Injection
CAPEC-14 Client-side Injection-induced Buffer Overflow
CAPEC-153 Input Data Manipulation
CAPEC-182 Flash Injection
CAPEC-209 XSS Using MIME Type Mismatch
CAPEC-22 Exploiting Trust in Client
CAPEC-23 File Content Injection
CAPEC-230 Serialized Data with Nested Payloads
CAPEC-231 Oversized Serialized Data Payloads
CAPEC-24 Filter Failure through Buffer Overflow
CAPEC-250 XML Injection
CAPEC-261 Fuzzing for garnering other adjacent user/sensitive data
CAPEC-267 Leverage Alternate Encoding
CAPEC-28 Fuzzing
CAPEC-3 Using Leading 'Ghost' Character Sequences to Bypass Input Filters
CAPEC-31 Accessing/Intercepting/Modifying HTTP Cookies
CAPEC-42 MIME Conversion
CAPEC-43 Exploiting Multiple Input Interpretation Layers
CAPEC-45 Buffer Overflow via Symbolic Links
CAPEC-46 Overflow Variables and Tags
CAPEC-47 Buffer Overflow via Parameter Expansion
CAPEC-473 Signature Spoof
CAPEC-52 Embedding NULL Bytes
CAPEC-53 Postfix, Null Terminate, and Backslash
CAPEC-588 DOM-Based XSS
CAPEC-63 Cross-Site Scripting (XSS)
CAPEC-64 Using Slashes and URL Encoding Combined to Bypass Validation Logic
CAPEC-664 Server Side Request Forgery
CAPEC-67 String Format Overflow in syslog()
CAPEC-7 Blind SQL Injection
CAPEC-71 Using Unicode Encoding to Bypass Validation Logic
CAPEC-72 URL Encoding
CAPEC-73 User-Controlled Filename
CAPEC-78 Using Escaped Slashes in Alternate Encoding
CAPEC-79 Using Slashes in Alternate Encoding
CAPEC-8 Buffer Overflow in an API Call
CAPEC-80 Using UTF-8 Encoding to Bypass Validation Logic
CAPEC-81 Web Server Logs Tampering
CAPEC-83 XPath Injection
CAPEC-85 AJAX Footprinting
CAPEC-88 OS Command Injection
CAPEC-9 Buffer Overflow in Local Command-Line Utilities

Content History

Submissions
Submission Date Submitter Organization
2006-07-19 7 Pernicious Kingdoms
(CWE Draft 3, 2006-07-19)
Modifications
Previous Entry Names

You might also like