deardaniel/secdata-raw huggingface dataset:
CWE-180: Incorrect Behavior Order: Validate Before Canonicalize

Description:
The product validates input before it is canonicalized, which prevents the product from detecting data that becomes invalid after the canonicalization step.

Extended Description:
This can be used by an attacker to bypass the validation and launch attacks that expose weaknesses that would otherwise be prevented, such as injection.

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

Consequences:
  - Access Control: Bypass Protection Mechanism

Mitigations:
  - [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

Demonstrative examples:
The following code attempts to validate a given input path by checking it against an allowlist and then return the canonical path. In this specific case, the path is considered valid if it starts with the string "/safe_dir/".
The problem with the above code is that the validation step occurs before canonicalization occurs. An attacker could provide an input path of "/safe_dir/../" that would pass the validation step. However, the canonicalization process sees the double dot as a traversal to the parent directory and hence when canonicized the path would become just "/".
String path = getInputPath(); if (path.startsWith("/safe_dir/")) { File f = new File(path); return f.getCanonicalPath(); }
String path = getInputPath(); File f = new File(path); if (f.getCanonicalPath().startsWith("/safe_di

Real-world examples:
  - CVE-2002-0433: List files in web server using "*.ext"
  - CVE-2003-0332: Product modifies the first two letters of a filename extension after performing a security check, which allows remote attackers to bypass authentication via a filename with a .ats extension instead of
  - CVE-2002-0802: Database consumes an extra character when processing a character that cannot be converted, which could remove an escape character from the query and make the application subject to SQL injection attac
  - CVE-2000-0191: Overlaps "fakechild/../realchild"
  - CVE-2004-2363: Product checks URI for "<" and other literal characters, but does it before hex decoding the URI, so "%3E" and other sequences are allowed.
CWE-181: Incorrect Behavior Order: Validate Before Filter

Description:
The product validates data before it has been filtered, which prevents the product from detecting data that becomes invalid after the filtering step.

Extended Description:
This can be used by an attacker to bypass the validation and launch attacks that expose weaknesses that would otherwise be prevented, such as injection.

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

Consequences:
  - Access Control: Bypass Protection Mechanism

Mitigations:
  - [Implementation] Inputs should be decoded and canonicalized to the application's current internal representation before being filtered.

Demonstrative examples:
This script creates a subdirectory within a user directory and sets the user as the owner.
While the script attempts to screen for '..' sequences, an attacker can submit a directory path including ".~.", which will then become ".." after the filtering step. This allows a Path Traversal (CWE-21) attack to occur.
function createDir($userName,$dirName){ $userDir = '/users/'. $userName; if(strpos($dirName,'..') !== false){ echo 'Directory name contains invalid sequence'; return; } 
                         //filter out '~' because other scripts identify user directories by this prefix 
                         $dirName = str_replace('~','',$dirName); $newDir = $userDir . $dirName; mkdir($newDir, 0700); chown($newDir,$userName); }

Real-world examples:
  - CVE-2002-0934: Directory traversal vulnerability allows remote attackers to read or modify arbitrary files via invalid characters between two . (dot) characters, which are filtered and result in a ".." sequence.
  - CVE-2003-0282: Directory traversal vulnerability allows attackers to overwrite arbitrary files via invalid characters between two . (dot) characters, which are filtered and result in a ".." sequence.
CWE-182: Collapse of Data into Unsafe Value

Description:
The product filters data in a way that causes it to be reduced or "collapsed" into an unsafe value that violates an expected security property.

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

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
  - Canonicalize the name to match that of the file system's representation of the name. This can sometimes be achieved with an available API (e.g. in Win32 the GetFullPathName function).

Real-world examples:
  - CVE-2004-0815: "/.////" in pathname collapses to absolute path.
  - CVE-2005-3123: "/.//..//////././" is collapsed into "/.././" after ".." and "//" sequences are removed.
  - CVE-2002-0325: ".../...//" collapsed to "..." due to removal of "./" in web server.
  - CVE-2002-0784: chain: HTTP server protects against ".." but allows "." variants such as "////./../.../". If the server removes "/.." sequences, the result would collapse into an unsafe value "////../" (CWE-182).
  - CVE-2005-2169: MFV. Regular expression intended to protect against directory traversal reduces ".../...//" to "../".
CWE-183: Permissive List of Allowed Inputs

Description:
The product implements a protection mechanism that relies on a list of inputs (or properties of inputs) that are explicitly allowed by policy because the inputs are assumed to be safe, but the list is too permissive - that is, it allows an input that is unsafe, leading to resultant weaknesses.

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

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

Real-world examples:
  - CVE-2019-12799: chain: bypass of untrusted deserialization issue (CWE-502) by using an assumed-trusted class (CWE-183)
  - CVE-2019-10458: sandbox bypass using a method that is on an allowlist
  - CVE-2[PII_REDACTED]: sandbox bypass using unsafe methods that are on an allowlist
  - CVE-2019-10458: CI/CD pipeline feature has unsafe elements in allowlist, allowing bypass of script restrictions
  - CVE-2[PII_REDACTED]: Default allowlist includes unsafe methods, allowing bypass of sandbox
CWE-184: Incomplete List of Disallowed Inputs

Description:
The product implements a protection mechanism that relies on a list of inputs (or properties of inputs) that are not allowed by policy or otherwise require other action to neutralize before additional processing takes place, but the list is incomplete.

Affected languages: Not Language-Specific
Affected technologies: Not Technology-Specific
Parent weaknesses: CWE-693, CWE-1023

Consequences:
  - Access Control: Bypass Protection Mechanism

Detection methods:
  - Black Box: Exploitation of a vulnerability with commonly-used manipulations might fail, but minor variations might succeed.

Mitigations:
  - [Implementation] Do not rely exclusively on detecting disallowed inputs.  There are too many variants to encode a character, especially when different environments are used, so there is a high likelihood of missing some variants.  Only use detection of disallowed inputs as a mechanism for detecting suspicious activi

Demonstrative examples:
The following code attempts to stop XSS attacks by removing all occurences of "script" in an input string.
Because the code only checks for the lower-case "script" string, it can be easily defeated with upper-case script tags.
public String removeScriptTags(String input, String mask) { return input.replaceAll("script", mask); }

This example takes user input, passes it through an encoding scheme, then lists the contents of the user's home directory based on the user name.
The programmer attempts to encode dangerous characters, however the denylist for encoding is incomplete (CWE-184) and an attacker can still pass a semicolon, resulting in a chain with OS command injection (CWE-78).
sub GetUntrustedInput { return($ARGV[0]); } 
                      sub encode { my($str) = @_; $str =~ s/\&/\&amp;/gs; $str =~ s/\"/\&quot;/gs; $str =~ s/\'/\&apos;/gs; $str =~ s/\</\&lt;/gs; $str =~ s/\>/\&gt;/gs; return($str); } 
                      sub doit { my $uname = encode(GetUntrustedInput("username")); print "<b>Welcome, $uname!</b><p>\n"; system("cd /home/$uname; /bin/ls -l"); 
                      }
' pwd

Real-world examples:
  - CVE-2024-6091: Chain: AI agent platform does not restrict pathnames containing internal "/./" sequences (CWE-55), leading to an incomplete denylist (CWE-184) that does not prevent OS command injection (CWE-78)
  - CVE-2024-4315: Chain: API for text generation using Large Language Models (LLMs) does
			   not include the "\" Windows folder separator in its denylist (CWE-184)
			   when attempting to prevent Local File Inclusio
  - CVE-2024-44335: Chain: filter only checks for some shell-injection characters (CWE-184), enabling OS command injection (CWE-78)
  - CVE-2008-2309: product uses a denylist to identify potentially dangerous content, allowing attacker to bypass a warning
  - CVE-2005-2782: PHP remote file inclusion in web application that filters "http" and "https" URLs, but not "ftp".
CWE-185: Incorrect Regular Expression

Description:
The product specifies a regular expression in a way that causes data to be improperly matched or compared.

Extended Description:
When the regular expression is used in protection mechanisms such as filtering or validation, this may allow an attacker to bypass the intended restrictions on the incoming data.

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

Consequences:
  - Other: Unexpected State
  - 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] Regular expressions can become error prone when defining a complex language even for those experienced in writing grammars. Determine if several smaller regular expressions simplify one large regular expression. Also, subject the regular expression to thorough testing techniques such as equivalence 

Demonstrative examples:
The following code takes phone numbers as input, and uses a regular expression to reject invalid phone numbers.
An attacker could provide an argument such as: "; ls -l ; echo 123-456" This would pass the check, since "123-456" is sufficient to match the "\d+-\d+" portion of the regular expression.
$phone = GetPhoneNumber(); if ($phone =~ /\d+-\d+/) { 
                         # looks like it only has hyphens and digits 
                         system("lookup-phone $phone"); }
				   else { error("malformed number!"); }

This code uses a regular expression to validate an IP string prior to using it in a call to the "ping" command.
Since the regular expression does not have anchors (CWE-777), i.e. is unbounded without ^ or $ characters, then prepending a 0 or 0x to the beginning of the IP address will still result in a matched regex pattern. Since the ping command supports octal and hex prepended IP addresses, it will use the unexpectedly valid IP address (CWE-1389). For example, "0x63.63.63.63" would be considered equivalent to "99.63.63.63". As a result, the attacker could potentially ping systems that the attacker cannot reach directly.
import subprocess 
		  import re 
		   
		  def validate_ip_regex(ip: str): 
		   
		    ip_validator = re.compile(r"((25[0-5]|(2[0-4]|1\d|[1-9]|)\d)\.?\b){4}") 
		    if

Real-world examples:
  - CVE-2002-2109: Regexp isn't "anchored" to the beginning or end, which allows spoofed values that have trusted values as substrings.
  - CVE-2005-1949: Regexp for IP address isn't anchored at the end, allowing appending of shell metacharacters.
  - CVE-2001-1072: Bypass access restrictions via multiple leading slash, which causes a regular expression to fail.
  - CVE-2000-0115: Local user DoS via invalid regular expressions.
  - CVE-2002-1527: chain: Malformed input generates a regular expression error that leads to information exposure.
CWE-186: Overly Restrictive Regular Expression

Description:
A regular expression is overly restrictive, which prevents dangerous values from being detected.

Extended Description:
This weakness is not about regular expression complexity. Rather, it is about a regular expression that does not match all values that are intended. Consider the use of a regexp to identify acceptable values or to spot unwanted terms. An overly restrictive regexp misses some potentially security-relevant values leading to either false positives *or* false negatives, depending on how the regexp is being used within the code. Consider the expression /[0-8]/ where the intention was /[0-9]/.  This expression is not "complex" but the value "9" is not matched when maybe the programmer planned to check for it.

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

Consequences:
  - Access Control: Bypass Protection Mechanism

Mitigations:
  - [Implementation] Regular expressions can become error prone when defining a complex language even for those experienced in writing grammars. Determine if several smaller regular expressions simplify one large regular expression. Also, subject your regular expression to thorough testing techniques such as equivalence

Real-world examples:
  - CVE-2005-1604: MIE. ".php.ns" bypasses ".php$" regexp but is still parsed as PHP by Apache. (manipulates an equivalence property under Apache)
CWE-187: Partial String Comparison

Description:
The product performs a comparison that only examines a portion of a factor before determining whether there is a match, such as a substring, leading to resultant weaknesses.

Extended Description:
For example, an attacker might succeed in authentication by providing a small password that matches the associated portion of the larger, correct password.

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

Consequences:
  - Integrity: Alter Execution Logic

Mitigations:
  - [Testing] Thoroughly test the comparison scheme before deploying code into production. Perform positive testing as well as negative testing.

Demonstrative examples:
This example defines a fixed username and password. The AuthenticateUser() function is intended to accept a username and a password from an untrusted user, and check to ensure that it matches the username and password. If the username and password match, AuthenticateUser() is intended to indicate that authentication succeeded.
In AuthenticateUser(), the strncmp() call uses the string length of an attacker-provided inPass parameter in order to determine how many characters to check in the password. So, if the attacker only provides a password of length 1, the check will only examine the first byte of the application's password before determining success.
/* Ignore CWE-259 (hard-coded password) and CWE-309 (use of password system for authentication) for this example. */ 
                    

Real-world examples:
  - CVE-2014-6394: Product does not prevent access to restricted directories due to partial string comparison with a public directory
  - CVE-2004-1012: Argument parser of an IMAP server treats a partial command "body[p" as if it is "body.peek", leading to index error and out-of-bounds corruption.
  - CVE-2004-0765: Web browser only checks the hostname portion of a certificate when the hostname portion of the URI is not a fully qualified domain name (FQDN), which allows remote attackers to spoof trusted certifica
  - CVE-2002-1374: One-character password by attacker checks only against first character of real password.
  - CVE-2000-0979: One-character password by attacker checks only against first character of real password.
CWE-188: Reliance on Data/Memory Layout

Description:
The product makes invalid assumptions about how protocol data or memory is organized at a lower level, resulting in unintended program behavior.

Extended Description:
When changing platforms or protocol versions, in-memory organization of data may change in unintended ways. For example, some architectures may place local variables A and B right next to each other with A on top; some may place them next to each other with B on top; and others may add some padding to each. The padding size may vary to ensure that each variable is aligned to a proper word size. 
             In protocol implementations, it is common to calculate an offset relative to another field to pick out a specific piece of data. Exceptional conditions, often involving new protocol versions, may add corner cases that change the data layout in an unusual way. The result can be that an implementation accesses an unintended field in the packet, treating data of one type as data of another type.

Affected languages: Not Language-Specific, C, C++
Parent weaknesses: CWE-1105, CWE-435

Consequences:
  - Integrity: Modify Memory

Detection methods:
  - Fuzzing: Fuzz testing (fuzzing) is a powerful technique for generating large numbers of diverse inputs - either randomly or algorithmically - and dynamically invoking the code with those inputs. Even with rand
  - Automated Dynamic Analysis: Use tools that are integrated during
	     compilation to insert runtime error-checking mechanisms
	     related to memory safety errors, such as AddressSanitizer
	     (ASan) for C/C++ [REF-1518].

Mitigations:
  - [Implementation] In flat address space situations, never allow computing memory addresses as offsets from another memory address.
  - [Architecture and Design] Fully specify protocol layout unambiguously, providing a structured grammar (e.g., a compilable yacc grammar).
  - [Testing] Testing: Test that the implementation properly handles each case in the protocol grammar.

Demonstrative examples:
In this example function, the memory address of variable b is derived by adding 1 to the address of variable a. This derived address is then used to assign the value 0 to b.
Here, b may not be one byte past a. It may be one byte in front of a. Or, they may have three bytes between them because they are aligned on 32-bit boundaries.
void example() { char a; char b; *(&a + 1) = 0; }
CWE-191: Integer Underflow (Wrap or Wraparound)

Description:
The product subtracts one value from another, such that the result is less than the minimum allowable integer value, which produces a value that is not equal to the correct result.

Extended Description:
This can happen in signed and unsigned cases.

Affected languages: C, C++, Java, C#
Parent weaknesses: CWE-682, CWE-682

Consequences:
  - Availability: DoS: Crash, Exit, or Restart
  - Integrity: Modify Memory
  - Confidentiality: Execute Unauthorized Code or Commands

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 following example subtracts from a 32 bit signed integer.
The example has an integer underflow. The value of i is already at the lowest negative value possible, so after subtracting 1, the new value of i is[PII_REDACTED].
#include <stdio.h> #include <stdbool.h> main (void) { int i; i = [PII_REDACTED]; i = i - 1; return 0; }

This code performs a stack allocation based on a length calculation.
Since a and b are declared as signed ints, the "a - b" subtraction gives a negative result (-1). However, since len is declared to be unsigned, len is cast to an extremely large positive number (on 32-bit systems -[PII_REDACTED]). As a result, the buffer buf[len] declaration uses an extremely large size to allocate on the stack, very likely more than the entire computer's memory space.
int a = 5, b = 6; 
		    size_t len = a - b; 
		    char buf[len];    // Just blows up the stack
		   
		  }

Real-world examples:
  - CVE-2004-0816: Integer underflow in firewall via malformed packet.
  - CVE-2004-1002: Integer underflow by packet with invalid length.
  - CVE-2005-0199: Long input causes incorrect length calculation.
  - CVE-2005-1891: Malformed icon causes integer underflow in loop counter variable.