deardaniel/secdata-raw huggingface dataset:
CWE-283: Unverified Ownership

Description:
The product does not properly verify that a critical resource is owned by the proper entity.

Affected languages: Not Language-Specific
Parent weaknesses: CWE-282

Consequences:
  - Access Control: Gain Privileges or Assume Identity

Mitigations:
  - [Architecture and Design] Very carefully manage the setting, management, and handling of privileges. Explicitly manage trust zones in the software.
  - [Architecture and Design] Consider following the principle of separation of privilege. Require multiple conditions to be met before permitting access to a system resource.

Demonstrative examples:
This function is part of a privileged program that takes input from users with potentially lower privileges.
This code does not confirm that the process to be killed is owned by the requesting user, thus allowing an attacker to kill arbitrary processes.
def killProcess(processID): os.kill(processID, signal.SIGKILL)
def killProcess(processID): 
                         user = getCurrentUser() 
                            
                            #Check process owner against requesting user 
                            if getProcessOwner(processID) == user: os.kill(processID, signal.SIGKILL) return 
                            else: print("You cannot kill a process you don't own") return

Real-world examples:
  - CVE-2001-0178: Program does not verify the owner of a UNIX socket that is used for sending a password.
  - CVE-2004-2012: Owner of special device not checked, allowing root.
CWE-286: Incorrect User Management

Description:
The product does not properly manage a user within its environment.

Extended Description:
Users can be assigned to the wrong group (class) of permissions resulting in unintended access rights to sensitive objects.

Affected languages: Not Language-Specific
Parent weaknesses: CWE-284

Consequences:
  - Other: Varies by Context

Real-world examples:
  - CVE-2022-36109: Containerization product does not record a user's supplementary group ID, allowing bypass of group restrictions.
  - CVE-1999-1193: Operating system assigns user to privileged wheel group, allowing the user to gain root privileges.
CWE-288: Authentication Bypass Using an Alternate Path or Channel

Description:
The product requires authentication, but the product has an alternate path or channel that does not require authentication.

Affected languages: Not Language-Specific
Affected technologies: Not Technology-Specific, Web Based
Parent weaknesses: CWE-306, CWE-284

Consequences:
  - Access Control: Bypass Protection Mechanism

Mitigations:
  - [Architecture and Design] Funnel all access through a single choke point to simplify how users can access a resource. For every access, perform a check to determine if the user has permissions to access the resource.

Demonstrative examples:
Register SECURE_ME is located at address 0xF00. A
                 mirror of this register called COPY_OF_SECURE_ME is
                 at location 0x800F00. The register SECURE_ME is
                 protected from malicious agents and only allows
                 access to select, while COPY_OF_SECURE_ME is not. 
                
                
                 Access control is implemented using an allowlist (as
                 indicated by acl_oh_allowlist). The identity of the
                 initiator of the transaction is indicated by the
                 one hot input, incoming_id. This is checked against
                 the acl_oh_allowlist (which contains a list of
                 initiators that are allowed to access the asset). 
                
                
         

Real-world examples:
  - CVE-2000-1179: Router allows remote attackers to read system logs without authentication by directly connecting to the login screen and typing certain control characters.
  - CVE-1999-1454: Attackers with physical access to the machine may bypass the password prompt by pressing the ESC (Escape) key.
  - CVE-1999-1077: OS allows local attackers to bypass the password protection of idled sessions via the programmer's switch or CMD-PWR keyboard sequence, which brings up a debugger that the attacker can use to disable 
  - CVE-2003-0304: Direct request of installation file allows attacker to create administrator accounts.
  - CVE-2002-0870: Attackers may gain additional privileges by directly requesting the web management URL.
CWE-289: Authentication Bypass by Alternate Name

Description:
The product performs authentication based on the name of a resource being accessed, or the name of the actor performing the access, but it does not properly check all possible names for that resource or actor.

Affected languages: Not Language-Specific
Parent weaknesses: CWE-1390

Consequences:
  - Access Control: Bypass Protection Mechanism

Detection methods:
  - Automated Static Analysis: Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without havin

Mitigations:
  - [Architecture and Design] Avoid making decisions based on names of resources (e.g. files) if those resources can have alternate names.
  - [Implementation] Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. 
                   When pe
  - [Implementation] Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174). Such errors could be used to bypass allowlist validation schemes by introducing dangerous i

Real-world examples:
  - CVE-2003-0317: Protection mechanism that restricts URL access can be bypassed using URL encoding.
  - CVE-2004-0847: web framework for .NET allows remote attackers to bypass authentication for .aspx files in restricted directories via a request containing a (1) "\" (backslash) or (2) "%5C" (encoded backslash)
CWE-29: Path Traversal: '\..\filename'

Description:
The product uses external input to construct a pathname that should be within a restricted directory, but it does not properly neutralize '\..\filename' (leading backslash dot dot) sequences that can resolve to a location that is outside of that directory.

Extended Description:
This allows attackers to traverse the file system to access files or directories that are outside of the restricted directory. 
             This is similar to CWE-25, except using "\" instead of "/". Sometimes a program checks for "..\" at the beginning of the input, so a "\..\" can bypass that check. It is also useful for bypassing path traversal protection schemes that only assume that the "/" separator is valid.

Affected languages: Not Language-Specific
Parent weaknesses: CWE-23

Consequences:
  - Confidentiality: Read Files or Directories

Detection methods:
  - Automated Static Analysis: Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without havin

Mitigations:
  - [Implementation] Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. 
                   When pe
  - [Implementation] Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174). Such errors could be used to bypass allowlist validation schemes by introducing dangerous i

Real-world examples:
  - CVE-2002-1987: Protection mechanism checks for "/.." but doesn't account for Windows-specific "\.." allowing read of arbitrary files.
  - CVE-2005-2142: Directory traversal vulnerability in FTP server allows remote authenticated attackers to list arbitrary directories via a "\.." sequence in an LS command.
CWE-290: Authentication Bypass by Spoofing

Description:
This attack-focused weakness is caused by incorrectly implemented authentication schemes that are subject to spoofing attacks.

Affected languages: Not Language-Specific
Parent weaknesses: CWE-1390, CWE-287

Consequences:
  - Access Control: Bypass Protection Mechanism

Demonstrative examples:
The following code authenticates users.
The authentication mechanism implemented relies on an IP address for source validation. If an attacker is able to spoof the IP, they may be able to bypass the authentication mechanism.
String sourceIP = request.getRemoteAddr(); if (sourceIP != null && sourceIP.equals(APPROVED_IP)) { authenticated = true; }

Both of these examples check if a request is from a trusted address before responding to the request.
The code only verifies the address as stored in the request packet. An attacker can spoof this address, thus impersonating a trusted client.
sd = socket(AF_INET, SOCK_DGRAM, 0); serv.sin_family = AF_INET; serv.sin_addr.s_addr = htonl(INADDR_ANY); servr.sin_port = htons(1008); bind(sd, (struct sockaddr *) & serv, sizeof(serv)); 
                      while (1) { memset(msg, 0x0, MAX_MSG); clilen = sizeof(cli); if (inet_ntoa(cli.sin_addr)==getTrustedAddress()) { n = recvfrom(sd, msg, MAX_MSG, 0, (struct sockaddr *) & cli, &clilen); } }
while(true) { 
                         DatagramPacket rp=new DatagramPacket(rData,rData.length); outSock.receive(rp); String in = new String(p.getData(),0, r

Real-world examples:
  - CVE-2022-30319: S-bus functionality in a home automation product performs access control using an IP allowlist, which can be bypassed by a forged IP address.
  - CVE-2009-1048: VOIP product allows authentication bypass using 127.0.0.1 in the Host header.
CWE-291: Reliance on IP Address for Authentication

Description:
The product uses an IP address for authentication.

Extended Description:
IP addresses can be easily spoofed. Attackers can forge the source IP address of the packets they send, but response packets will return to the forged IP address. To see the response packets, the attacker has to sniff the traffic between the victim machine and the forged IP address. In order to accomplish the required sniffing, attackers typically attempt to locate themselves on the same subnet as the victim machine. Attackers may be able to circumvent this requirement by using source routing, but source routing is disabled across much of the Internet today. In summary, IP address verification can be a useful part of an authentication scheme, but it should not be the single factor required for authentication.

Affected languages: Not Language-Specific
Parent weaknesses: CWE-290, CWE-923

Consequences:
  - Access Control: Hide Activities

Mitigations:
  - [Architecture and Design] Use other means of identity verification that cannot be simply spoofed. Possibilities include a username/password or certificate.

Demonstrative examples:
Both of these examples check if a request is from a trusted address before responding to the request.
The code only verifies the address as stored in the request packet. An attacker can spoof this address, thus impersonating a trusted client.
sd = socket(AF_INET, SOCK_DGRAM, 0); serv.sin_family = AF_INET; serv.sin_addr.s_addr = htonl(INADDR_ANY); servr.sin_port = htons(1008); bind(sd, (struct sockaddr *) & serv, sizeof(serv)); 
                      while (1) { memset(msg, 0x0, MAX_MSG); clilen = sizeof(cli); if (inet_ntoa(cli.sin_addr)==getTrustedAddress()) { n = recvfrom(sd, msg, MAX_MSG, 0, (struct sockaddr *) & cli, &clilen); } }
while(true) { 
                         DatagramPacket rp=new DatagramPacket(rData,rData.length); outSock.receive(rp); String in = new String(p.getData(),0, r

Real-world examples:
  - CVE-2022-30319: S-bus functionality in a home automation product performs access control using an IP allowlist, which can be bypassed by a forged IP address.
CWE-293: Using Referer Field for Authentication

Description:
The referer field in HTTP requests can be easily modified and, as such, is not a valid means of message integrity checking.

Affected languages: Not Language-Specific
Parent weaknesses: CWE-290

Consequences:
  - Access Control: Gain Privileges or Assume Identity

Detection methods:
  - Automated Static Analysis: Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without havin

Mitigations:
  - [Architecture and Design] In order to usefully check if a given action is authorized, some means of strong authentication and method protection must be used. Use other means of authorization that cannot be simply spoofed. Possibilities include a username/password or certificate.

Demonstrative examples:
The following code samples check a packet's referer in order to decide whether or not an inbound request is from a trusted host.
These examples check if a request is from a trusted referer before responding to a request, but the code only verifies the referer name as stored in the request packet. An attacker can spoof the referer, thus impersonating a trusted client.
String trustedReferer = "http://www.example.com/" while(true){ n = read(newsock, buffer, BUFSIZE); requestPacket = processPacket(buffer, n); if (requestPacket.referer == trustedReferer){ openNewSecureSession(requestPacket); } }
boolean processConnectionRequest(HttpServletRequest request){ String referer = request.getHeader("referer") String trustedReferer = "http://www.example.com/" if(referer.equals(trustedReferer)){ openPriv
CWE-294: Authentication Bypass by Capture-replay

Description:
A capture-replay flaw exists when the design of the product makes it possible for a malicious user to sniff network traffic and bypass authentication by replaying it to the server in question to the same effect as the original message (or with minor changes).

Extended Description:
Capture-replay attacks are common and can be difficult to defeat without cryptography. They are a subset of network injection attacks that rely on observing previously-sent valid commands, then changing them slightly if necessary and resending the same commands to the server.

Affected languages: Not Language-Specific
Parent weaknesses: CWE-1390, CWE-287

Consequences:
  - Access Control: Gain Privileges or Assume Identity

Mitigations:
  - [Architecture and Design] Utilize some sequence or time stamping functionality along with a checksum which takes this into account in order to ensure that messages can be parsed only once.
  - [Architecture and Design] Since any attacker who can listen to traffic can see sequence numbers, it is necessary to sign messages with some kind of cryptography to ensure that sequence numbers are not simply doctored along with content.

Real-world examples:
  - CVE-2005-3435: product authentication succeeds if user-provided MD5 hash matches the hash in its database; this can be subjected to replay attacks.
  - CVE-2007-4961: Chain: cleartext transmission of the MD5 hash of password (CWE-319) enables attacks against a server that is susceptible to replay (CWE-294).
CWE-296: Improper Following of a Certificate's Chain of Trust

Description:
The product does not follow, or incorrectly follows, the chain of trust for a certificate back to a trusted root certificate.

Extended Description:
There are several ways in which the chain of trust might be broken, including but not limited to: 
             
               Any certificate in the chain is self-signed, unless it is the root. 
               Not every intermediate certificate is checked, starting from the original certificate all the way up to the root certificate. 
               An intermediate, CA-signed certificate does not have the expected Basic Constraints or other important extensions. 
               The root certificate has been compromised or authorized to the wrong party.

Affected languages: Not Language-Specific
Affected technologies: Not Technology-Specific, Web Based
Parent weaknesses: CWE-295, CWE-573

Consequences:
  - Non-Repudiation: Hide Activities
  - Integrity: Gain Privileges or Assume Identity

Detection methods:
  - Automated Static Analysis: Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without havin

Mitigations:
  - [Architecture and Design] Ensure that proper certificate checking is included in the system design.
  - [Implementation] Understand, and properly implement all checks necessary to ensure the integrity of certificate trust integrity.
  - [Implementation] If certificate pinning is being used, ensure that all relevant properties of the certificate are fully validated before the certificate is pinned, including the full chain of trust.

Demonstrative examples:
This code checks the certificate of a connected peer.
In this case, because the certificate is self-signed, there was no external authority that could prove the identity of the host. The program could be communicating with a different system that is spoofing the host, e.g. by poisoning the DNS cache or using an Adversary-in-the-Middle (AITM) attack to modify the traffic from server to client.
if ((cert = SSL_get_peer_certificate(ssl)) && host) foo=SSL_get_verify_result(ssl); 
                      if ((X509_V_OK==foo) || X509_V_ERR_SELF_SIGNED_CERT_IN_CHAIN==foo)) 
                         
                            
                            // certificate looks good, host can be trusted

Real-world examples:
  - CVE-2016-2402: Server allows bypass of certificate pinning by sending a chain of trust that includes a trusted CA that is not pinned.
  - CVE-2008-4989: Verification function trusts certificate chains in which the last certificate is self-signed.
  - CVE-2012-5821: Chain: Web browser uses a TLS-related function incorrectly, preventing it from verifying that a server's certificate is signed by a trusted certification authority (CA).
  - CVE-2009-3046: Web browser does not check if any intermediate certificates are revoked.
  - CVE-2009-0265: chain: DNS server does not correctly check return value from the OpenSSL EVP_VerifyFinal function allows bypass of validation of the certificate chain.
CWE-298: Improper Validation of Certificate Expiration

Description:
A certificate expiration is not validated or is incorrectly validated.

Affected languages: Not Language-Specific
Parent weaknesses: CWE-295, CWE-672

Consequences:
  - Integrity: Other
  - Authentication: Other

Mitigations:
  - [Architecture and Design] Check for expired certificates and provide the user with adequate information about the nature of the problem and how to proceed.
  - [Implementation] If certificate pinning is being used, ensure that all relevant properties of the certificate are fully validated before the certificate is pinned, including the expiration.

Demonstrative examples:
The following OpenSSL code ensures that there is a certificate and allows the use of expired certificates.
If the call to SSL_get_verify_result() returns X509_V_ERR_CERT_HAS_EXPIRED, this means that the certificate has expired. As time goes on, there is an increasing chance for attackers to compromise the certificate.
if (cert = SSL_get_peer(certificate(ssl)) { 
                         foo=SSL_get_verify_result(ssl); if ((X509_V_OK==foo) || (X509_V_ERR_CERT_HAS_EXPIRED==foo)) 
                               
                                  
                                  //do stuff

Real-world examples:
  - CVE-2025-4384: product does not verify that a certificate has expired
  - CVE-2007-3564: web library product does not verify that a certificate has expired
  - CVE-2007-6746: IRC product does not check the expiration date of the X.509 certificate
  - CVE-2007-6746: library for SSL and TLS does not check the activation or expiration dates of CA certificates
CWE-299: Improper Check for Certificate Revocation

Description:
The product does not check or incorrectly checks the revocation status of a certificate, which may cause it to use a certificate that has been compromised.

Extended Description:
An improper check for certificate revocation is a far more serious flaw than related certificate failures. This is because the use of any revoked certificate is almost certainly malicious. The most common reason for certificate revocation is compromise of the system in question, with the result that no legitimate servers will be using a revoked certificate, unless they are sorely out of sync.

Affected languages: Not Language-Specific
Affected technologies: Not Technology-Specific, Web Based
Parent weaknesses: CWE-295, CWE-404

Consequences:
  - Access Control: Gain Privileges or Assume Identity
  - Integrity: Other
  - Confidentiality: Read Application Data

Detection methods:
  - Automated Static Analysis: Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without havin

Mitigations:
  - [Architecture and Design] Ensure that certificates are checked for revoked status.
  - [Implementation] If certificate pinning is being used, ensure that all relevant properties of the certificate are fully validated before the certificate is pinned, including the revoked status.

Demonstrative examples:
The following OpenSSL code ensures that there is a certificate before continuing execution.
Because this code does not use SSL_get_verify_results() to check the certificate, it could accept certificates that have been revoked (X509_V_ERR_CERT_REVOKED). The product could be communicating with a malicious host.
if (cert = SSL_get_peer_certificate(ssl)) { 
                         
                            
                            // got a certificate, do secret things

Real-world examples:
  - CVE-2011-2014: LDAP-over-SSL implementation does not check Certificate Revocation List (CRL), allowing spoofing using a revoked certificate.
  - CVE-2011-0199: Operating system does not check Certificate Revocation List (CRL) in some cases, allowing spoofing using a revoked certificate.
  - CVE-2010-5185: Antivirus product does not check whether certificates from signed executables have been revoked.
  - CVE-2009-3046: Web browser does not check if any intermediate certificates are revoked.
  - CVE-2009-0161: chain: Ruby module for OCSP misinterprets a response, preventing detection of a revoked certificate.