Weakness (CWE)
CWE-829: Inclusion of Functionality from Untrusted Control Sphere
The product imports, requires, or includes executable functionality (such as a library) from a source that is outside of the intended control sphere.
How to prevent it (8 mitigations)
-
Architecture and Design
Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid [REF-1482].
-
Architecture and Design
When the set of acceptable objects, such as filenames or URLs, is limited or known, create a mapping from a set of fixed input values (such as numeric IDs) to the actual filenames or URLs, and reject all other inputs.
For example, ID 1 could map to "inbox.txt" and ID 2 could map to "profile.txt". Features such as the ESAPI AccessReferenceMap [REF-45] provide this capability.
-
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.
-
Architecture and Design, Operation
Run the code in a "jail" or similar sandbox environment that enforces strict boundaries between the process and the operating system. This may effectively restrict which files can be accessed in a particular directory or which commands can be executed by the software.
OS-level examples include the Unix chroot jail, AppArmor, and SELinux. In general, managed code may provide some protection. For example, java.io.FilePermission in the Java SecurityManager allows the software to specify restrictions on file operations.
This may not be a feasible solution, and it only limits the impact to the operating system; the rest of the application may still be subject to compromise.
Be careful to avoid CWE-243 and other weaknesses related to jails.
-
Architecture and Design, Operation
Run your code using the lowest privileges that are required to accomplish the necessary tasks [REF-76]. If possible, create isolated accounts with limited privileges that are only used for a single task. That way, a successful attack will not immediately give the attacker access to the rest of the software or its environment. For example, database applications rarely need to run as the database administrator, especially in day-to-day operations.
-
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.
When validating filenames, use stringent allowlists that limit the character set to be used. If feasible, only allow a single "." character in the filename to avoid weaknesses such as CWE-23, and exclude directory separators such as "/" to avoid CWE-36. Use a list of allowable file extensions, which will help to avoid CWE-434.
Do not rely exclusively on a filtering mechanism that removes potentially dangerous characters. This is equivalent to a denylist, which may be incomplete (CWE-184). For example, filtering "/" is insufficient protection if the filesystem also supports the use of "\" as a directory separator. Another possible error could occur when the filtering is applied in a way that still produces dangerous data (CWE-182). For example, if "../" sequences are removed from the ".../...//" string in a sequential fashion, two instances of "../" would be removed from the original string, but the remaining characters would still form the "../" string.
-
Architecture and Design, Operation
Store library, include, and utility files outside of the web document root, if possible. Otherwise, store them in a separate directory and use the web server's access control capabilities to prevent attackers from directly requesting them. One common practice is to define a fixed constant in each calling program, then check for the existence of the constant in the library/include file; if the constant does not exist, then the file was directly requested, and it can exit immediately.
This significantly reduces the chance of an attacker being able to bypass any protection mechanisms that are in the base program but not in the include files. It will also reduce the attack surface.
-
Architecture and Design, Implementation
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.
Many file inclusion problems occur because the programmer assumed that certain inputs could not be modified, especially for cookies and URL components.
Source: MITRE CWE-829
347 results · Feed
-
Medium 6.6
Gradle's dependency verification can ignore checksum verification when signature verification cannot be performed
Gradle is a build tool. Dependency verification is a security feature in Gradle Build Tool that was introduced to allow validation of external dependencies either through their checksum or cryptographic signatures. In versions 6.2 through 7.4.2, there are som…
-
Critical 10.0
In Eclipse p2, installable units are able to alter the Eclipse Platform installation and the local machine via touchpoi…
-
Medium 5.3
Anonymous user cache poisoning in discourse
Discourse is an open source platform for community discussion. In affected versions an attacker can poison the cache for anonymous (i.e. not logged in) users, such that the users are shown the crawler view of the site instead of the HTML page. This can lead t…
-
Critical 10.0
ICSA-22-090-05 Rockwell Automation Logix Controllers
An attacker with the ability to modify a user program may change user program code on some ControlLogix, CompactLogix, and GuardLogix Control systems. Studio 5000 Logix Designer writes user-readable program code to a separate location than the executed compil…
-
Medium 5.3
Improper Locking in JetBrains Kotlin
In JetBrains Kotlin before 1.6.0, it was not possible to lock dependencies for Multiplatform Gradle Projects.
-
High 7.5
Dependency verification bypass in Gradle
Gradle is a build tool with a focus on build automation and support for multi-language development. In some cases, Gradle may skip that verification and accept a dependency that would otherwise fail the build as an untrusted external artifact. This occurs whe…
-
Medium 5.8
Intent URI permissions manipulation in nextcloud news-android
nextcloud news-android is an Android client for the Nextcloud news/feed reader app. In affected versions the Nextcloud News for Android app has a security issue by which a malicious application installed on the same device can send it an arbitrary Intent that…
-
Critical 9.3
Preview generation used third-party library not suited for user-generated content in Nextcloud server
Nextcloud server is an open source, self hosted personal cloud. Nextcloud supports rendering image previews for user provided file content. For some image types, the Nextcloud server was invoking a third-party library that wasn't suited for untrusted user-sup…
-
High 8.1
Inclusion of Functionality from Untrusted Control Sphere in PHPMailer/PHPMailer
PHPMailer 6.4.1 and earlier contain a vulnerability that can result in untrusted code being called (if such code is injected into the host project's scope by other means). If the $patternselect parameter to validateAddress() is set to 'php' (the default, defi…
-
High 8.0CVE-2021-29427 Public exploit
Repository content filters do not work in Settings pluginManagement
In Gradle from version 5.1 and before version 7.0 there is a vulnerability which can lead to information disclosure and/or dependency poisoning. Repository content filtering is a security control Gradle introduced to help users specify what repositories are u…
-
Medium 6.1
Command Injection in @theia/messages
In Eclipse Theia versions up to and including 0.16.0, in the notification messages there is no HTML escaping, so Javascript code can run.
-
High 7.2
Moodle Arbitrary PHP code execution by site admins via Shibboleth configuration
It was found in Moodle before version 3.10.1, 3.9.4, 3.8.7 and 3.5.16 that it was possible for site administrators to execute arbitrary PHP scripts via a PHP include used during Shibboleth authentication.
-
Medium 6.5
Inclusion of Functionality from Untrusted Control Sphere in CKEditor 4
It was possible to execute a ReDoS-type attack inside CKEditor 4 before 4.16 by persuading a victim to paste crafted URL-like text into the editor, and then press Enter or Space (in the Autolink plugin).
-
Medium 4.8CVE-2020-5295 Public exploit
Local File read vulnerability in OctoberCMS
In OctoberCMS (october/october composer package) versions from 1.0.319 and before 1.0.466, an attacker can exploit this vulnerability to read local files of an October CMS server. The vulnerability is only exploitable by an authenticated backend user with the…
-
Critical 9.8
Server-Side Request Forgery and Inclusion of Functionality from Untrusted Control Sphere in jsreport
An unintended require and server-side request forgery vulnerabilities in jsreport version 2.5.0 and earlier allow attackers to execute arbitrary code.
-
High 8.8
Magento remote code execution vulnerability
A remote code execution vulnerability exists in Magento 2.2 prior to 2.2.10, Magento 2.3 prior to 2.3.3 or 2.3.2-p1. An authenticated user with privileges to modify product catalogs can trigger PHP file inclusion through a crafted XML file that specifies prod…
-
High 8.1
High severity vulnerability that affects generator-jhipster
## Generated code uses repository configuration that downloads over HTTP instead of HTTPS ### Impact Gradle users were using the http://repo.spring.io/plugins-release repositories in plain HTTP, and not HTTPS, so a man-in-the-middle attack was possible at bui…
-
High 7.5
Unintended Require in larvitbase-api
An unintended require vulnerability in <v0.5.5 larvitbase-api may allow an attacker to load arbitrary non-production code (JavaScript file).
-
Critical 9.8
paranoid2 gem Code backdoor
The paranoid2 gem 1.1.6 for Ruby, as distributed on RubyGems.org, included a code-execution backdoor inserted by a third party. The current version, without this backdoor, is 1.1.5.
-
Unscored —
In Eclipse Buildship versions prior to 3.1.1, the build files indicate that this project is resolving dependencies over…
-
Medium 5.9
Insecure Default Configuration in tesseract.js
Versions of `tesseract.js` prior to 1.0.19 default to using a third-party proxy. Requests may be proxied through `crossorigin.me` which clearly states is not suitable for production use. This may lead to instability and privacy violations. ## Recommendation U…
-
High 8.1
Potentially compromised builds
All Xtext & Xtend versions prior to 2.18.0 were built using HTTP instead of HTTPS file transfer and thus the built artifacts may have been compromised.
-
High 8.1
Eclipse Vorto resolved Maven build artifacts for the Xtext project over HTTP instead of HTTPS
Eclipse Vorto versions prior to 0.11 resolved Maven build artifacts for the Xtext project over HTTP instead of HTTPS. Any of these dependent artifacts could have been maliciously compromised by a MITM attack. Hence produced build artifacts of Vorto might be i…
-
High 8.1
Cleartext Transmission of Sensitive Information, Inclusion of Functionality from Untrusted Control Sphere , and Download of Code Without Integrity Check in Eclipse hawkBit
Eclipse hawkBit versions prior to 0.3.0M2 resolved Maven build artifacts for the Vaadin based UI over HTTP instead of HTTPS. Any of these dependent artifacts could have been maliciously compromised by a MITM attack. Hence produced build artifacts of hawkBit m…
-
Medium 5.9
Moderate severity vulnerability that affects org.springframework:spring-core
Spring Framework, versions 5.0.x prior to 5.0.7 and 4.3.x prior to 4.3.18 and older unsupported versions, allows web applications to enable cross-domain requests via JSONP (JSON with Padding) through AbstractJsonpResponseBodyAdvice for REST controllers and Ma…
-
High 7.3CVE-2018-1122 Public exploit
procps-ng before version 3.3.15 is vulnerable to a local privilege escalation in top. If a user runs top with HOME unse…
-
High 8.1
Drupal Remote code execution
A 3rd party development library including with Drupal 8 development dependencies is vulnerable to remote code execution. This is mitigated by the default .htaccess protection against PHP execution, and the fact that Composer development dependencies aren't no…