CWE Reference

CWE-669: Incorrect Resource Transfer Between Spheres

Official CWE-669 CWE context with Glexia analysis, remediation guidance, related CVEs, and ATT&CK context.

Release 4.20weaknessDraft

Glexia's Take

CWE-669: Incorrect Resource Transfer Between Spheres

Incorrect Resource Transfer Between Spheres represents a recurring weakness pattern that can create exploitable paths when design, validation, or implementation controls are missing.

Executive Impact

Confidentiality,Integrity: Read Application Data,Modify Application Data,Unexpected State

Developer Pattern

CWE-669 is the kind of defect developers can usually prevent with explicit validation, safer framework defaults, and tests that exercise hostile input or unsafe state transitions.

Confidence

high confidence from CWE-669, 4.20.

Official CWE Definition

CWE-669: Incorrect Resource Transfer Between Spheres

The product does not properly transfer a resource/behavior to another sphere, or improperly imports a resource/behavior from another sphere, in a manner that provides unintended control over that resource.

Type: weakness
Abstraction: Class
Status: Draft
Source: MITRE CWE definition

Developer And Remediation Guidance

How teams prevent and detect this weakness

Causes

The following code demonstrates the unrestricted upload of a file with a Java servlet and a path traversal vulnerability. The action attribute of an HTML form is sending the upload file request to the Java servlet. When submitted the Java servlet's doPost method will receive the request, extract the name of the file from the Http request header, read the file contents from the request and output the file to the local upload directory.,This code does not perform a check on the type of the file being uploaded (CWE-434). This could allow an attacker to upload any executable file or other file with malicious code.,Additionally, the creation of the BufferedWriter object is subject to relative path traversal (CWE-23). Since the code does not check the filename that is provided in the header, an attacker can use "../" sequences to write to files outside of the intended directory. Depending on the executing environment, the attacker may be able to specify arbitrary files to write to, leading to a wide variety of consequences, from code execution, XSS (CWE-79), or system crash.
This code includes an external script to get database credentials, then authenticates a user against the database, allowing access to the application. This code does not verify that the external domain accessed is the intended one. An attacker may somehow cause the external domain name to resolve to an attack server, which would provide the information for a false database. The attacker may then steal the usernames and encrypted passwords from real user login attempts, or simply allow themself to access the application without a real user account.,This example is also vulnerable to an Adversary-in-the-Middle AITM (CWE-300) attack.
This code either generates a public HTML user information page or a JSON response containing the same user information. The programmer is careful to not display the user's e-mail address when displaying the public HTML page. However, the e-mail address is not removed from the JSON response, exposing the user's e-mail address.

Remediation

Use safe APIs
Centralize the control
Add regression tests
Review logs and telemetry for attempted abuse

Detection

Code review
SAST
DAST
Focused regression tests

Mappings

Related CVEs, CWEs, and ATT&CK context

Related CWEs

Related CVEs

Related CVE mappings appear after CVE records are cross-indexed.

Open CWE CVE mapping

ATT&CK Relevance

ATT&CK relevance is shown only when reviewed or responsibly inferred.