- CWE-22: Path Traversal
- CWE-78: OS Command Injection
- CWE-79: Cross-Site Scripting
- CWE-89: SQL Injection
- CWE-90: LDAP Injection
- CWE-91: XML Injection
- CWE-94: Code Injection
- CWE-98: PHP File Inclusion
- CWE-113: HTTP Response Splitting
- CWE-119: Buffer Errors
- CWE-130: Improper Handling of Length Parameter Inconsistency
- CWE-193: Off-by-one Error
- CWE-200: Information Exposure
- CWE-211: Information Exposure Through Externally-Generated Error Message
- CWE-236: Improper Handling of Undefined Parameters
- CWE-276: Incorrect Default Permissions
- CWE-284: Improper Access Control
- CWE-285: Improper Authorization
- CWE-287: Improper Authentication
- CWE-297: Improper Validation of Certificate with Host Mismatch
- CWE-306: Missing Authentication for Critical Function
- CWE-312: Cleartext Storage of Sensitive Information
- CWE-345: Insufficient Verification of Data Authenticity
- CWE-352: Cross-Site Request Forgery
- CWE-384: Session Fixation
- CWE-427: Uncontrolled Search Path Element
- CWE-434: Unrestricted Upload of File with Dangerous Type
- CWE-476: NULL Pointer Dereference
- CWE-521: Weak Password Requirements
- CWE-601: Open Redirect
- CWE-611: Improper Restriction of XML External Entity Reference ('XXE')
- CWE-613: Insufficient Session Expiration
- CWE-618: Exposed Unsafe ActiveX Method
- CWE-671: Lack of Administrator Control over Security
- CWE-798: Use of Hard-coded Credentials
- CWE-799: Improper Control of Interaction Frequency
- CWE-822: Untrusted Pointer Dereference
- CWE-835: Infinite Loop
- CWE-918: Server-Side Request Forgery (SSRF)
- CWE-942: Overly Permissive Cross-domain Whitelist
CWE is a trademark of the MITRE Corporation.
Improper Access Control [CWE-284]
Improper Access Control weakness describes a failure in the AAA security model.
Created: September 11, 2012
Latest Update: June 26, 2019
Table of Content
- Potential impact
- Attack patterns
- Affected software
- Severity and CVSS Scoring
- Latest Related Security Advisories
Access control is a security process that controls usage of specific resources within a predefined criteria and is a part of the AAA (Authentication, Authorization, Accounting) security model. All modern systems use certain access control models to manage their security. Access control models can be grouped in three main classes: Mandatory Access Control (MAC), Discretionary Access Control (DAC), and Role Based Access Control (RBAC).
1.1 Mandatory Access Control (MAC)
MAC is an access control model implemented in many modern operating systems such as SELinux (since kernel 2.6), FreeBSD (since 5.0), SUSE Linux, Ubuntu, Microsoft Windows (starting with Vista), etc. In MAC a security policy administrator controls the overall security policy. Users do not have the ability to override the defined policy set and e.g. grant access to otherwise restricted objects. This policy is based on mandated regulations determined by a central authority.
1.2 Discretionary Access Control (DAC)
The DAC access control model is based on identity of the requestor and defined access rules that determine allowed actions. Access decisions are typically based on provided credentials and are subject to manipulation within specified bounds. In most DAC model implementations the owner of the object can modify its permissions and transfer ownership to other subjects.
1.3 Role Based Access Control (RBAC)
Role-based policies control access to objects depending on the roles that user have within the system and on rules that define access permissions for users in the given role.
Discretionary and role-based policies usually contain an administrative policy that defines an administrative account for access control management.
The Improper Access Control weakness describes a case where software fails to restrict access to an object properly. A malicious user can compromise security of the software and perform certain unauthorized actions by gaining elevated privileges, reading otherwise restricted information, executing commands, bypassing implemented security mechanisms, etc.
Two major behaviors can potentially introduce the access control weaknesses:
- Specification: Some permissions, privileges or ownerships, which are initially intended for certain users or processes, can indeed be applied to other users or processes (e.g. placing a file with secured key into a word-readable directory, or assigning capabilities of a privileged account to a guest user).
- Enforcement: the security mechanism contains errors that prevent proper enforcement of the specified access control requirements (e.g. allowing the user to specify his own access controls or allowing incorrect access control lists to produce insecure settings). This problem occurs within the application that does not correctly enforce or inherits the intended security policy.
The following PHP code can be used as an example of the improper access control weakness:
- // Improper Access Control [CWE-284] vulnerable code example
- // (c) HTB Research
- define ("ACCESS_DENIED",false);
- if ($_SERVER["REQUEST_METHOD"]=="GET"):
- if (ACCESS_DENIED):
- echo "You don't have permission to access this file.";
In the above code, the ACCESS_DENIED constant is erroneously declared as false. An attacker might be able to send a HTTP POST request to the script, bypass the authorization checks intended for the HTTP GET method, and gain access to output of the
2. Potential impact
This weakness allows an attacker to bypass intended security restrictions and perform a variety of actions depending on the source of error and functionality of the application. An attacker might be able to perform certain actions by gaining elevated privileges, reading otherwise restricted information, executing commands, bypassing implemented security mechanisms, etc.
3. Attack patterns
There is only one CAPEC pattern that is related to this weakness:
- CAPEC-19: Embedding Scripts within Scripts
This weakness is not described as an attack technique in WASC Threat Classification database.
4. Affected software
Any software intended to handle access controls is potentially vulnerable to this weakness.
5. Severity and CVSS Scoring
This vulnerability could be scored differently depending on application's design, its functionality and potential security impact. In case an attacker gets full control over the application or can read, modify and delete data, it should be scored as:
9.8 [CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H] – Critical severity.
Improper access control weaknesses usually result in logic errors. Developers must carefully manage settings and handling of privileges as well as pay attention to security zones within the application. They should also integrate mechanisms that control privilege separation functionality and think about creating architecture that relies on the least privilege principle.
- CWE-284: Improper Access Control [cwe.mitre.org]
- Insufficient Authorization [projects.webappsec.org]
- Mandatory access control [wikipedia.org]
- Mandatory Access Control [lindqvist.awardspace.info]
- Access Control: Policies, Models, and Mechanisms [spdp.dti.unimi.it]
- Access Control Model (Windows) [msdn.microsoft.com]
8. Improper Access Control Vulnerabilities, Exploits and Examples
- HTB23254: Multiple Vulnerabilities in TheCartPress WordPress plugin
- HTB23243: Multiple vulnerabilities in MantisBT
- HTB23238: Multiple vulnerabilities in EspoCRM
- HTB23219: Improper Access Control in ArticleFR
- HTB23202: Multiple Vulnerabilities in OpenDocMan
Copyright Disclaimer: Any above-mentioned content can be copied and used for non-commercial purposes only if proper credit to ImmuniWeb is given.↑ Back to Top