The software does not properly manage privileges while it is switching between different contexts that have different privileges or spheres of control.
Time of Introduction
Architecture and Design
Implementation
Operation
Applicable Platforms
Languages
All
Common Consequences
Scope
Effect
Access Control
Technical Impact: Gain privileges / assume
identity
A user can assume the identity of another user with separate
privileges in another context. This will give the user unauthorized
access that may allow them to acquire the access information of other
users.
Run callback in different security context after
it has been changed from untrusted to trusted. * note that "context switch
before actions are completed" is one type of problem that happens
frequently, espec. in browsers.
Potential Mitigations
Phases: Architecture and Design; Operation
Very carefully manage the setting, management, and handling of
privileges. Explicitly manage trust zones in the software.
Phases: Architecture and Design; Operation
Strategy: Environment Hardening
Run your code using the lowest privileges that are required to accomplish the necessary tasks [R.270.1]. 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.
Phase: Architecture and Design
Strategy: Separation of Privilege
Consider following the principle of separation of privilege. Require
multiple conditions to be met before permitting access to a system
resource.
More information is available — Please select a different filter.
Page Last Updated:
May 05, 2017
Use of the Common Weakness Enumeration and the associated references from this website are subject to the
Terms of Use. For more information, please email
cwe@mitre.org.
Description
