deardaniel/secdata-raw huggingface dataset:
CWE-488: Exposure of Data Element to Wrong Session

Description:
The product does not sufficiently enforce boundaries between the states of different sessions, causing data to be provided to, or used by, the wrong session.

Extended Description:
Data can "bleed" from one session to another through member variables of singleton objects, such as Servlets, and objects from a shared pool. 
             In the case of Servlets, developers sometimes do not understand that, unless a Servlet implements the SingleThreadModel interface, the Servlet is a singleton; there is only one instance of the Servlet, and that single instance is used and re-used to handle multiple requests that are processed simultaneously by different threads. A common result is that developers use Servlet member fields in such a way that one user may inadvertently see another user's data. In other words, storing user data in Servlet member fields introduces a data access race condition.

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

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:
  - [Architecture and Design] Protect the application's sessions from information leakage. Make sure that a session's data is not used or visible by other sessions.
  - [Testing] Use a static analysis tool to scan the code for information leakage vulnerabilities (e.g. Singleton Member Field).
  - [Architecture and Design] In a multithreading environment, storing user data in Servlet member fields introduces a data access race condition. Do not use member fields to store information in the Servlet.

Demonstrative examples:
The following Servlet stores the value of a request parameter in a member field and then later echoes the parameter value to the response output stream.
While this code will work perfectly in a single-user environment, if two users access the Servlet at approximately the same time, it is possible for the two request handler threads to interleave in the following way: Thread 1: assign "Dick" to name Thread 2: assign "Jane" to name Thread 1: print "Jane, thanks for visiting!" Thread 2: print "Jane, thanks for visiting!" Thereby showing the first user the second user's name.
public class GuestBook extends HttpServlet { 
                         String name; 
                            protected void doPost (HttpServletRequest req, HttpServletResponse res) { name = req.getParameter("name"); .
CWE-489: Active Debug Code

Description:
The product is released with debugging code still enabled or active.

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

Consequences:
  - Confidentiality: 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:
  - [Build and Compilation] Remove debug code before deploying the application.

Demonstrative examples:
Debug code can be used to bypass authentication. For example, suppose an application has a login script that receives a username and a password. Assume also that a third, optional, parameter, called "debug", is interpreted by the script as requesting a switch to debug mode, and that when this parameter is given the username and password are not checked. In such a case, it is very simple to bypass the authentication process if the special behavior of the application regarding the debug parameter is known. In a case where the form is:
Then a conforming link will look like:
<FORM ACTION="/authenticate_login.cgi"> <INPUT TYPE=TEXT name=username> <INPUT TYPE=PASSWORD name=password> <INPUT TYPE=SUBMIT> </FORM>
http://TARGET/authenticate_login.cgi?username=...&password=...

Real-world examples:
  - CVE-2024-44092: smartphone is built for production with debugging code present, allowing local privilege escalation
  - CVE-2024-36475: network hub contains active debug code, which allows users to execute arbitrary OS commands using a debug function
  - CVE-2024-29075: Mesh Wi-Fi router has active debug code, allowing attackers to modify device settings
CWE-49: Path Equivalence: 'filename/' (Trailing Slash)

Description:
The product accepts path input in the form of trailing slash ('filedir/') 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
Affected technologies: Not Technology-Specific, Web Based
Parent weaknesses: CWE-41, CWE-162

Consequences:
  - Confidentiality: Read Files or Directories

Real-world examples:
  - CVE-2002-0253: Overlaps infoleak
  - CVE-2001-0446: Application server allows remote attackers to read source code for .jsp files by appending a / to the requested URL.
  - CVE-2004-0334: Bypass Basic Authentication for files using trailing "/"
  - CVE-2001-0893: Read sensitive files with trailing "/"
  - CVE-2001-0892: Web server allows remote attackers to view sensitive files under the document root (such as .htpasswd) via a GET request with a trailing /.
CWE-491: Public cloneable() Method Without Final ('Object Hijack')

Description:
A class has a cloneable() method that is not declared final, which allows an object to be created without calling the constructor. This can cause the object to be in an unexpected state.

Affected languages: Java
Parent weaknesses: CWE-668

Consequences:
  - Integrity: 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:
  - [Implementation] Make the cloneable() method final.

Demonstrative examples:
In this example, a public class "BankAccount" implements the cloneable() method which declares "Object clone(string accountnumber)":

public class BankAccount implements Cloneable{ 
                         public Object clone(String accountnumber) throws CloneNotSupportedException { 
                               Object returnMe = new BankAccount(account number); ... 
                               
                            } 
                      }

In the example below, a clone() method is defined without being declared final.

protected Object clone() throws CloneNotSupportedException { ... }
CWE-492: Use of Inner Class Containing Sensitive Data

Description:
Inner classes are translated into classes that are accessible at package scope and may expose code that the programmer intended to keep private to attackers.

Extended Description:
Inner classes quietly introduce several security concerns because of the way they are translated into Java bytecode. In Java source code, it appears that an inner class can be declared to be accessible only by the enclosing class, but Java bytecode has no concept of an inner class, so the compiler must transform an inner class declaration into a peer class with package level access to the original outer class. More insidiously, since an inner class can access private fields in its enclosing class, once an inner class becomes a peer class in bytecode, the compiler converts private fields accessed by the inner class into protected fields.

Affected languages: Java
Parent weaknesses: CWE-668

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:
  - [Implementation] Using sealed classes protects object-oriented encapsulation paradigms and therefore protects code from being extended in unforeseen ways.
  - [Implementation] Inner Classes do not provide security. Warning: Never reduce the security of the object from an outer class, going to an inner class. If an outer class is final or private, ensure that its inner class is private as well.

Demonstrative examples:
The following Java Applet code mistakenly makes use of an inner class.

public final class urlTool extends Applet { private final class urlHelper { ... } ... }

The following example shows a basic use of inner classes. The class OuterClass contains the private member inner class InnerClass. The private inner class InnerClass includes the method concat that accesses the private member variables of the class OuterClass to output the value of one of the private member variables of the class OuterClass and returns a string that is a concatenation of one of the private member variables of the class OuterClass, the separator input parameter of the method and the private member variable of the class InnerClass.
Although this is an acceptable use of inner classes it demonstrates one of the weaknesses of inner classes that inner classes have complete access to all member variables and methods of the enclosing class even those that are declared private and
CWE-493: Critical Public Variable Without Final Modifier

Description:
The product has a critical public variable that is not final, which allows the variable to be modified to contain unexpected values.

Extended Description:
If a field is non-final and public, it can be changed once the value is set by any function that has access to the class which contains the field. This could lead to a vulnerability if other parts of the program make assumptions about the contents of that field.

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

Consequences:
  - Integrity: Modify Application Data
  - 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:
  - [Implementation] Declare all public fields as final when possible, especially if it is used to maintain internal state of an Applet or of classes used by an Applet. If a field must be public, then perform all appropriate sanity checks before accessing the field from your code.

Demonstrative examples:
Suppose this WidgetData class is used for an e-commerce web site. The programmer attempts to prevent price-tampering attacks by setting the price of the widget using the constructor.
The price field is not final. Even though the value is set by the constructor, it could be modified by anybody that has access to an instance of WidgetData.
public final class WidgetData extends Applet { public float price; ... public WidgetData(...) { this.price = LookupPrice("MyWidgetType"); } }

Assume the following code is intended to provide the location of a configuration file that controls execution of the application.
While this field is readable from any function, and thus might allow an information leak of a pathname, a more serious problem is that it can be changed by any function.
public string configPath = "/etc/application/config.dat";
public String configPath = new String("/etc/application/config.dat");
CWE-495: Private Data Structure Returned From A Public Method

Description:
The product has a method that is declared public, but returns a reference to a private data structure, which could then be modified in unexpected ways.

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

Consequences:
  - 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:
  - [Implementation] Declare the method private.
  - [Implementation] Clone the member data and keep an unmodified version of the data private to the object.
  - [Implementation] Use public setter methods that govern how a private member can be modified.

Demonstrative examples:
Here, a public method in a Java class returns a reference to a private array. Given that arrays in Java are mutable, any modifications made to the returned reference would be reflected in the original private array.

private String[] colors; public String[] getColors() { return colors; }

In this example, the Color class defines functions that return non-const references to private members (an array type and an integer type), which are then arbitrarily altered from outside the control of the class.

class Color { private: int[2] colorArray; int colorValue; public: Color () : colorArray { 1, 2 }, colorValue (3) { }; int[2] & fa () { return colorArray; }  // return reference to private array int & fv () { return colorValue; }  // return reference to private integer }; int main () { Color c; c.fa () [1] = 42;  // modifies private array element c.fv () = 42;  // modifies private int return 0; }
CWE-496: Public Data Assigned to Private Array-Typed Field

Description:
Assigning public data to a private array is equivalent to giving public access to the array.

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

Consequences:
  - 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:
  - [Implementation] Do not allow objects to modify private members of a class.

Demonstrative examples:
In the example below, the setRoles() method assigns a publically-controllable array to a private field, thus allowing the caller to modify the private array directly by virtue of the fact that arrays in Java are mutable.

private String[] userRoles; public void setUserRoles(String[] userRoles) { this.userRoles = userRoles; }
CWE-498: Cloneable Class Containing Sensitive Information

Description:
The code contains a class with sensitive data, but the class is cloneable. The data can then be accessed by cloning the class.

Extended Description:
Cloneable classes are effectively open classes, since data cannot be hidden in them. Classes that do not explicitly deny cloning can be cloned by any other class without running the constructor.

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

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] If you do make your classes clonable, ensure that your clone method is final and throw super.clone().

Demonstrative examples:
The following example demonstrates the weakness.
Make classes uncloneable by defining a clone function like:
public class CloneClient { 
                         public CloneClient() //throws java.lang.CloneNotSupportedException { 
                               
                                  Teacher t1 = new Teacher("guddu","22,nagar road"); //... // Do some stuff to remove the teacher. Teacher t2 = (Teacher)t1.clone(); System.out.println(t2.name); 
                            } public static void main(String args[]) { 
                               
                                  new CloneClient(); 
                            } 
                      } class Teacher implements Cloneable { 
                         
                            public Object clone() {
CWE-499: Serializable Class Containing Sensitive Data

Description:
The code contains a class with sensitive data, but the class does not explicitly deny serialization. The data can be accessed by serializing the class through another class.

Extended Description:
Serializable classes are effectively open classes since data cannot be hidden in them. Classes that do not explicitly deny serialization can be serialized by any other class, which can then in turn use the data stored inside it.

Affected languages: Java
Parent weaknesses: CWE-668

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:
  - [Implementation] In Java, explicitly define final writeObject() to prevent serialization. This is the recommended solution. Define the writeObject() function to throw an exception explicitly denying serialization.
  - [Implementation] Make sure to prevent serialization of your objects.

Demonstrative examples:
This code creates a new record for a medical patient:
This object does not explicitly deny serialization, allowing an attacker to serialize an instance of this object and gain a patient's name and Social Security number even though those fields are private.
class PatientRecord { private String name; private String socialSecurityNum; public Patient(String name,String ssn) { this.SetName(name); this.SetSocialSecurityNumber(ssn); } }
CWE-5: J2EE Misconfiguration: Data Transmission Without Encryption

Description:
Information sent over a network can be compromised while in transit. An attacker may be able to read or modify the contents if the data are sent in plaintext or are weakly encrypted.

Affected languages: Java
Parent weaknesses: CWE-319

Consequences:
  - Confidentiality: Read Application Data
  - Integrity: Modify Application Data

Mitigations:
  - [System Configuration] The product configuration should ensure that SSL or an encryption mechanism of equivalent strength and vetted reputation is used for all access-controlled pages.
CWE-50: Path Equivalence: '//multiple/leading/slash'

Description:
The product accepts path input in the form of multiple leading slash ('//multiple/leading/slash') 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, CWE-161

Consequences:
  - Confidentiality: Read Files or Directories

Real-world examples:
  - CVE-2002-1483: Read files with full pathname using multiple internal slash.
  - CVE-1999-1456: Server allows remote attackers to read arbitrary files via a GET request with more than one leading / (slash) character in the filename.
  - CVE-2004-0578: Server allows remote attackers to read arbitrary files via leading slash (//) characters in a URL request.
  - CVE-2002-0275: Server allows remote attackers to bypass authentication and read restricted files via an extra / (slash) in the requested URL.
  - CVE-2004-1032: Product allows local users to delete arbitrary files or create arbitrary empty files via a target filename with a large number of leading slash (/) characters.
CWE-500: Public Static Field Not Marked Final

Description:
An object contains a public static field that is not marked final, which might allow it to be modified in unexpected ways.

Extended Description:
Public static variables can be read without an accessor and changed without a mutator by any classes in the application.

Affected languages: C++, Java
Parent weaknesses: CWE-493

Consequences:
  - Integrity: Modify Application Data
  - 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] Clearly identify the scope for all critical data elements, including whether they should be regarded as static.
  - [Implementation] Make any static fields private and constant. 
                   A constant field is denoted by the keyword 'const' in C/C++ and ' final' in Java

Demonstrative examples:
The following examples use of a public static String variable to contain the name of a property/configuration file for the application.
Having a public static variable that is not marked final (constant) may allow the variable to the altered in a way not intended by the application. In this example the String variable can be modified to indicate a different on nonexistent properties file which could cause the application to crash or caused unexpected behavior.
class SomeAppClass { 
                         
                            public: static string appPropertiesConfigFile = "app/properties.config"; 
                            ... 
                      }
public class SomeAppClass { 
                         
                            public static String appPropertiesFile = "app
CWE-501: Trust Boundary Violation

Description:
The product mixes trusted and untrusted data in the same data structure or structured message.

Extended Description:
A trust boundary can be thought of as line drawn through a program. On one side of the line, data is untrusted. On the other side of the line, data is assumed to be trustworthy. The purpose of validation logic is to allow data to safely cross the trust boundary - to move from untrusted to trusted. A trust boundary violation occurs when a program blurs the line between what is trusted and what is untrusted. By combining trusted and untrusted data in the same data structure, it becomes easier for programmers to mistakenly trust unvalidated data.

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

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

Demonstrative examples:
The following code accepts an HTTP request and stores the username parameter in the HTTP session object before checking to ensure that the user has been authenticated.
Without well-established and maintained trust boundaries, programmers will inevitably lose track of which pieces of data have been validated and which have not. This confusion will eventually allow some data to be used without first being validated.
usrname = request.getParameter("usrname"); if (session.getAttribute(ATTR_USR) == null) { session.setAttribute(ATTR_USR, usrname); }
usrname = request.Item("usrname"); if (session.Item(ATTR_USR) == null) { session.Add(ATTR_USR, usrname); }