Data Validation (DVL) Class
We define Data Validation Bugs (DVL) as follows:
Data are validated (syntax check) or sanitized (escape, filter, repair) improperly.
Fig. 1 depicts DVL causes, attributes and consequences.
Data Validation Bugs (DVL) Class
- click on image for detailed view.
The DVL operations are: Validate and Sanitize. They reflect the improper check and modification of data syntax.
||Check data syntax (proper form/grammar) in order to accept (and possibly sanitize) or reject it. Includes checking for missing symbols/elements.
||Modify data (neutralize/escape, filter/remove, repair/add symbols) in order to make it valid (well-formed).
The graph of causes shows that there are three main causes for data validation bugs: Improper Operation,
Improper Data, and Improper Policy.
||The operation is absent.
||Missing data sanitization.
||There is a bug in the implementation of the operation (incl. how it checks against a policy).
- Using not equal to (!=) when
comparing to safelist values.
- Using greater than (>) when
checking for upper range.
||Accepts bad data.
- Permissive safelist or regular
- Incomplete denylist.
||Rejects good data.
||Over-restrictive denylist or regu- lar expression.
||Unintentionally modified data due to a previous weakness (e.g., with a decompress or a decrypt operation) that if not sanitized would end-up as invalid data for next weakness.
||Maliciously modified data due to a previous weakness (e.g., with a deserialize, authorize, or crypto verify operation) that would lead to injection error.
||Unintentionally modified policy due to a previous weakness (e.g., with a decompress operation).
||Maliciously modified policy due to a previous weakness (e.g., with an authorize operation).
The graph of consequences shows Improper Data for Next Operation and Injection Error as consequences.
|Improper Data for Next Operation
||Data with harmed syntax due to sanitization errors.
||Malicious insertion of condition parts (e.g., or 1==1) or entire commands (e.g., drop table) into an input used to construct a database query.
- SQL Injection
- No SQL Injection
- XPath Injection
- XQuery Injection
- LDAP Injection
||Malicious insertion of new commands into the input to a command that is sent to an operat- ing system (OS) or to a server.
- OS Command Injection
- Regular Expression Injection
- IMAP/SMTP Command Injection
- Object Injection (JSON server side)
|Source Code Injection
||Malicious insertion of new code (incl. with <> elements) into input used as part of an exe- cuting application code.
- Cross Site Scripting (XSS)
- CSS Injection
- Eval Injection
- EL Injection
- JSON Injection (Client or Server Side)
||Malicious insertion of data (e.g., with & pa- rameter separator) into input used as param- eter/argument in other parts of code.
- Argument Injection
- Format String Injection
- Email Injection
- HTTP Header Injection (incl.
Server Header Injection)
- Reflection Injection
- Flash Injection
- CRLF Injection (incl. HTTP
||Malicious insertion of data (e.g., with .. and / or with file entries) into input used to ac- cess/modify files or as file content.
- CSV, Temp, etc. File Injection
- Log Entry Injection
- XML Injection
- CRLF Injection (incl. in as in
log entry files)
- Relative Path Traversal
- Absolute Path Traversal
The attributes of DVL are:
||Policy based on a set of known good content.
||Policy based on a set of known bad content; helps reject outright maliciously malformed data.
||Policy based on syntax format (e.g., defined via regular expression).
||Policy based on allowed number of characters in data. Note that this is not about the data value as size of an object.
||The operation is in programmer’s code – in the application itself.
||The operation is in a third party library.
||The operation is in the standard library for a particular programming language.
||The operation is in the tool that allows execution or creates executable (compiler, assembler,
||The bugged code runs in an environment with access control policy with limited (local user) permission.
||The bugged code runs in an environment with access control policy with unlimited (admin user) permission.
||The bugged code runs in an environment with-out privilege control. Usually, the program is the only
software running and has total access to the hardware.
||Data comes from user interface (e.g., text field).
||Data comes from permanent storage (e.g., file, database on a storage device).
||Data comes from volatile storage (e.g., RAM, cache memory).
||Data comes via network (e.g., connecting analog device or another computer).
A site for input/output check bugs is any part of the code that should check and sanitize data syntax or check and correct data semantics.
Application examples are provided here.