deardaniel/secdata-raw huggingface dataset:
CWE-478: Missing Default Case in Multiple Condition Expression

Description:
The code does not have a default case in an expression with multiple conditions, such as a switch statement.

Extended Description:
If a multiple-condition expression (such as a switch in C) omits the default case but does not consider or handle all possible values that could occur, then this might lead to complex logical errors and resultant weaknesses. Because of this, further decisions are made based on poor information, and cascading failure results. This cascading failure may result in any number of security issues, and constitutes a significant failure in the system.

Affected languages: C, C++, Java, C#, Python, JavaScript
Parent weaknesses: CWE-1023

Consequences:
  - Integrity: 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:
  - [Implementation] Ensure that there are no cases unaccounted for when adjusting program flow or values based on the value of a given variable. In the case of switch style statements, the very simple act of creating a default case can, if done correctly, mitigate this situation. Often however, the default case is used

Demonstrative examples:
The following does not properly check the return code in the case where the security_check function returns a -1 value when an error occurs. If an attacker can supply data that will invoke an error, the attacker can bypass the security check:
Instead a default label should be used for unaccounted conditions:
#define FAILED 0 #define PASSED 1 int result; ... result = security_check(data); switch (result) { 
                         case FAILED: printf("Security check failed!\n"); exit(-1); 
                               //Break never reached because of exit() 
                               break; 
                            case PASSED: printf("Security check passed.\n"); break; 
                         
                      } 
                      // program execution continues... 
 

In the following Java example the method getInterestRate retrieves the interest rate for the number of points for a mortgage. The number of points is provided within the input parameter and a switch statement will set the interest rate value to be returned based on the number of points.
However, this code assumes that the value of the points input parameter will always be 0, 1 or 2 and does not check for other incorrect values passed to the method. This can be easily accomplished by providing a default label in the switch statement that outputs an error message indicating an invalid value for the points input parameter and returning a null value.
public static final String INTEREST_RATE_AT_ZERO_POINTS = "5.00"; public static final String INTEREST_RATE_AT_ONE_POINTS = "4.75"; public static
CWE-479: Signal Handler Use of a Non-reentrant Function

Description:
The product defines a signal handler that calls a non-reentrant function.

Extended Description:
Non-reentrant functions are functions that cannot safely be called, interrupted, and then recalled before the first call has finished without resulting in memory corruption. This can lead to an unexpected system state and unpredictable results with a variety of potential consequences depending on context, including denial of service and code execution. 
             Many functions are not reentrant, but some of them can result in the corruption of memory if they are used in a signal handler. The function call syslog() is an example of this. In order to perform its functionality, it allocates a small amount of memory as "scratch space." If syslog() is suspended by a signal call and the signal handler calls syslog(), the memory used by both of these functions enters an undefined, and possibly, exploitable state. Implementations of malloc() and free() manage metadata in global structures in order to track which memory is allocated versus which memory is available, but they are non-reentra

Affected languages: C, C++
Parent weaknesses: CWE-828, CWE-663

Consequences:
  - Integrity: Execute Unauthorized Code or Commands
  - Integrity: Modify 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

Mitigations:
  - [Requirements] Require languages or libraries that provide reentrant functionality, or otherwise make it easier to avoid this weakness.
  - [Architecture and Design] Design signal handlers to only set flags rather than perform complex functionality.
  - [Implementation] Ensure that non-reentrant functions are not found in signal handlers.
  - [Implementation] Use sanity checks to reduce the timing window for exploitation of race conditions. This is only a partial solution, since many attacks might fail, but other attacks still might work within the narrower window, even accidentally.

Demonstrative examples:
In this example, a signal handler uses syslog() to log a message:

char *message; void sh(int dummy) { syslog(LOG_NOTICE,"%s\n",message); sleep(10); exit(0); } int main(int argc,char* argv[]) { ... signal(SIGHUP,sh); signal(SIGTERM,sh); sleep(10); exit(0); } If the execution of the first call to the signal handler is suspended after invoking syslog(), and the signal handler is called a second time, the memory allocated by syslog() enters an undefined, and possibly, exploitable state.

Real-world examples:
  - CVE-2005-0893: signal handler calls function that ultimately uses malloc()
  - CVE-2004-2259: SIGCHLD signal to FTP server can cause crash under heavy load while executing non-reentrant functions like malloc/free.
CWE-48: Path Equivalence: 'file name' (Internal Whitespace)

Description:
The product accepts path input in the form of internal space ('file(SPACE)name') without appropriate validation, which can lead to ambiguous path resolution and allow an attacker to traverse the file system to unintended locations or access arbitrary files.

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

Consequences:
  - Confidentiality: Read Files or Directories

Real-world examples:
  - CVE-2000-0293: Filenames with spaces allow arbitrary file deletion when the product does not properly quote them; some overlap with path traversal.
  - CVE-2001-1567: "+" characters in query string converted to spaces before sensitive file/extension (internal space), leading to bypass of access restrictions to the file.
CWE-480: Use of Incorrect Operator

Description:
The product accidentally uses the wrong operator, which changes the logic in security-relevant ways.

Extended Description:
These types of errors are generally the result of a typo by the programmer.

Affected languages: C, C++, Perl, Not Language-Specific
Parent weaknesses: CWE-670

Consequences:
  - Other: Alter Execution Logic

Detection methods:
  - Automated Static Analysis: This weakness can be found easily using static analysis. However in some cases an operator might appear to be incorrect, but is actually correct and reflects unusual logic within the program.
  - Manual Static Analysis: This weakness can be found easily using static analysis. However in some cases an operator might appear to be incorrect, but is actually correct and reflects unusual logic within the program.

Demonstrative examples:
The following C/C++ and C# examples attempt to validate an int input parameter against the integer value 100.
However, the expression to be evaluated in the if statement uses the assignment operator "=" rather than the comparison operator "==". The result of using the assignment operator instead of the comparison operator causes the int variable to be reassigned locally and the expression in the if statement will always evaluate to the value on the right hand side of the expression. This will result in the input value not being properly validated, which can cause unexpected results.
int isValid(int value) { if (value=100) { printf("Value is valid\n"); return(1); } printf("Value is not valid\n"); return(0); }
bool isValid(int value) { if (value=100) { Console.WriteLine("Value is valid."); r

The following C/C++ example shows a simple implementation of a stack that includes methods for adding and removing integer values from the stack. The example uses pointers to add and remove integer values to the stack array variable.
The push method includes an expression to assign the integer value to the location in the stack pointed to by the pointer variable.
#define SIZE 50 int *tos, *p1, stack[SIZE]; 
                      void push(int i) { 
                         p1++; if(p1==(tos+SIZE)) { 
                               
                                  
                                  // Print stack overflow error message and exit 
                                  
                               
                            } *p1 == i; 
                      } 
            

Real-world examples:
  - CVE-2022-3979: Chain: data visualization program written in PHP uses the "!=" operator instead of the type-strict "!==" operator (CWE-480) when validating hash values, potentially leading to an incorrect type conver
  - CVE-2021-3116: Chain: Python-based HTTP Proxy server uses the wrong boolean operators (CWE-480) causing an  incorrect comparison (CWE-697) that identifies an authN failure if all three conditions are met instead of
CWE-481: Assigning instead of Comparing

Description:
The code uses an operator for assignment when the intention was to perform a comparison.

Extended Description:
In many languages the compare statement is very close in appearance to the assignment statement and are often confused. This bug is generally the result of a typo and usually causes obvious problems with program execution. If the comparison is in an if statement, the if statement will usually evaluate the value of the right-hand side of the predicate.

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

Consequences:
  - Other: Alter Execution Logic

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
  - Automated Static Analysis - Source Code: An Integrated Development Environment (IDE) or linter can report or highlight this weaknesses.

Mitigations:
  - [Implementation] Place constants on the left. If one attempts to assign a constant with a variable, the compiler will produce an error.

Demonstrative examples:
The following C/C++ and C# examples attempt to validate an int input parameter against the integer value 100.
However, the expression to be evaluated in the if statement uses the assignment operator "=" rather than the comparison operator "==". The result of using the assignment operator instead of the comparison operator causes the int variable to be reassigned locally and the expression in the if statement will always evaluate to the value on the right hand side of the expression. This will result in the input value not being properly validated, which can cause unexpected results.
int isValid(int value) { if (value=100) { printf("Value is valid\n"); return(1); } printf("Value is not valid\n"); return(0); }
bool isValid(int value) { if (value=100) { Console.WriteLine("Value is valid."); r

In this example, we show how assigning instead of comparing can impact code when values are being passed by reference instead of by value. Consider a scenario in which a string is being processed from user input. Assume the string has already been formatted such that different user inputs are concatenated with the colon character. When the processString function is called, the test for the colon character will result in an insertion of the colon character instead, adding new input separators. Since the string was passed by reference, the data sentinels will be inserted in the original string (CWE-464), and further processing of the inputs will be altered, possibly malformed.

void processString (char *str) { 
                         int i; 
                            for(i=0; i<strlen(st
CWE-482: Comparing instead of Assigning

Description:
The code uses an operator for comparison when the intention was to perform an assignment.

Extended Description:
In many languages, the compare statement is very close in appearance to the assignment statement; they are often confused.

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

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
  - Automated Static Analysis - Source Code: An Integrated Development Environment (IDE) or linter can report or highlight this weaknesses.

Mitigations:
  - [Testing] Many IDEs and static analysis products will detect this problem.

Demonstrative examples:
The following example demonstrates the weakness.

void called(int foo) { foo==1; if (foo==1) System.out.println("foo\n"); } int main() { 
                         
                            called(2); return 0; 
                      }

The following C/C++ example shows a simple implementation of a stack that includes methods for adding and removing integer values from the stack. The example uses pointers to add and remove integer values to the stack array variable.
The push method includes an expression to assign the integer value to the location in the stack pointed to by the pointer variable.
#define SIZE 50 int *tos, *p1, stack[SIZE]; 
                      void push(int i) { 
                         p1++; if(p1==(tos+SIZE)) { 
                               
                                  
                                  // Print stack overflow error message and exit 
                                  
                               
                            } *p1 == i; 
                      }
CWE-483: Incorrect Block Delimitation

Description:
The code does not explicitly delimit a block that is intended to contain 2 or more statements, creating a logic error.

Extended Description:
In some languages, braces (or other delimiters) are optional for blocks. When the delimiter is omitted, it is possible to insert a logic error in which a statement is thought to be in a block but is not. In some cases, the logic error can have security implications.

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

Consequences:
  - Confidentiality: Alter Execution Logic

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] Always use explicit block delimitation and use static-analysis technologies to enforce this practice.

Demonstrative examples:
In this example, the programmer has indented the statements to call Do_X() and Do_Y(), as if the intention is that these functions are only called when the condition is true. However, because there are no braces to signify the block, Do_Y() will always be executed, even if the condition is false.
This might not be what the programmer intended. When the condition is critical for security, such as in making a security decision or detecting a critical error, this may produce a vulnerability.
if (condition==true) Do_X(); Do_Y();

In this example, the programmer has indented the Do_Y() statement as if the intention is that the function should be associated with the preceding conditional and should only be called when the condition is true. However, because Do_X() was called on the same line as the conditional and there are no braces to signify the block, Do_Y() will always be executed, even if the condition is false.
This might not be what the programmer intended. When the condition is critical for security, such as in making a security decision or detecting a critical error, this may produce a vulnerability.
if (condition==true) Do_X(); Do_Y();

Real-world examples:
  - CVE-2014-1266: Chain: incorrect "goto" in Apple SSL product bypasses certificate validation, allowing Adversary-in-the-Middle (AITM) attack (Apple "goto fail" bug). CWE-705 (Incorrect Control Flow Scoping) -> CWE-56
CWE-484: Omitted Break Statement in Switch

Description:
The product omits a break statement within a switch or similar construct, causing code associated with multiple conditions to execute. This can cause problems when the programmer only intended to execute code associated with one condition.

Extended Description:
This can lead to critical code executing in situations where it should not.

Affected languages: C, C++, Java, C#, PHP, Not Language-Specific
Parent weaknesses: CWE-710, CWE-670

Consequences:
  - Other: Alter Execution Logic

Detection methods:
  - White Box: Omission of a break statement might be intentional, in order to support fallthrough. Automated detection methods might therefore be erroneous. Semantic understanding of expected product behavior is re
  - Black Box: Since this weakness is associated with a code construct, it would be indistinguishable from other errors that produce the same behavior.
  - 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] Omitting a break statement so that one may fall through is often indistinguishable from an error, and therefore should be avoided. If you need to use fall-through capabilities, make sure that you have clearly documented this within the switch statement, and ensure that you have examined all the logi
  - [Implementation] The functionality of omitting a break statement could be clarified with an if statement. This method is much safer.

Demonstrative examples:
In both of these examples, a message is printed based on the month passed into the function:
Both examples do not use a break statement after each case, which leads to unintended fall-through behavior. For example, calling "printMessage(10)" will result in the text "OctoberNovemberDecember is a great month" being printed.
public void printMessage(int month){ 
                         switch (month) { 
                               
                                  case 1: print("January"); case 2: print("February"); case 3: print("March"); case 4: print("April"); case 5: print("May"); case 6: print("June"); case 7: print("July"); case 8: print("August"); case 9: print("September"); case 10: print("October"); case 11: print("November"); case 12: print("December");
CWE-486: Comparison of Classes by Name

Description:
The product compares classes by name, which can cause it to use the wrong class when multiple classes can have the same name.

Extended Description:
If the decision to trust the methods and data of an object is based on the name of a class, it is possible for malicious users to send objects of the same name as trusted classes and thereby gain the trust afforded to known classes and types.

Affected languages: Java
Parent weaknesses: CWE-1025

Consequences:
  - Integrity: 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

Mitigations:
  - [Implementation] Use class equivalency to determine type. Rather than use the class name to determine if an object is of a given type, use the getClass() method, and == operator.

Demonstrative examples:
In this example, the expression in the if statement compares the class of the inputClass object to a trusted class by comparing the class names.
However, multiple classes can have the same name therefore comparing an object's class by name can allow untrusted classes of the same name as the trusted class to be use to execute unintended or incorrect code. To compare the class of an object to the intended class the getClass() method and the comparison operator "==" should be used to ensure the correct trusted class is used, as shown in the following example.
if (inputClass.getClass().getName().equals("TrustedClassName")) { 
                         
                            
                            // Do something assuming you trust inputClass 
                            
           

In this example, the Java class, TrustedClass, overrides the equals method of the parent class Object to determine equivalence of objects of the class. The overridden equals method first determines if the object, obj, is the same class as the TrustedClass object and then compares the object's fields to determine if the objects are equivalent.
However, the equals method compares the class names of the object, obj, and the TrustedClass object to determine if they are the same class. As with the previous example using the name of the class to compare the class of objects can lead to the execution of unintended or incorrect code if the object passed to the equals method is of another class with the same name. To compare the class of an object to the intended class, the getClass() method and th
CWE-487: Reliance on Package-level Scope

Description:
Java packages are not inherently closed; therefore, relying on them for code security is not a good practice.

Extended Description:
The purpose of package scope is to prevent accidental access by other parts of a program. This is an ease-of-software-development feature but not a security feature.

Affected languages: Java
Parent weaknesses: CWE-664

Consequences:
  - Confidentiality: Read Application Data
  - Integrity: Modify 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] Data should be private static and final whenever possible. This will assure that your code is protected by instantiating early, preventing access and tampering.

Demonstrative examples:
The following example demonstrates the weakness.

package math; public class Lebesgue implements Integration{ 
                         public final Static String youAreHidingThisFunction(functionToIntegrate){ 
                               
                                  return ...; 
                            } 
                      }