deardaniel/secdata-raw huggingface dataset:
CWE-369: Divide By Zero

Description:
The product divides a value by zero.

Extended Description:
This weakness typically occurs when an unexpected value is provided to the product, or if an error occurs that is not properly detected. It frequently occurs in calculations involving physical dimensions such as size, length, width, and height.

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

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
  - 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

Demonstrative examples:
The following Java example contains a function to compute an average but does not validate that the input value used as the denominator is not zero. This will create an exception for attempting to divide by zero. If this error is not handled by Java exception handling, unexpected results can occur.
By validating the input value used as the denominator the following code will ensure that a divide by zero error will not cause unexpected results. The following Java code example will validate the input value, output an error message, and throw an exception.
public int computeAverageResponseTime (int totalTime, int numRequests) { return totalTime / numRequests; }
public int computeAverageResponseTime (int totalTime, int numRequests) throws ArithmeticException { if (numRequests == 0) { System.ou

The following C/C++ example contains a function that divides two numeric values without verifying that the input value used as the denominator is not zero. This will create an error for attempting to divide by zero, if this error is not caught by the error handling capabilities of the language, unexpected results can occur.
By validating the input value used as the denominator the following code will ensure that a divide by zero error will not cause unexpected results. If the method is called and a zero is passed as the second argument a DivideByZero error will be thrown and should be caught by the calling block with an output message indicating the error.
double divide(double x, double y){ return x/y; }
const int DivideByZero = 10; double divide(double x, double y){ if ( 0 == y ){ throw D

Real-world examples:
  - CVE-2007-3268: Invalid size value leads to divide by zero.
  - CVE-2007-2723: "Empty" content triggers divide by zero.
  - CVE-2007-2237: Height value of 0 triggers divide by zero.
CWE-37: Path Traversal: '/absolute/pathname/here'

Description:
The product accepts input in the form of a slash absolute path ('/absolute/pathname/here') without appropriate validation, which can allow an attacker to traverse the file system to unintended locations or access arbitrary files.

Affected languages: Not Language-Specific
Parent weaknesses: CWE-36, CWE-160

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-1345: Multiple FTP clients write arbitrary files via absolute paths in server responses
  - CVE-2001-1269: ZIP file extractor allows full path
  - CVE-2002-1818: Path traversal using absolute pathname
  - CVE-2002-1913: Path traversal using absolute pathname
  - CVE-2005-2147: Path traversal using absolute pathname
CWE-370: Missing Check for Certificate Revocation after Initial Check

Description:
The product does not check the revocation status of a certificate after its initial revocation check, which can cause the product to perform privileged actions even after the certificate is revoked at a later time.

Extended Description:
If the revocation status of a certificate is not checked before each action that requires privileges, the system may be subject to a race condition. If a certificate is revoked after the initial check, all subsequent actions taken with the owner of the revoked certificate will lose all benefits guaranteed by the certificate. In fact, it is almost certain that the use of a revoked certificate indicates malicious activity.

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

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

Mitigations:
  - [Architecture and Design] Ensure that certificates are checked for revoked status before each use of a protected resource. If the certificate is checked before each access of a protected resource, the delay subject to a possible race condition becomes almost negligible and significantly reduces the risk associated with this 

Demonstrative examples:
The following code checks a certificate before performing an action.
While the code performs the certificate verification before each action, it does not check the result of the verification after the initial attempt. The certificate may have been revoked in the time between the privileged actions.
if (cert = SSL_get_peer_certificate(ssl)) { 
                         foo=SSL_get_verify_result(ssl); if (X509_V_OK==foo) 
                               
                                  
                                  //do stuff 
                                  foo=SSL_get_verify_result(ssl); 
                                  //do more stuff without the check.
CWE-372: Incomplete Internal State Distinction

Description:
The product does not properly determine which state it is in, causing it to assume it is in state X when in fact it is in state Y, causing it to perform incorrect operations in a security-relevant manner.

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

Consequences:
  - Integrity: Varies by Context
CWE-374: Passing Mutable Objects to an Untrusted Method

Description:
The product sends non-cloned mutable data as an argument to a method or function.

Extended Description:
The function or method that has been called can alter or delete the mutable data. This could violate assumptions that the calling function has made about its state. In situations where unknown code is called with references to mutable data, this external code could make changes to the data sent. If this data was not previously cloned, the modified data might not be valid in the context of execution.

Affected languages: Object-Oriented, C, C++, Java, C#
Parent weaknesses: CWE-668

Consequences:
  - Integrity: Modify Memory

Mitigations:
  - [Implementation] Pass in data which should not be altered as constant or immutable.
  - [Implementation] Clone all mutable data before passing it into an external function . This is the preferred mitigation. This way, regardless of what changes are made to the data, a valid copy is retained for use by the class.

Demonstrative examples:
The following example demonstrates the weakness.
In this example, bar and baz will be passed by reference to doOtherStuff() which may change them.
private: int foo; complexType bar; String baz; otherClass externalClass; 
                      
                      public: void doStuff() { externalClass.doOtherStuff(foo, bar, baz) }

In the following Java example, the BookStore class manages the sale of books in a bookstore, this class includes the member objects for the bookstore inventory and sales database manager classes. The BookStore class includes a method for updating the sales database and inventory when a book is sold. This method retrieves a Book object from the bookstore inventory object using the supplied ISBN number for the book class, then calls a method for the sales object to update the sales information and then calls a method for the inventory object to update inventory for the BookStore.
However, in this example the Book object that is retrieved and passed to the method of the sales object could have its contents modified by the method. This could cause unexpected results when the book object is sen
CWE-375: Returning a Mutable Object to an Untrusted Caller

Description:
Sending non-cloned mutable data as a return value may result in that data being altered or deleted by the calling function.

Extended Description:
In situations where functions return references to mutable data, it is possible that the external code which called the function may make changes to the data sent. If this data was not previously cloned, the class will then be using modified data which may violate assumptions about its internal state.

Affected languages: Object-Oriented, C, C++, Java, C#
Parent weaknesses: CWE-668

Consequences:
  - Access Control: Modify Memory

Mitigations:
  - [Implementation] Declare returned data which should not be altered as constant or immutable.
  - [Implementation] Clone all mutable data before returning references to it. This is the preferred mitigation. This way, regardless of what changes are made to the data, a valid copy is retained for use by the class.

Demonstrative examples:
This class has a private list of patients, but provides a way to see the list :
While this code only means to allow reading of the patient list, the getPatients() method returns a reference to the class's original patient list instead of a reference to a copy of the list. Any caller of this method can arbitrarily modify the contents of the patient list even though it is a private member of the class.
public class ClinicalTrial { private PatientClass[] patientList = new PatientClass[50]; public getPatients(...){ return patientList; } }
CWE-377: Insecure Temporary File

Description:
Creating and using insecure temporary files can leave application and system data vulnerable to attack.

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

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:
The following code uses a temporary file for storing intermediate data gathered from the network before it is processed.
This otherwise unremarkable code is vulnerable to a number of different attacks because it relies on an insecure method for creating temporary files. The vulnerabilities introduced by this function and others are described in the following sections. The most egregious security problems related to temporary file creation have occurred on Unix-based operating systems, but Windows applications have parallel risks. This section includes a discussion of temporary file creation on both Unix and Windows systems. Methods and behaviors can vary between systems, but the fundamental risks introduced by each are reasonably constant.
if (tmpnam_r(filename)) { 
                       

Real-world examples:
  - CVE-2022-41954: A library uses the Java File.createTempFile() method which creates a file with "-rw-r--r--" default permissions on Unix-like operating systems
CWE-378: Creation of Temporary File With Insecure Permissions

Description:
Opening temporary files without appropriate measures or controls can leave the file, its contents and any function that it impacts vulnerable to attack.

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

Consequences:
  - Confidentiality: Read Application Data
  - Authorization: Other
  - Integrity: Other

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:
  - [Requirements] Many contemporary languages have functions which properly handle this condition. Older C temp file functions are especially susceptible.
  - [Implementation] Ensure that you use proper file permissions. This can be achieved by using a safe temp file function. Temporary files should be writable and readable only by the process that owns the file.
  - [Implementation] Randomize temporary file names. This can also be achieved by using a safe temp-file function. This will ensure that temporary files will not be created in predictable places.

Demonstrative examples:
In the following code examples a temporary file is created and written to.  After using the temporary file, the file is closed and deleted from the file system.
However, within this C/C++ code the method tmpfile() is used to create and open the temp file. The tmpfile() method works the same way as the fopen() method would with read/write permission, allowing attackers to read potentially sensitive information contained in the temp file or modify the contents of the file.
FILE *stream; if( (stream = tmpfile()) == NULL ) { 
                         
                            perror("Could not open new temporary file\n"); return (-1); 
                      } 
                      // write data to tmp file 
                      ... // remove tmp file rmtmp();
try { File temp = File.create

Real-world examples:
  - CVE-2022-24823: A network application framework uses the Java function createTempFile(), which will create a file that is readable by other local users of the system
CWE-379: Creation of Temporary File in Directory with Insecure Permissions

Description:
The product creates a temporary file in a directory whose permissions allow unintended actors to determine the file's existence or otherwise access that file.

Extended Description:
On some operating systems, the fact that the temporary file exists may be apparent to any user with sufficient privileges to access that directory. Since the file is visible, the application that is using the temporary file could be known. If one has access to list the processes on the system, the attacker has gained information about what the user is doing at that time. By correlating this with the applications the user is running, an attacker could potentially discover what a user's actions are. From this, higher levels of security could be breached.

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

Consequences:
  - 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:
  - [Requirements] Many contemporary languages have functions which properly handle this condition. Older C temp file functions are especially susceptible.
  - [Implementation] Try to store sensitive tempfiles in a directory which is not world readable -- i.e., per-user directories.
  - [Implementation] Avoid using vulnerable temp file functions.

Demonstrative examples:
In the following code examples a temporary file is created and written to.  After using the temporary file, the file is closed and deleted from the file system.
However, within this C/C++ code the method tmpfile() is used to create and open the temp file. The tmpfile() method works the same way as the fopen() method would with read/write permission, allowing attackers to read potentially sensitive information contained in the temp file or modify the contents of the file.
FILE *stream; if( (stream = tmpfile()) == NULL ) { 
                         
                            perror("Could not open new temporary file\n"); return (-1); 
                      } 
                      // write data to tmp file 
                      ... // remove tmp file rmtmp();
try { File temp = File.create

Real-world examples:
  - CVE-2022-27818: A hotkey daemon written in Rust creates a domain socket file underneath /tmp, which is accessible by any user.
  - CVE-2021-41989: analytic platform's repair functionality uses the %TEMP% folder of a user while running with higher privileges
  - CVE-2021-21290: A Java-based application for a rapid-development framework uses File.createTempFile() to create a random temporary file with insecure default permissions.
CWE-38: Path Traversal: '\absolute\pathname\here'

Description:
The product accepts input in the form of a backslash absolute path ('\absolute\pathname\here') without appropriate validation, which can allow an attacker to traverse the file system to unintended locations or access arbitrary files.

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

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-1999-1263: Mail client allows remote attackers to overwrite arbitrary files via an e-mail message containing a uuencoded attachment that specifies the full pathname for the file to be modified.
  - CVE-2003-0753: Remote attackers can read arbitrary files via a full pathname to the target file in config parameter.
  - CVE-2002-1525: Remote attackers can read arbitrary files via an absolute pathname.
CWE-382: J2EE Bad Practices: Use of System.exit()

Description:
A J2EE application uses System.exit(), which also shuts down its container.

Extended Description:
It is never a good idea for a web application to attempt to shut down the application container. Access to a function that can shut down the application is an avenue for Denial of Service (DoS) attacks.

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

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

Mitigations:
  - [Architecture and Design] The shutdown function should be a privileged function available only to a properly authorized administrative user
  - [Implementation] Web applications should not call methods that cause the virtual machine to exit, such as System.exit()
  - [Implementation] Web applications should also not throw any Throwables to the application server as this may adversely affect the container.
  - [Implementation] Non-web applications may have a main() method that contains a System.exit(), but generally should not call System.exit() from other locations in the code

Demonstrative examples:
Included in the doPost() method defined below is a call to System.exit() in the event of a specific exception.

Public void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { try { ... } catch (ApplicationSpecificException ase) { logger.error("Caught: " + ase.toString()); System.exit(1); } }
CWE-383: J2EE Bad Practices: Direct Use of Threads

Description:
Thread management in a Web application is forbidden in some circumstances and is always highly error prone.

Extended Description:
Thread management in a web application is forbidden by the J2EE standard in some circumstances and is always highly error prone. Managing threads is difficult and is likely to interfere in unpredictable ways with the behavior of the application container. Even without interfering with the container, thread management usually leads to bugs that are hard to detect and diagnose like deadlock, race conditions, and other synchronization errors.

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

Mitigations:
  - [Architecture and Design] For EJB, use framework approaches for parallel execution, instead of using threads.

Demonstrative examples:
In the following example, a new Thread object is created and invoked directly from within the body of a doGet() method in a Java servlet.

public void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { 
                         
                            
                            // Perform servlet tasks. 
                            ... 
                            
                            // Create a new thread to handle background processing. 
                            Runnable r = new Runnable() { 
                               public void run() { 
                                     
                                        
                                        // Process and store request statistics.