logo

Incorrect Resource Transfer Between Spheres

Draft Class
Structure: Simple
Description

This vulnerability occurs when an application incorrectly moves or shares a resource (like data, permissions, or functionality) between different trust boundaries or security contexts. This improper transfer can give unintended actors control over that resource, leading to security breaches.

Extended Description

Think of your application as having separate, secure zones—like a user interface (client-side), a backend server, and an administrative panel. Each zone has its own level of trust and permitted actions. This weakness happens when a resource, such as a user session, a file handle, or an administrative function, is mistakenly allowed to cross from a less-trusted zone into a more-trusted one, or is imported without proper validation. For example, a web application might incorrectly accept and process a user-supplied file path as if it originated from the secure server itself, allowing an attacker to access sensitive system files. To prevent this, developers must enforce strict boundaries between different spheres of control. Always validate and sanitize any resource that moves between contexts, explicitly check the origin of requests, and implement the principle of least privilege so that resources can only be used within their intended security scope. Auditing data flows and trust transitions in your architecture is key to identifying and fixing these improper transfers.
Common Consequences 1
Scope: ConfidentialityIntegrity

Impact: Read Application DataModify Application DataUnexpected State
Demonstrative Examples 3

ID : DX-22

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.

Code Example:

Good
HTML
html
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.

Code Example:

Bad
Java
java
This code does not perform a check on the type of the file being uploaded (Unrestricted Upload of File with Dangerous Type). 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 (Relative Path Traversal). 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 (Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')), or system crash.

ID : DX-219

This code includes an external script to get database credentials, then authenticates a user against the database, allowing access to the application.

Code Example:

Bad
PHP


//assume the password is already encrypted, avoiding CWE-312*


php


php
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 (Channel Accessible by Non-Endpoint) attack.
ID : DX-220
This code either generates a public HTML user information page or a JSON response containing the same user information.
Code Example:
Bad
PHP


// API flag, output JSON if set*
$json = $_GET['json']
$username = $_GET['user']
if(!$json)
{
```
$record = getUserRecord($username);
foreach($record as $fieldName => $fieldValue)
{
if($fieldName == "email_address") {


php
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.
  
Observed Examples 3
CVE-2021-22909Chain: router's firmware update procedure uses curl with "-k" (insecure) option that disables certificate validation (Improper Certificate Validation), allowing adversary-in-the-middle (AITM) compromise with a malicious firmware image (Download of Code Without Integrity Check).
CVE-2023-5227PHP-based FAQ management app does not check the MIME type for uploaded images
CVE-2005-0406Some image editors modify a JPEG image, but the original EXIF thumbnail image is left intact within the JPEG. (Also an interaction error).
   
  
      
 
 
Modes of Introduction 
 
 
 
 
 
  Architecture and Design  
 
  Implementation  
 
  Operation  
 
 
 
          
 
 
Related Weaknesses 
 
 
 
 
  ChildOf:
 Improper Control of a Resource Through its Lifetime (CWE-664)