- 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 Authentication [CWE-287]
Improper Authentication weakness describes improper mechanisms of user's identity verification.
Created: September 11, 2012
Latest Update: January 10, 2019
Table of Content
- Potential impact
- Attack patterns
- Affected software
- Severity and CVSS Scoring
- Latest Related Security Advisories
Authentication is a part of the AAA (Authentication, Authorization, Accounting) security model. It is a process by which the system or application validates supplied credentials and assigns appropriate privileges.
This weakness occurs when application improperly verifies identity of a user. If software incorrectly validates user logon information or allows using different techniques of malicious credentials gathering (e.g. brute force, spoofing), an attacker can gain certain privileges within the application or disclose sensitive information.
For example, a software uses the "group" parameter passed in the HTTP GET request to assign certain privileges within the application. If the parameter is equal to "user" the application allows viewing the information, if it is equal to "admin", then it is possible to edit information on the page:
If an attacker changes the value of the "group" parameter to "admin", he will be able to modify the page.
The above example is just a simple demonstration of how the weakness works. In real-world scenarios, improper authentication can result from different sources, e.g. software misconfiguration, or can be introduced by another vulnerability, such as SQL injection, cross-site scripting, path traversal, local or remote file inclusion, etc.
2. Potential impact
The attacker might be able to gain unauthorized access to the application and otherwise restricted areas and perform certain actions, e.g. disclose sensitive information, alter application, or even execute arbitrary code.
An attacker can use a variety of vectors to exploit this weakness, including brute-force, session fixation, and Man-in-the-Middle (MitM) attacks.
3. Attack patterns
There are following CAPEC patterns for this weakness:
- CAPEC-22: Exploiting Trust in Client (aka Make the Client Invisible
- CAPEC-57: Utilizing REST's Trust in the System Resource to Register Man in the Middle
- CAPEC-94: Man in the Middle Attack
- CAPEC-114: Authentication Abuse
This weakness is described by WASC under two attack types:
4. Affected software
Multiuser systems and applications that use different privilege levels are potentially vulnerable to this weakness.
5. Severity and CVSS Scoring
This weakness should be scored depending on the maximum possible impact. Below are several examples of scoring the weakness:
Information disclosure (MitM attack)4.3 (AV:N/AC:M/Au:N/C:P/I:N/A:N) - Medium severity.
Control over the application
If a remote attacker can gain complete access to the application, the weakness is usually scored as:
7.5 (AV:N/AC:L/Au:N/C:P/I:P/A:P) - High severity.
Remote code execution
Improper authentication can also result in fully compromised system, if vulnerable application has enough privileges to execute arbitrary commands. In this case, the weakness should be scored with the maximum CVSS rating:
10 (AV:N/AC:L/Au:N/C:C/I:C/A:C) - Critical severity.
We use CVSSv2 scoring system in our HTB Security Advisories to calculate the risk of the discovered vulnerabilities. Not all of the vulnerabilities are scored in strict accordance to FIRST recommendations. Our CVSSv2 scores are based on our long internal experience in software auditing and penetration testing, taking into consideration a lot of practical nuances and details. Therefore, sometimes they may differ from those ones that are recommended by FIRST.
To protect the application from this weakness it is advised to implement strong authentication methods that features anti brute force and session protection mechanisms.
- CWE-287: Improper Authentication [cwe.mitre.org]
- CVE-2009-3421 [cve.mitre.org]
- Authentication [msdn.microsoft.com]
8. Latest HTB Security Advisories with CWE-287
- HTB23289: SSO Authentication Bypass and Website Takeover in DOKEOS
- HTB23192: Improper Authentication in Burden
- HTB23117: Multiple vulnerabilities in AContent
- HTB23101: Multiple vulnerabilities in PBBoard
- HTB22773: Authentication Bypass Vulnerability in phpMySport
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