Weakness (CWE)
CWE-20: Improper Input Validation
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.
How to prevent it (8 mitigations)
-
Architecture and Design
Consider using language-theoretic security (LangSec) techniques that characterize inputs using a formal language and build "recognizers" for that language. This effectively requires parsing to be a distinct layer that effectively enforces a boundary between raw input and internal data representations, instead of allowing parser code to be scattered throughout the program, where it could be subject to errors or inconsistencies that create weaknesses. [REF-1109] [REF-1110] [REF-1111]
-
Architecture and Design
Use an input validation framework such as Struts or the OWASP ESAPI Validation API. Note that using a framework does not automatically address all input validation problems; be mindful of weaknesses that could arise from misusing the framework itself (CWE-1173).
-
Architecture and Design, Implementation
Understand all the potential areas where untrusted inputs can enter the product, including but not limited to: 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.
-
Implementation
Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list 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. This 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, denylists 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.
-
Implementation
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.
-
Implementation
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.
-
Implementation
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.
Source: MITRE CWE-20
297 results · Clear filters · Feed
-
Low 3.3
Cisco Webex Network Recording Player and Cisco Webex Player Denial of Service Vulnerability
A vulnerability in Cisco Webex Network Recording Player and Cisco Webex Player for Microsoft Windows could allow an attacker to cause a process crash resulting in a Denial of service (DoS) condition for the player application on an affected system. The vulner…
-
Low 3.9
ABB PB610 HMIStudio crashes after launching an empty *.JPR application file
Due to a lack of file length check, the HMIStudio component of ABB PB610 Panel Builder 600 versions 2.8.0.424 and earlier crashes when trying to load an empty *.JPR application file. An attacker with access to the file system might be able to cause applicatio…
-
Low 3.3
Improper Input Validation in Firefly III
Firefly III 4.7.17.3 is vulnerable to local file enumeration. An attacker can enumerate local files due to the lack of protocol scheme sanitization, such as for file:/// URLs. This is related to fints_url to import/job/configuration, and import/create/fints.
-
Low 2.7
Improper Input Validation and Missing Authentication for Critical Function in Apache ActiveMQ
It was found that the Apache ActiveMQ client before 5.14.5 exposed a remote shutdown command in the ActiveMQConnection class. An attacker logged into a compromised broker could use this flaw to achieve denial of service on a connected client.
-
Low 3.1
An input validation flaw was found in the way OpenShift 3 handles requests for images. A user, with a copy of the manif…
-
Low 3.1
Jenkins Resource Disposer Plugin allows attacker to stop tracking specified resource
A data modification vulnerability exists in Jenkins Resource Disposer Plugin 0.11 and earlier in AsyncResourceDisposer.java that allows attackers to stop tracking a resource.
-
Low 2.6
It was discovered that the Dashbuilder login page as used in Red Hat JBoss BPM Suite before 6.4.2 and Red Hat JBoss Dat…
-
Low 3.5
An input validation error was found in Red Hat Certificate System's handling of client provided certificates before 8.1…
-
Low 2.2
Improper Input Validation in ansible
An input validation vulnerability was found in Ansible's mysql_user module before 2.2.1.0, which may fail to correctly change a password in certain circumstances. Thus the previous password would still be active when it should have been changed.
-
Low 3.7
Dovecot before version 2.2.29 is vulnerable to a denial of service. When 'dict' passdb and userdb were used for user au…
-
Low 2.2
Improper Input Validation in Jenkins
The Jenkins 2.73.1 and earlier, 2.83 and earlier default form control for passwords and other secrets, <f:password/>, supports form validation (e.g. for API keys). The form validation AJAX requests were sent via GET, which could result in secrets being logged…
-
Low 3.7
Phusion Passenger allows remote attackers to spoof headers
agent/Core/Controller/SendRequest.cpp in Phusion Passenger before 4.0.60 and 5.0.x before 5.0.22, when used in Apache integration mode or in standalone mode without a filtering proxy, allows remote attackers to spoof headers passed to applications by using an…
-
Low —
SMTP Injection in PHPMailer
Multiple CRLF injection vulnerabilities in PHPMailer before 5.2.14 allow attackers to inject arbitrary SMTP commands via CRLF sequences in an (1) email address to the validateAddress function in class.phpmailer.php or (2) SMTP command to the sendCommand funct…
-
Low —
Jenkins Vulnerable to Denial of Service (DoS)
Jenkins before 1.600 and LTS before 1.596.1 allows remote authenticated users to cause a denial of service (improper plug-in and tool installation) via crafted update center data.
-
Low 2.1
Schneider Electric Wonderware Input Validation
Schneider Electric Wonderware Information Server (WIS) Portal 4.0 SP1 through 5.5 allows remote attackers to read arbitrary files or cause a denial of service via an XML external entity declaration in conjunction with an entity reference, related to an XML Ex…
-
Low —
Jenkins affected by Open Redirect Vulnerability
Open redirect vulnerability in Jenkins before 1.491, Jenkins LTS before 1.480.1, and Jenkins Enterprise 1.424.x before 1.424.6.13, 1.447.x before 1.447.4.1, and 1.466.x before 1.466.10.1 allows remote attackers to redirect users to arbitrary web sites and con…
-
Low —
OpenStack Nova Scheduler denial of service through scheduler_hints
The Nova scheduler in OpenStack Compute (Nova) Folsom (2012.2) and Essex (2012.1), when DifferentHostFilter or SameHostFilter is enabled, allows remote authenticated users to cause a denial of service (excessive database lookup calls and server hang) via a re…