CWE

Common Weakness Enumeration

A Community-Developed Dictionary of Software Weakness Types

Common Weakness Scoring System
Common Weakness Risk Analysis Framework
Home > CWE List > CWE- Individual Dictionary Definition (2.8)  

Presentation Filter:

CWE-284: Improper Access Control

 
Improper Access Control
Weakness ID: 284 (Weakness Class)Status: Incomplete
+ Description

Description Summary

The software does not restrict or incorrectly restricts access to a resource from an unauthorized actor.

Extended Description

Access control involves the use of several protection mechanisms such as authentication (proving the identity of an actor) authorization (ensuring that a given actor can access a resource), and accountability (tracking of activities that were performed). When any mechanism is not applied or otherwise fails, attackers can compromise the security of the software by gaining privileges, reading sensitive information, executing commands, evading detection, etc.

There are two distinct behaviors that can introduce access control weaknesses:

  • Specification: incorrect privileges, permissions, ownership, etc. are explicitly specified for either the user or the resource (for example, setting a password file to be world-writable, or giving administrator capabilities to a guest user). This action could be performed by the program or the administrator.

  • Enforcement: the mechanism contains errors that prevent it from properly enforcing the specified access control requirements (e.g., allowing the user to specify their own privileges, or allowing a syntactically-incorrect ACL to produce insecure settings). This problem occurs within the program itself, in that it does not actually enforce the intended security policy that the administrator specifies.

+ Alternate Terms
Authorization:

The terms "access control" and "authorization" are often used interchangeably, although many people have distinct definitions. The CWE usage of "access control" is intended as a general term for the various mechanisms that restrict which users can access which resources, and "authorization" is more narrowly defined. It is unlikely that there will be community consensus on the use of these terms.

+ Time of Introduction
  • Architecture and Design
  • Implementation
  • Operation
+ Common Consequences
ScopeEffect
Other

Technical Impact: Varies by context

+ Potential Mitigations

Phases: Architecture and Design; Operation

Very carefully manage the setting, management, and handling of privileges. Explicitly manage trust zones in the software.

Phase: Architecture and Design

Strategy: Separation of Privilege

Compartmentalize the system to have "safe" areas where trust boundaries can be unambiguously drawn. Do not allow sensitive data to go outside of the trust boundary and always be careful when interfacing with a compartment outside of the safe area.

Ensure that appropriate compartmentalization is built into the system design and that the compartmentalization serves to allow for and further reinforce privilege separation functionality. Architects and designers should rely on the principle of least privilege to decide when it is appropriate to use and to drop system privileges.

+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfCategoryCategory264Permissions, Privileges, and Access Controls
Development Concepts (primary)699
ChildOfCategoryCategory632Weaknesses that Affect Files or Directories
Resource-specific Weaknesses (primary)631
ChildOfWeakness ClassWeakness Class664Improper Control of a Resource Through its Lifetime
Research Concepts1000
ChildOfWeakness ClassWeakness Class693Protection Mechanism Failure
Research Concepts (primary)1000
ChildOfCategoryCategory723OWASP Top Ten 2004 Category A2 - Broken Access Control
Weaknesses in OWASP Top Ten (2004) (primary)711
ChildOfCategoryCategory944SFP Secondary Cluster: Access Management
Software Fault Pattern (SFP) Clusters (primary)888
ParentOfWeakness BaseWeakness Base269Improper Privilege Management
Development Concepts (primary)699
Research Concepts (primary)1000
ParentOfWeakness ClassWeakness Class282Improper Ownership Management
Research Concepts (primary)1000
ParentOfWeakness ClassWeakness Class285Improper Authorization
Development Concepts (primary)699
Research Concepts (primary)1000
ParentOfWeakness ClassWeakness Class286Incorrect User Management
Development Concepts (primary)699
Research Concepts (primary)1000
ParentOfWeakness ClassWeakness Class287Improper Authentication
Development Concepts (primary)699
Research Concepts (primary)1000
ParentOfWeakness BaseWeakness Base346Origin Validation Error
Development Concepts699
Research Concepts1000
ParentOfWeakness VariantWeakness Variant782Exposed IOCTL with Insufficient Access Control
Development Concepts699
ParentOfWeakness ClassWeakness Class923Improper Restriction of Communication Channel to Intended Endpoints
Development Concepts (primary)699
Research Concepts (primary)1000
ParentOfWeakness VariantWeakness Variant942Overly Permissive Cross-domain Whitelist
Development Concepts (primary)699
Research Concepts (primary)1000
+ Affected Resources
  • File/Directory
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERAccess Control List (ACL) errors
WASC2Insufficient Authorization
+ References
[REF-11] M. Howard and D. LeBlanc. "Writing Secure Code". Chapter 6, "Determining Appropriate Access Control" Page 171. 2nd Edition. Microsoft. 2002.
[REF-17] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 17: Failure to Protect Stored Data." Page 253. McGraw-Hill. 2010.
+ Maintenance Notes

This item needs more work. Possible sub-categories include:

* Trusted group includes undesired entities (partially covered by CWE-286)

* Group can perform undesired actions

* ACL parse error does not fail closed

+ Content History
Submissions
Submission DateSubmitterOrganizationSource
PLOVERExternally Mined
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigitalExternal
updated Time_of_Introduction
2008-09-08CWE Content TeamMITREInternal
updated Alternate_Terms, Background_Details, Description, Maintenance_Notes, Name, Relationships, Taxonomy_Mappings
2008-10-14CWE Content TeamMITREInternal
updated Relationships
2009-03-10CWE Content TeamMITREInternal
updated Relationships
2009-07-27CWE Content TeamMITREInternal
updated Alternate_Terms, Relationships
2009-12-28CWE Content TeamMITREInternal
updated Potential_Mitigations
2010-02-16CWE Content TeamMITREInternal
updated References, Taxonomy_Mappings
2010-06-21CWE Content TeamMITREInternal
updated Potential_Mitigations
2011-03-24
(Critical)
CWE Content TeamMITREInternal
Changed name and description; clarified difference between "access control" and "authorization."
2011-03-29CWE Content TeamMITREInternal
updated Alternate_Terms, Background_Details, Description, Maintenance_Notes, Name, Relationships
2011-06-01CWE Content TeamMITREInternal
updated Common_Consequences
2011-06-27CWE Content TeamMITREInternal
updated Common_Consequences
2012-05-11CWE Content TeamMITREInternal
updated References, Relationships
2012-10-30CWE Content TeamMITREInternal
updated Potential_Mitigations
2014-02-18CWE Content TeamMITREInternal
updated Related_Attack_Patterns, Relationships
2014-06-23CWE Content TeamMITREInternal
updated Relationships
2014-07-30CWE Content TeamMITREInternal
updated Relationships
Previous Entry Names
Change DatePrevious Entry Name
2008-09-09Access Control Issues
2011-03-29Access Control (Authorization) Issues
Page Last Updated: July 30, 2014