Description
When an actor claims to have a given identity, the product does not prove or insufficiently proves that the claim is correct.
OAuth Misconfiguration Guide
Read our in-depth guide on exploiting and mitigating this weakness
Potential Impact
Integrity, Confidentiality, Availability, Access Control
Read Application Data, Gain Privileges or Assume Identity, Execute Unauthorized Code or Commands
Demonstrative Examples
The following code intends to ensure that the user is already logged in. If not, the code performs authentication with the user-provided username and password. If successful, it sets the loggedin and user cookies to "remember" that the user has already logged in. Finally, the code performs administrator tasks if the logged-in user has the "Administrator" username, as recorded in the user cookie.
Bad
my $q = new CGI;
if ($q->cookie('loggedin') ne "true") {
if (! AuthenticateUser($q->param('username'), $q->param('password'))) {ExitError("Error: you need to log in first");}else {
# Set loggedin and user cookies.$q->cookie(-name => 'loggedin',-value => 'true');
$q->cookie(-name => 'user',-value => $q->param('username'));
}
}
if ($q->cookie('user') eq "Administrator") {DoAdministratorTasks();}Unfortunately, this code can be bypassed. The attacker can set the cookies independently so that the code does not check the username and password. The attacker could do this with an HTTP request containing headers such as:
Attack
GET /cgi-bin/vulnerable.cgi HTTP/1.1Cookie: user=AdministratorCookie: loggedin=true
[body of request]By setting the loggedin cookie to "true", the attacker bypasses the entire authentication check. By using the "Administrator" value in the user cookie, the attacker also gains privileges to administer the software.
In 2022, the OT:ICEFALL study examined products by 10 different Operational Technology (OT) vendors. The researchers reported 56 vulnerabilities and said that the products were "insecure by design" [REF-1283]. If exploited, these vulnerabilities often allowed adversaries to change how the products operated, ranging from denial of service to changing the code that the products executed. Since these products were often used in industries such as power, electrical, water, and others, there could even be safety implications.
Multiple vendors did not use any authentication or used client-side authentication for critical functionality in their OT products.
Mitigations & Prevention
Use an authentication framework or library such as the OWASP ESAPI Authentication feature.
Detection Methods
- Automated Static Analysis Limited — Automated static analysis is useful for detecting certain types of authentication. A tool may be able to analyze related configuration files, such as .htaccess in Apache web servers, or detect the usage of commonly-used authentication libraries. Generally, automated static analys
- Manual Static Analysis High — This weakness can be detected using tools and techniques that require manual (human) analysis, such as penetration testing, threat modeling, and interactive tools that allow the tester to record and modify an active session. Manual static analysis is useful for evaluating the cor
- Manual Static Analysis - Binary or Bytecode SOAR Partial — According to SOAR [REF-1479], the following detection techniques may be useful:
- Dynamic Analysis with Automated Results Interpretation SOAR Partial — According to SOAR [REF-1479], the following detection techniques may be useful:
- Dynamic Analysis with Manual Results Interpretation SOAR Partial — According to SOAR [REF-1479], the following detection techniques may be useful:
- Manual Static Analysis - Source Code SOAR Partial — According to SOAR [REF-1479], the following detection techniques may be useful:
Real-World CVE Examples
| CVE ID | Description |
|---|---|
| CVE-2024-11680 | File-sharing PHP product does not check if user is logged in during requests for PHP library files under an includes/ directory, allowing configuration changes, code execution, and other impacts. |
| CVE-2022-35248 | Chat application skips validation when Central Authentication Service (CAS) is enabled, effectively removing the second factor from two-factor authentication |
| CVE-2022-36436 | Python-based authentication proxy does not enforce password authentication during the initial handshake, allowing the client to bypass authentication by specifying a 'None' authentication type. |
| CVE-2022-30034 | Chain: Web UI for a Python RPC framework does not use regex anchors to validate user login emails (CWE-777), potentially allowing bypass of OAuth (CWE-1390). |
| CVE-2022-29951 | TCP-based protocol in Programmable Logic Controller (PLC) has no authentication. |
| CVE-2022-29952 | Condition Monitor uses a protocol that does not require authentication. |
| CVE-2022-30313 | Safety Instrumented System uses proprietary TCP protocols with no authentication. |
| CVE-2022-30317 | Distributed Control System (DCS) uses a protocol that has no authentication. |
| CVE-2022-33139 | SCADA system only uses client-side authentication, allowing adversaries to impersonate other users. |
| CVE-2021-3116 | Chain: Python-based HTTP Proxy server uses the wrong boolean operators (CWE-480) causing an incorrect comparison (CWE-697) that identifies an authN failure if all three conditions are met instead of |
| CVE-2021-21972 | Chain: Cloud computing virtualization platform does not require authentication for upload of a tar format file (CWE-306), then uses .. path traversal sequences (CWE-23) in the file to access unexpecte |
| CVE-2021-37415 | IT management product does not perform authentication for some REST API requests, as exploited in the wild per CISA KEV. |
| CVE-2021-35033 | Firmware for a WiFi router uses a hard-coded password for a BusyBox shell, allowing bypass of authentication through the UART port |
| CVE-2020-10263 | Bluetooth speaker does not require authentication for the debug functionality on the UART port, allowing root shell access |
| CVE-2020-13927 | Default setting in workflow management product allows all API requests without authentication, as exploited in the wild per CISA KEV. |
Showing 15 of 33 observed examples.
Related Weaknesses
Taxonomy Mappings
- PLOVER: — Authentication Error
- OWASP Top Ten 2007: A7 — Broken Authentication and Session Management
- OWASP Top Ten 2004: A3 — Broken Authentication and Session Management
- WASC: 1 — Insufficient Authentication
- ISA/IEC 62443: Part 3-3 — Req SR 1.1
- ISA/IEC 62443: Part 3-3 — Req SR 1.2
- ISA/IEC 62443: Part 4-2 — Req CR 1.1
- ISA/IEC 62443: Part 4-2 — Req CR 1.2
Frequently Asked Questions
What is CWE-287?
CWE-287 (Improper Authentication) is a software weakness identified by MITRE's Common Weakness Enumeration. It is classified as a Class-level weakness. When an actor claims to have a given identity, the product does not prove or insufficiently proves that the claim is correct.
How can CWE-287 be exploited?
Attackers can exploit CWE-287 (Improper Authentication) to read application data, gain privileges or assume identity, execute unauthorized code or commands. This weakness is typically introduced during the Architecture and Design, Implementation phase of software development.
How do I prevent CWE-287?
Key mitigations include: Use an authentication framework or library such as the OWASP ESAPI Authentication feature.
What is the severity of CWE-287?
CWE-287 is classified as a Class-level weakness (High abstraction). It has been observed in 33 real-world CVEs.