deardaniel/secdata-raw huggingface dataset:
CWE-32: Path Traversal: '...' (Triple Dot)

Description:
The product uses external input to construct a pathname that should be within a restricted directory, but it does not properly neutralize '...' (triple 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. 
             The '...' manipulation is useful for bypassing some path traversal protection schemes. On some Windows systems, it is equivalent to "..\.." and might bypass checks that assume only two dots are valid. Incomplete filtering, such as removal of "./" sequences, can ultimately produce valid ".." sequences due to a collapse into unsafe value (CWE-182).

Affected languages: Not Language-Specific
Affected technologies: Not Technology-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-2001-0467: "\..." in web server
  - CVE-2001-0615: "..." or "...." in chat server
  - CVE-2001-0963: "..." in cd command in FTP server
  - CVE-2001-1193: "..." in cd command in FTP server
  - CVE-2001-1131: "..." in cd command in FTP server
CWE-321: Use of Hard-coded Cryptographic Key

Description:
The product uses a hard-coded, unchangeable cryptographic key.

Affected languages: Not Language-Specific
Affected technologies: ICS/OT
Parent weaknesses: CWE-798, CWE-798, CWE-798

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] Prevention schemes mirror that of hard-coded password storage.

Demonstrative examples:
The following code examples attempt to verify a password using a hard-coded cryptographic key.
The cryptographic key is within a hard-coded string value that is compared to the password. It is likely that an attacker will be able to read the key and compromise the system.
int VerifyAdmin(char *password) { 
                         if (strcmp(password,"68af404b513073584c4b6f22b6c63e6b")) { 
                               
                                  printf("Incorrect Password!\n"); return(0); 
                            } printf("Entering Diagnostic Mode...\n"); return(1); 
                      }
public boolean VerifyAdmin(String password) { if (password.equals("68af404b513073584c4b6f22b6c63e6b")) { System.out.println("Entering Diagnostic Mode..."); return true; } System.out.println

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 used hard-coded keys for critical functionality in their OT products.

Real-world examples:
  - CVE-2022-29960: Engineering Workstation uses hard-coded cryptographic keys that could allow for unathorized filesystem access and privilege escalation
  - CVE-2022-30271: Remote Terminal Unit (RTU) uses a hard-coded SSH private key that is likely to be used by default.
  - CVE-2020-10884: WiFi router service has a hard-coded encryption key, allowing root access
  - CVE-2014-2198: Communications / collaboration product has a hardcoded SSH private key, allowing access to root account
CWE-322: Key Exchange without Entity Authentication

Description:
The product performs a key exchange with an actor without verifying the identity of that actor.

Extended Description:
Performing a key exchange will preserve the integrity of the information sent between two entities, but this will not guarantee that the entities are who they claim they are. This may enable an attacker to impersonate an actor by modifying traffic between the two entities.  Typically, this involves a victim client that contacts a malicious server that is impersonating a trusted server. If the client skips authentication or ignores an authentication failure, the malicious server may request authentication information from the user. The malicious server can then use this authentication information to log in to the trusted server using the victim's credentials, sniff traffic between the victim and trusted server, etc.

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

Consequences:
  - Access Control: Bypass Protection Mechanism
  - 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 proper authentication is included in the system design.
  - [Implementation] Understand and properly implement all checks necessary to ensure the identity of entities involved in encrypted communications.

Demonstrative examples:
Many systems have used Diffie-Hellman key exchange without authenticating the entities exchanging keys, allowing attackers to influence communications by redirecting or interfering with the communication path.  Many people using SSL/TLS skip the authentication (often unknowingly).
CWE-323: Reusing a Nonce, Key Pair in Encryption

Description:
Nonces should be used for the present occasion and only once.

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

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:
  - [Implementation] Refuse to reuse nonce values.
  - [Implementation] Use techniques such as requiring incrementing, time based and/or challenge response to assure uniqueness of nonces.

Demonstrative examples:
This code takes a password, concatenates it with a nonce, then encrypts it before sending over a network:
Because the nonce used is always the same, an attacker can impersonate a trusted party by intercepting and resending the encrypted password. This attack avoids the need to learn the unencrypted password.
void encryptAndSendPassword(char *password){ char *nonce = "bad"; ... char *data = (unsigned char*)malloc(20); int para_size = strlen(nonce) + strlen(password); char *paragraph = (char*)malloc(para_size); SHA1((const unsigned char*)paragraph,parsize,(unsigned char*)data); sendEncryptedData(data) }

This code sends a command to a remote server, using an encrypted password and nonce to prove the command is from a trusted party:
Once again the nonce used is always the same. An attacker may be able to replay previous legitimate commands or execute new arbitrary commands.
String command = new String("some command to execute"); MessageDigest nonce = MessageDigest.getInstance("SHA"); nonce.update(String.valueOf("bad nonce")); byte[] nonce = nonce.digest(); MessageDigest [CREDENTIAL_REDACTED].getInstance("SHA"); password.update(nonce + "secretPassword"); byte[] digest = password.digest(); sendCommand(digest, command)

Real-world examples:
  - CVE-2024-36289: social networking app reuses a nonce/key pair, allowing MITM attackers to manipulate direct messages
  - CVE-2024-21530: Rust package reuses a nonce/key pair when an object is cloned, which resets the random number generation
CWE-324: Use of a Key Past its Expiration Date

Description:
The product uses a cryptographic key or password past its expiration date, which diminishes its safety significantly by increasing the timing window for cracking attacks against that key.

Extended Description:
While the expiration of keys does not necessarily ensure that they are compromised, it is a significant concern that keys which remain in use for prolonged periods of time have a decreasing probability of integrity. For this reason, it is important to replace keys within a period of time proportional to their strength.

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

Consequences:
  - Access Control: Bypass Protection Mechanism

Mitigations:
  - [Architecture and Design] Adequate consideration should be put in to the user interface in order to notify users previous to the key's expiration, to explain the importance of new key generation and to walk users through the process as painlessly as possible.

Demonstrative examples:
The following code attempts to verify that a certificate is valid.
The code checks if the certificate is not yet valid, but it fails to check if a certificate is past its expiration date, thus treating expired certificates as valid.
if (cert = SSL_get_peer_certificate(ssl)) { 
                         foo=SSL_get_verify_result(ssl); if ((X509_V_OK==foo) || (X509_V_ERRCERT_NOT_YET_VALID==foo)) 
                               
                                  
                                  //do stuff 
                                  
                               
                            
                         
                      }

Real-world examples:
  - CVE-2021-33020: Picture Archiving and Communication System (PACS) system for hospitals uses a cryptographic key or password past its expiration date
CWE-325: Missing Cryptographic Step

Description:
The product does not implement a required step in a cryptographic algorithm, resulting in weaker encryption than advertised by the algorithm.

Affected languages: Not Language-Specific
Affected technologies: Not Technology-Specific
Parent weaknesses: CWE-1240, CWE-573

Consequences:
  - Access Control: Bypass Protection Mechanism
  - Confidentiality: Read Application Data
  - Accountability: Hide Activities

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

Demonstrative examples:
The example code is taken from the HMAC engine inside the buggy OpenPiton SoC of HACK@DAC'21 [REF-1358]. HAMC is a message authentication code (MAC) that uses both a hash and a secret crypto key. The HMAC engine in HACK@DAC SoC uses the SHA-256 module for the calculation of the HMAC for 512 bits messages.
However, this HMAC engine cannot handle messages that are longer than 512 bits. Moreover, a complete HMAC will contain an iterate hash function that breaks up a message into blocks of a fixed size and iterates over them with a compression function (e.g., SHA-256). Therefore, the implementation of the HMAC in OpenPiton SoC is incomplete. Such HMAC engines will not be used in real-world applications as the messages will usually be longer than 512 bits. For instance, OpenTitan offers a compr

Real-world examples:
  - CVE-2001-1585: Missing challenge-response step allows authentication bypass using public key.
CWE-326: Inadequate Encryption Strength

Description:
The product stores or transmits sensitive data using an encryption scheme that is theoretically sound, but is not strong enough for the level of protection required.

Extended Description:
A weak encryption scheme can be subjected to brute force attacks that have a reasonable chance of succeeding using current attack methods and resources.

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

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] Use an encryption scheme that is currently considered to be strong by experts in the field.

Real-world examples:
  - CVE-2001-1546: Weak encryption
  - CVE-2004-2172: Weak encryption (chosen plaintext attack)
  - CVE-2002-1682: Weak encryption
  - CVE-2002-1697: Weak encryption produces same ciphertext from the same plaintext blocks.
  - CVE-2002-1739: Weak encryption
CWE-33: Path Traversal: '....' (Multiple Dot)

Description:
The product uses external input to construct a pathname that should be within a restricted directory, but it does not properly neutralize '....' (multiple 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. 
             The '....' manipulation is useful for bypassing some path traversal protection schemes. On some Windows systems, it is equivalent to "..\..\.." and might bypass checks that assume only two dots are valid. Incomplete filtering, such as removal of "./" sequences, can ultimately produce valid ".." sequences due to a collapse into unsafe value (CWE-182).

Affected languages: Not Language-Specific
Affected technologies: Not Technology-Specific, Web Based
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-2000-0240: read files via "/........../" in URL
  - CVE-2000-0773: read files via "...." in web server
  - CVE-1999-1082: read files via "......" in web server (doubled triple dot?)
  - CVE-2004-2121: read files via "......" in web server (doubled triple dot?)
  - CVE-2001-0491: multiple attacks using "..", "...", and "...." in different commands
CWE-331: Insufficient Entropy

Description:
The product uses an algorithm or scheme that produces insufficient entropy, leaving patterns or clusters of values that are more likely to occur than others.

Affected languages: Not Language-Specific
Parent weaknesses: CWE-330, CWE-330

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:
  - [Implementation] Determine the necessary entropy to adequately provide for randomness and predictability. This can be achieved by increasing the number of bits of objects such as keys and seeds.

Demonstrative examples:
This code generates a unique random identifier for a user's session.
Because the seed for the PRNG is always the user's ID, the session ID will always be the same. An attacker could thus predict any user's session ID and potentially hijack the session.
function generateSessionID($userID){ srand($userID); return rand(); }

The following code uses a statistical PRNG to create a URL for a receipt that remains active for some period of time after a purchase.
This code uses the Random.nextInt() function to generate "unique" identifiers for the receipt pages it generates. Because Random.nextInt() is a statistical PRNG, it is easy for an attacker to guess the strings it generates. Although the underlying design of the receipt system is also faulty, it would be more secure if it used a random number generator that did not produce predictable receipt identifiers, such as a cryptographic PRNG.
String GenerateReceiptURL(String baseUrl) { Random ranGen = new Random(); ranGen.setSeed((new Date()).getTime()); return(baseUrl + ranGen.nextInt(400000000) + ".html"); }

Real-world examples:
  - CVE-2001-0950: Insufficiently random data used to generate session tokens using C rand(). Also, for certificate/key generation, uses a source that does not block when entropy is low.
  - CVE-2008-2108: Chain: insufficient precision (CWE-1339) in
	     random-number generator causes some zero bits to be reliably
	     generated, reducing the amount of entropy (CWE-331)
CWE-332: Insufficient Entropy in PRNG

Description:
The lack of entropy available for, or used by, a Pseudo-Random Number Generator (PRNG) can be a stability and security threat.

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

Consequences:
  - Availability: DoS: Crash, Exit, or Restart
  - 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] Use products or modules that conform to FIPS 140-2 [REF-267] to avoid obvious entropy problems. Consult FIPS 140-2 Annex C ("Approved Random Number Generators").
  - [Implementation] Consider a PRNG that re-seeds itself as needed from high-quality pseudo-random output, such as hardware devices.
  - [Architecture and Design] When deciding which PRNG to use, look at its sources of entropy. Depending on what your security needs are, you may need to use a random number generator that always uses strong random data -- i.e., a random number generator that attempts to be strong but will fail in a weak way or will always provi

Real-world examples:
  - [REF-1374]: Chain: JavaScript-based cryptocurrency library can fall back to the insecure Math.random() function instead of reporting a failure (CWE-392), thus reducing the entropy (CWE-332) and leading to generat
  - CVE-2019-1715: security product has insufficient entropy in the DRBG, allowing collisions and private key discovery
CWE-333: Improper Handling of Insufficient Entropy in TRNG

Description:
True random number generators (TRNG) generally have a limited source of entropy and therefore can fail or block.

Extended Description:
The rate at which true random numbers can be generated is limited. It is important that one uses them only when they are needed for security.

Affected languages: Not Language-Specific
Parent weaknesses: CWE-331, CWE-755

Consequences:
  - Availability: DoS: Crash, Exit, or Restart

Mitigations:
  - [Implementation] Rather than failing on a lack of random numbers, it is often preferable to wait for more numbers to be created.

Demonstrative examples:
This code uses a TRNG to generate a unique session id for new connections to a server:
This code does not attempt to limit the number of new connections or make sure the TRNG can successfully generate a new random number. An attacker may be able to create many new connections and exhaust the entropy of the TRNG. The TRNG may then block and cause the program to crash or hang.
while (1){ 
                         if (haveNewConnection()){ if (hwRandom()){ int sessionID = hwRandom(); createNewConnection(sessionID); } } }
CWE-334: Small Space of Random Values

Description:
The number of possible random values is smaller than needed by the product, making it more susceptible to brute force attacks.

Affected languages: Not Language-Specific
Affected technologies: Not Technology-Specific
Parent weaknesses: CWE-330

Consequences:
  - Access Control: Bypass Protection Mechanism

Mitigations:
  - [Architecture and Design] Use products or modules that conform to FIPS 140-2 [REF-267] to avoid obvious entropy problems. Consult FIPS 140-2 Annex C ("Approved Random Number Generators").

Demonstrative examples:
The following XML example code is a deployment descriptor for a Java web application deployed on a Sun Java Application Server. This deployment descriptor includes a session configuration property for configuring the session ID length.
This deployment descriptor has set the session ID length for this Java web application to 8 bytes (or 64 bits). The session ID length for Java web applications should be set to 16 bytes (128 bits) to prevent attackers from guessing and/or stealing a session ID and taking over a user's session.
<sun-web-app> 
                         ... <session-config> 
                               <session-properties> <property name="idLengthBytes" value="8"> <description>The number of bytes in this web module's session ID.</description> </property> </session-properties>

Real-world examples:
  - CVE-2002-0583: Product uses 5 alphanumeric characters for filenames of expense claim reports, stored under web root.
  - CVE-2002-0903: Product uses small number of random numbers for a code to approve an action, and also uses predictable new user IDs, allowing attackers to hijack new accounts.
  - CVE-2003-1230: SYN cookies implementation only uses 32-bit keys, making it easier to brute force ISN.
  - CVE-2004-0230: Complex predictability / randomness (reduced space).