CWE

Common Weakness Enumeration

A Community-Developed List of Software Weakness Types

CWE/SANS Top 25 Most Dangerous Software Errors
Home > CWE List > CWE- Individual Dictionary Definition (3.0)  
ID

CWE-284: Improper Access Control

Weakness ID: 284
Abstraction: Class
Structure: Simple
Status: Incomplete
Presentation Filter:
+ Description
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.
+ Relationships

The table(s) below shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.

+ Relevant to the view "Research Concepts" (CWE-1000)
+ Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (CWE-1003)
NatureTypeIDName
ParentOfClassClass285Improper Authorization
ParentOfClassClass287Improper Authentication
+ Relevant to the view "Architectural Concepts" (CWE-1008)
NatureTypeIDName
MemberOfCategoryCategory1011Authorize Actors
+ Relevant to the view "Development Concepts" (CWE-699)
+ Modes Of Introduction

The different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the software life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.

PhaseNote
Architecture and Design
ImplementationREALIZATION: This weakness is caused during implementation of an architectural security tactic.
Operation
+ Common Consequences

The table below specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.

ScopeImpactLikelihood
Other

Technical Impact: Varies by Context

+ 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.
+ Observed Examples
ReferenceDescription
Bulletin board applies restrictions on number of images during post creation, but does not enforce this on editing.
+ 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.
+ Affected Resources
  • File or Directory
+ Memberships
This MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
+ Notes

Maintenance

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
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERAccess Control List (ACL) errors
WASC2Insufficient Authorization
+ References
[REF-7] Michael Howard and David LeBlanc. "Writing Secure Code". Chapter 6, "Determining Appropriate Access Control" Page 171. 2nd Edition. Microsoft Press. 2002-12-04. <https://www.microsoft.com/mspress/books/toc/5957.aspx>.
[REF-44] 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.
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
PLOVER
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Alternate_Terms, Background_Details, Description, Maintenance_Notes, Name, Relationships, Taxonomy_Mappings
2008-10-14CWE Content TeamMITRE
updated Relationships
2009-03-10CWE Content TeamMITRE
updated Relationships
2009-07-27CWE Content TeamMITRE
updated Alternate_Terms, Relationships
2009-12-28CWE Content TeamMITRE
updated Potential_Mitigations
2010-02-16CWE Content TeamMITRE
updated References, Taxonomy_Mappings
2010-06-21CWE Content TeamMITRE
updated Potential_Mitigations
2011-03-24CWE Content TeamMITRE
Changed name and description; clarified difference between "access control" and "authorization."
2011-03-29CWE Content TeamMITRE
updated Alternate_Terms, Background_Details, Description, Maintenance_Notes, Name, Relationships
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated References, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-02-18CWE Content TeamMITRE
updated Related_Attack_Patterns, Relationships
2014-06-23CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships
2015-12-07CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Affected_Resources, Modes_of_Introduction, Observed_Examples, References, Relationships
Previous Entry Names
Change DatePrevious Entry Name
2008-09-09Access Control Issues
2011-03-29Access Control (Authorization) Issues

More information is available — Please select a different filter.
Page Last Updated: November 14, 2017