CWE - CWE-287: Improper Authentication (4.20) Common Weakness Enumeration A community-developed list of SW & HW weaknesses that can become vulnerabilities Home > CWE List > CWE-287: Improper Authentication (4.20) ID Lookup: * Home * About ▼ Who We Are User Stories History Documents Videos * Learn ▼ Basics Root Cause Mapping ► Guidance Quick Tips Examples How to Contribute Weakness Content FAQs Glossary * Access Content ▼ Top-N Lists ► Top 25 Software Top Hardware Top 10 KEV Weaknesses CWE List ► Current Version Reports Visualizations Releases Archive Downloads REST API * Community ▼ News ► Current News Blog Podcast News Archive CWE Board Working Groups & Special Interest Groups Email Lists * Search ▼ Search CWE List Search Website CWE Glossary Definition CWE-287: Improper Authentication Weakness ID: 287 Vulnerability Mapping : DISCOURAGED This CWE ID should not be used to map to real-world vulnerabilities Abstraction: Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. View customized information: Conceptual For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. Operational For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. Mapping Friendly For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. Complete For users who wish to see all available information for the CWE/CAPEC entry. Custom For users who want to customize what details are displayed. Edit Custom Filter Conceptual Operational Mapping Friendly Select All Reset Clear Submit Cancel Description When an actor claims to have a given identity, the product does not prove or insufficiently proves that the claim is correct. Alternate Terms authentification An alternate term is "authentification", which appears to be most commonly used by people from non-English-speaking countries. AuthN "AuthN" is typically used as an abbreviation of "authentication" within the web application security community. It is also distinct from "AuthZ," which is an abbreviation of "authorization." The use of "Auth" as an abbreviation is discouraged, since it could be used for either authentication or authorization. AuthC "AuthC" is used as an abbreviation of "authentication," but it appears to used less frequently than "AuthN." Common Consequences This table 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. Impact Details Read Application Data; Gain Privileges or Assume Identity; Execute Unauthorized Code or Commands Scope: Integrity, Confidentiality, Availability, Access Control This weakness can lead to the exposure of resources or functionality to unintended actors, possibly providing attackers with sensitive information or even execute arbitrary code. Potential Mitigations Phase(s) Mitigation Architecture and Design Strategy: Libraries or Frameworks Use an authentication framework or library such as the OWASP ESAPI Authentication feature. Relationships This table 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" (View-1000) Nature Type ID Name ChildOf Pillar - a weakness that is the most abstract type of weakness and represents a theme for all class/base/variant weaknesses related to it. A Pillar is different from a Category as a Pillar is still technically a type of weakness that describes a mistake, while a Category represents a common characteristic used to group related things. 284 Improper Access Control ParentOf Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 295 Improper Certificate Validation ParentOf Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 306 Missing Authentication for Critical Function ParentOf Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 645 Overly Restrictive Account Lockout Mechanism ParentOf Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 1390 Weak Authentication CanFollow Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 613 Insufficient Session Expiration Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (View-1003) Nature Type ID Name MemberOf View - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 1003 Weaknesses for Simplified Mapping of Published Vulnerabilities ParentOf Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 290 Authentication Bypass by Spoofing ParentOf Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 294 Authentication Bypass by Capture-replay ParentOf Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 295 Improper Certificate Validation ParentOf Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 306 Missing Authentication for Critical Function ParentOf Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 307 Improper Restriction of Excessive Authentication Attempts ParentOf Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 521 Weak Password Requirements ParentOf Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 522 Insufficiently Protected Credentials ParentOf Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 640 Weak Password Recovery Mechanism for Forgotten Password ParentOf Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 798 Use of Hard-coded Credentials Relevant to the view "Architectural Concepts" (View-1008) Nature Type ID Name MemberOf Category - a CWE entry that contains a set of other entries that share a common characteristic. 1010 Authenticate Actors Relevant to the view "CISQ Data Protection Measures" (View-1340) Nature Type ID Name ChildOf Pillar - a weakness that is the most abstract type of weakness and represents a theme for all class/base/variant weaknesses related to it. A Pillar is different from a Category as a Pillar is still technically a type of weakness that describes a mistake, while a Category represents a common characteristic used to group related things. 284 Improper Access Control 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 life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase. Phase Note Architecture and Design Implementation REALIZATION: This weakness is caused during implementation of an architectural security tactic. Applicable Platforms This listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance. Languages Class: Not Language-Specific (Undetermined Prevalence) Operating Systems Class: Not OS-Specific (Undetermined Prevalence) Technologies Class: Not Technology-Specific (Undetermined Prevalence) Class: Web Based (Undetermined Prevalence) Class: ICS/OT (Often Prevalent) Likelihood Of Exploit High Demonstrative Examples Example 1 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 code) Example Language: Perl 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 code) GET /cgi-bin/vulnerable.cgi HTTP/1.1 Cookie: user=Administrator Cookie: 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. Example 2 In January 2009, an attacker was able to gain administrator access to a Twitter server because the server did not restrict the number of login attempts [ REF-236 ]. The attacker targeted a member of Twitter's support team and was able to successfully guess the member's password using a brute force attack by guessing a large number of common words. After gaining access as the member of the support staff, the attacker used the administrator panel to gain access to 33 accounts that belonged to celebrities and politicians. Ultimately, fake Twitter messages were sent that appeared to come from the compromised accounts. Example 2 References: [REF-236] Kim Zetter. "Weak Password Brings 'Happiness' to Twitter Hacker". 2009-01-09. < https://www.wired.com/2009/01/professed-twitt/ >. URL validated: 2023-04-07 . Example 3 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. Selected Observed Examples Note: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry. Reference 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 only one, allowing bypass of the proxy authentication ( CWE-1390 ) 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 unexpected files, as exploited in the wild per CISA KEV. 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. CVE-2021-35