deardaniel/secdata-raw huggingface dataset:
CWE-24: Path Traversal: '../filedir'

Description:
The product uses external input to construct a pathname that should be within a restricted directory, but it does not properly neutralize "../" 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 the canonical manipulation for operating systems that use "/" as directory separators, such as UNIX- and Linux-based systems. In some cases, it is useful for bypassing protection schemes in environments for which "/" is supported but not the primary separator, such as Windows, which uses "\" but can also accept "/".

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-2022-45918: Chain: a learning management tool debugger uses external input to locate previous session logs (CWE-73) and does not properly validate the given path (CWE-20), allowing for filesystem path traversal u
CWE-240: Improper Handling of Inconsistent Structural Elements

Description:
The product does not handle or incorrectly handles when two or more structural elements should be consistent, but are not.

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

Consequences:
  - Integrity: Varies by Context

Demonstrative examples:
In the following C/C++ example the method processMessageFromSocket() will get a message from a socket, placed into a buffer, and will parse the contents of the buffer into a structure that contains the message length and the message body. A for loop is used to copy the message body into a local character string which will be passed to another method for processing.
However, the message length variable (msgLength) from the structure is used as the condition for ending the for loop without validating that msgLength accurately reflects the actual length of the message body (CWE-606). If msgLength indicates a length that is longer than the size of a message body (CWE-130), then this can result in a buffer over-read by reading past the end of the buffer (CWE-126).
int processMessageFromSocket(i

Real-world examples:
  - CVE-2014-0160: Chain: "Heartbleed" bug receives an inconsistent length parameter (CWE-130) enabling an out-of-bounds read (CWE-126), returning memory that could include private cryptographic keys and other sensitive
  - CVE-2009-2299: Web application firewall consumes excessive memory when an HTTP request contains a large Content-Length value but no POST data.
CWE-241: Improper Handling of Unexpected Data Type

Description:
The product does not handle or incorrectly handles when a particular element is not the expected type, e.g. it expects a digit (0-9) but is provided with a letter (A-Z).

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

Consequences:
  - Integrity: Varies by Context

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-1999-1156: FTP server crash via PORT command with non-numeric character.
  - CVE-2004-0270: Anti-virus product has assert error when line length is non-numeric.
CWE-242: Use of Inherently Dangerous Function

Description:
The product calls a function that can never be guaranteed to work safely.

Extended Description:
Certain functions behave in dangerous ways regardless of how they are used. Functions in this category were often implemented without taking security concerns into account. The gets() function is unsafe because it does not perform bounds checking on the size of its input. An attacker can easily send arbitrarily-sized input to gets() and overflow the destination buffer. Similarly, the >> operator is unsafe to use when reading into a statically-allocated character array because it does not perform bounds checking on the size of its input. An attacker can easily send arbitrarily-sized input to the >> operator and overflow the destination buffer.

Affected languages: C, C++
Parent weaknesses: CWE-1177

Consequences:
  - Other: Varies by Context

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:
  - [Build and Compilation] Identify a list of prohibited API functions and prohibit developers from using these functions, providing safer alternatives. In some cases, automatic code analysis tools or the compiler can be instructed to spot use of prohibited functions, such as the "banned.h" include file from Microsoft's SDL. 
  - [Testing] Use grep or static analysis tools to spot usage of dangerous functions.

Demonstrative examples:
The code below calls gets() to read information into a buffer.
The gets() function in C is inherently unsafe.
char buf[BUFSIZE]; gets(buf);

The code below calls the gets() function to read in data from the command line.
However, gets() is inherently unsafe, because it copies all input from STDIN to the buffer without checking size. This allows the user to provide a string that is larger than the buffer size, resulting in an overflow condition.
char buf[24]; printf("Please enter your name and press <Enter>\n"); gets(buf); ... }

Real-world examples:
  - CVE-2007-4004: FTP client uses inherently insecure gets() function and is setuid root on some systems, allowing buffer overflow
CWE-243: Creation of chroot Jail Without Changing Working Directory

Description:
The product uses the chroot() system call to create a jail, but does not change the working directory afterward. This does not prevent access to files outside of the jail.

Extended Description:
Improper use of chroot() may allow attackers to escape from the chroot jail. The chroot() function call does not change the process's current working directory, so relative paths may still refer to file system resources outside of the chroot jail after chroot() has been called.

Affected languages: C, C++
Parent weaknesses: CWE-573, CWE-669

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

Demonstrative examples:
Consider the following source code from a (hypothetical) FTP server:
This code is responsible for reading a filename from the network, opening the corresponding file on the local machine, and sending the contents over the network. This code could be used to implement the FTP GET command. The FTP server calls chroot() in its initialization routines in an attempt to prevent access to files outside of /var/ftproot. But because the server does not change the current working directory by calling chdir("/"), an attacker could request the file "../../../../../etc/passwd" and obtain a copy of the system password file.
chroot("/var/ftproot"); ... fgets(filename, sizeof(filename), network); localfile = fopen(filename, "r"); while ((len = fread(buf, 1, sizeof(buf), localfile)) != EOF) { fwrite(buf, 1
CWE-244: Improper Clearing of Heap Memory Before Release ('Heap Inspection')

Description:
Using realloc() to resize buffers that store sensitive information can leave the sensitive information exposed to attack, because it is not removed from memory.

Extended Description:
When sensitive data such as a password or an encryption key is not removed from memory, it could be exposed to an attacker using a "heap inspection" attack that reads the sensitive data using memory dumps or other methods. The realloc() function is commonly used to increase the size of a block of allocated memory. This operation often requires copying the contents of the old memory block into a new and larger block. This operation leaves the contents of the original block intact but inaccessible to the program, preventing the program from being able to scrub sensitive data from memory. If an attacker can later examine the contents of a memory dump, the sensitive data could be exposed.

Affected languages: Memory-Unsafe, C, C++
Parent weaknesses: CWE-226

Consequences:
  - Confidentiality: Read Memory

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 code calls realloc() on a buffer containing sensitive data:
There is an attempt to scrub the sensitive data from memory, but realloc() is used, so it could return a pointer to a different part of memory. The memory that was originally allocated for cleartext_buffer could still contain an uncleared copy of the data.
cleartext_buffer = get_secret();... cleartext_buffer = realloc(cleartext_buffer, 1024); ... scrub_memory(cleartext_buffer, 1024);

Real-world examples:
  - CVE-2019-3733: Cryptography library does not clear heap memory before release
CWE-245: J2EE Bad Practices: Direct Management of Connections

Description:
The J2EE application directly manages connections, instead of using the container's connection management facilities.

Extended Description:
The J2EE standard forbids the direct management of connections. It requires that applications use the container's resource management facilities to obtain connections to resources. Every major web application container provides pooled database connection management as part of its resource management framework. Duplicating this functionality in an application is difficult and error prone, which is part of the reason it is forbidden under the J2EE standard.

Affected languages: Java
Affected technologies: Web Based, Web Server
Parent weaknesses: CWE-695

Consequences:
  - Other: Quality Degradation

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:
In the following example, the class DatabaseConnection opens and manages a connection to a database for a J2EE application. The method openDatabaseConnection opens a connection to the database using a DriverManager to create the Connection object conn to the database specified in the string constant CONNECT_STRING.
The use of the DriverManager class to directly manage the connection to the database violates the J2EE restriction against the direct management of connections. The J2EE application should use the web application container's resource management facilities to obtain a connection to the database as shown in the following example.
public class DatabaseConnection { 
                         private static final String CONNECT_STRING = "jdbc:mysql://localhost:3306/mysqldb"; private C
CWE-246: J2EE Bad Practices: Direct Use of Sockets

Description:
The J2EE application directly uses sockets instead of using framework method calls.

Extended Description:
The J2EE standard permits the use of sockets only for the purpose of communication with legacy systems when no higher-level protocol is available. Authoring your own communication protocol requires wrestling with difficult security issues. 
             Without significant scrutiny by a security expert, chances are good that a custom communication protocol will suffer from security problems. Many of the same issues apply to a custom implementation of a standard protocol. While there are usually more resources available that address security concerns related to implementing a standard protocol, these resources are also available to attackers.

Affected languages: Java
Parent weaknesses: CWE-695

Consequences:
  - Other: Quality Degradation

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 framework method calls instead of using sockets directly.

Demonstrative examples:
The following example opens a socket to connect to a remote server.
A Socket object is created directly within the Java servlet, which is a dangerous way to manage remote connections.
public void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { 
                         
                            
                            // Perform servlet tasks. 
                            ... 
                            
                            // Open a socket to a remote server (bad). 
                            Socket sock = null; 
                            try { 
                               sock = new Socket(remoteHostname, 3000); 
                                  
                                  // Do something with the socke
CWE-248: Uncaught Exception

Description:
An exception is thrown from a function, but it is not caught.

Extended Description:
When an exception is not caught, it may cause the program to crash or expose sensitive information.

Affected languages: C++, Java, C#
Parent weaknesses: CWE-705, CWE-755, CWE-703, CWE-703

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

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 attempts to resolve a hostname.
A DNS lookup failure will cause the Servlet to throw an exception.
protected void doPost (HttpServletRequest req, HttpServletResponse res) throws IOException { String ip = req.getRemoteAddr(); InetAddress addr = InetAddress.getByName(ip); ... out.println("hello " + addr.getHostName()); }

The _alloca() function allocates memory on the stack. If an allocation request is too large for the available stack space, _alloca() throws an exception. If the exception is not caught, the program will crash, potentially enabling a denial of service attack. _alloca() has been deprecated as of Microsoft Visual Studio 2005(R). It has been replaced with the more secure _alloca_s().

Real-world examples:
  - CVE-2023-41151: SDK for OPC Unified Architecture (OPC UA) server has uncaught exception when a socket is blocked for writing but the server tries to send an error
  - CVE-2023-21087: Java code in a smartphone OS can encounter a "boot loop" due to an uncaught exception
CWE-25: Path Traversal: '/../filedir'

Description:
The product uses external input to construct a pathname that should be within a restricted directory, but it does not properly neutralize "/../" 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. 
             Sometimes a program checks for "../" at the beginning of the input, so a "/../" can bypass that check.

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-2022-20775: A cloud management tool allows attackers to bypass the restricted shell using path traversal sequences like "/../" in the USER environment variable.
CWE-253: Incorrect Check of Function Return Value

Description:
The product incorrectly checks a return value from a function, which prevents it from detecting errors or exceptional conditions.

Extended Description:
Important and common functions will return some value about the success of its actions. This will alert the program whether or not to handle any errors caused by that function.

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

Consequences:
  - Availability: Unexpected State

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 a language or compiler that uses exceptions and requires the catching of those exceptions.
  - [Implementation] Properly check all functions which return a value.
  - [Implementation] When designing any function make sure you return a value or throw an exception in case of an error.

Demonstrative examples:
This code attempts to allocate memory for 4 integers and checks if the allocation succeeds.
The code assumes that only a negative return value would indicate an error, but malloc() may return a null pointer when there is an error. The value of tmp could then be equal to 0, and the error would be missed.
tmp = malloc(sizeof(int) * 4); if (tmp < 0 ) { 
                         perror("Failure"); 
                            //should have checked if the call returned 0 
                            
                         
                      }

Real-world examples:
  - CVE-2023-49286: Chain: function in web caching proxy does not correctly check a return value (CWE-253) leading to a reachable assertion (CWE-617)
CWE-256: Plaintext Storage of a Password

Description:
The product stores a password in plaintext within resources such as memory or files.

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

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] Avoid storing passwords in easily accessible locations.
  - [Architecture and Design] Consider storing cryptographic hashes of passwords as an alternative to storing in plaintext.
  - A programmer might attempt to remedy the password management problem by obscuring the password with an encoding function, such as base 64 encoding, but this effort does not adequately protect the password because the encoding can be detected and decoded easily.

Demonstrative examples:
The following code reads a password from a properties file and uses the password to connect to a database.
This code will run successfully, but anyone who has access to config.properties can read the value of password. If a devious employee has access to this information, they can use it to break into the system.
... Properties prop = new Properties(); prop.load(new FileInputStream("config.properties")); String password = prop.getProperty("password"); DriverManager.getConnection(url, usr, password); ...

The following code reads a password from the registry and uses the password to create a new network credential.
This code will run successfully, but anyone who has access to the registry key used to store the password can read the value of password. If a devious employee has access to this information, they can use it to break into the system
... String [CREDENTIAL_REDACTED].GetValue(passKey).toString(); NetworkCredential netCred = new NetworkCredential(username,password,domain); ...

Real-world examples:
  - CVE-2022-30275: Remote Terminal Unit (RTU) uses a driver that relies on a password stored in plaintext.