COMMON WEAKNESS ENUMERATIONDraft

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.

Abstraction

Class

Structure

Simple

Likelihood of Exploit

Medium

Understand the problem

What is the problem?

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.

Root cause

How and when does the problem arise?

Lifecycle phase

Architecture and Design

Lifecycle phase

Implementation

REALIZATION: This weakness is caused during implementation of an architectural security tactic.

Lifecycle phase

Operation

A "control sphere" is a set of resources and behaviors that are accessible to a single actor, or a group of actors. A product's security model will typically define multiple spheres, possibly implicitly. For example, a server might define one sphere for "administrators" who can create new user accounts with subdirectories under /home/server/, and a second sphere might cover the set of users who can create or delete files within their own subdirectories. A third sphere might be "users who are authenticated to the operating system on which the product is installed." Each sphere has different sets of actors and allowable behaviors.

Risk

What does successful exploitation lead to?

Read Application DataModify Application DataUnexpected State

Affected security scopes: Confidentiality, Integrity

Defence

How is it prevented and fixed?

  • Follow secure coding guidelines for input handling and boundary checking.
  • Enforce strict security reviews and automated static analysis (SAST) checks.
CWE-669: Common Weakness Enumeration Entry CWE-669 · DayBreach Sözlük · DayBreach