Description
The software does not properly manage privileges while it is switching between different contexts that have different privileges or spheres of control.
Modes of Introduction:
– Architecture and Design
Related Weaknesses
Consequences
Access Control: Gain Privileges or 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.
Potential Mitigations
Phase: Architecture and Design, Operation
Description:
Very carefully manage the setting, management, and handling of privileges. Explicitly manage trust zones in the software.
Phase: Architecture and Design, Operation
Description:
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.
Phase: Architecture and Design
Description:
Consider following the principle of separation of privilege. Require multiple conditions to be met before permitting access to a system resource.
CVE References
- CVE-2002-1688
- Web browser cross domain problem when user hits “back” button.
- CVE-2003-1026
- Web browser cross domain problem when user hits “back” button.
- CVE-2002-1770
- Cross-domain issue – third party product passes code to web browser, which executes it in unsafe zone.
- CVE-2005-2263
- 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.