deardaniel/secdata-raw huggingface dataset:
CWE-566: Authorization Bypass Through User-Controlled SQL Primary Key

Description:
The product uses a database table that includes records that should not be accessible to an actor, but it executes a SQL statement with a primary key that can be controlled by that actor.

Extended Description:
When a user can set a primary key to any value, then the user can modify the key to point to unauthorized records. 
             Database access control errors occur when: 
                
                   Data enters a program from an untrusted source. 
                   The data is used to specify the value of a primary key in a SQL query. 
                   The untrusted source does not have the permissions to be able to access all rows in the associated table.

Affected languages: SQL
Affected technologies: Database Server
Parent weaknesses: CWE-639

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] Assume all input is malicious. Use a standard input validation mechanism to validate all input for length, type, syntax, and business rules before accepting the data. Use an "accept known good" validation strategy.
  - [Implementation] Use a parameterized query AND make sure that the accepted values conform to the business rules. Construct your SQL statement accordingly.

Demonstrative examples:
The following code uses a parameterized statement, which escapes metacharacters and prevents SQL injection vulnerabilities, to construct and execute a SQL query that searches for an invoice matching the specified identifier [1]. The identifier is selected from a list of all invoices associated with the current authenticated user.
The problem is that the developer has not considered all of the possible values of id. Although the interface generates a list of invoice identifiers that belong to the current user, an attacker can bypass this interface to request any desired invoice. Because the code in this example does not check to ensure that the user has permission to access the requested invoice, it will display any invoice, even if it does not belong to the current user.
... 
		  conn = ne
CWE-567: Unsynchronized Access to Shared Data in a Multithreaded Context

Description:
The product does not properly synchronize shared data, such as static variables across threads, which can lead to undefined behavior and unpredictable data changes.

Extended Description:
Within servlets, shared static variables are not protected from concurrent access, but servlets are multithreaded. This is a typical programming mistake in J2EE applications, since the multithreading is handled by the framework. When a shared variable can be influenced by an attacker, one thread could wind up modifying the variable to contain data that is not valid for a different thread that is also using the data within the variable. 
             Note that this weakness is not unique to servlets.

Affected languages: Java
Parent weaknesses: CWE-820, CWE-662, CWE-662

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] Remove the use of static variables used between servlets. If this cannot be avoided, use synchronized access for these variables.

Demonstrative examples:
The following code implements a basic counter for how many times the page has been accesed.
Consider when two separate threads, Thread A and Thread B, concurrently handle two different requests:
public static class Counter extends HttpServlet { static int count = 0; protected void doGet(HttpServletRequest in, HttpServletResponse out) throws ServletException, IOException { out.setContentType("text/plain"); PrintWriter p = out.getWriter(); count++; p.println(count + " hits so far!"); } }
CWE-568: finalize() Method Without super.finalize()

Description:
The product contains a finalize() method that does not call super.finalize().

Extended Description:
The Java Language Specification states that it is a good practice for a finalize() method to call super.finalize().

Affected languages: Java
Parent weaknesses: CWE-573, CWE-459

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:
  - [Implementation] Call the super.finalize() method.

Demonstrative examples:
The following method omits the call to super.finalize().

protected void finalize() { discardNative(); }
CWE-57: Path Equivalence: 'fakedir/../realdir/filename'

Description:
The product contains protection mechanisms to restrict access to 'realdir/filename', but it constructs pathnames using external input in the form of 'fakedir/../realdir/filename' that are not handled by those mechanisms. This allows attackers to perform unauthorized actions against the targeted file.

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

Consequences:
  - Confidentiality: Read Files or Directories

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

Real-world examples:
  - CVE-2001-1152: Proxy allows remote attackers to bypass denylist restrictions and connect to unauthorized web servers by modifying the requested URL, including (1) a // (double slash), (2) a /SUBDIR/.. where the desi
  - CVE-2000-0191: application check access for restricted URL before canonicalization
  - CVE-2005-1366: CGI source disclosure using "dirname/../cgi-bin"
CWE-570: Expression is Always False

Description:
The product contains an expression that will always evaluate to false.

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

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:
  - [Implementation] Consider refactoring the code, or determine if the code is not including a condition that could cause the expression to become false.

Demonstrative examples:
In the following Java example the updateUserAccountOrder() method used within an e-business product ordering/inventory application will validate the product number that was ordered and the user account number. If they are valid, the method will update the product inventory, the user account, and the user order appropriately.
However, the method never sets the isValidAccount variable after initializing it to false so the isValidProduct is mistakenly used twice. The result is that the expression "isValidProduct && isValidAccount" will always evaluate to false, so the updateAccountOrder() method will never be invoked. This will create serious problems with the product ordering application since the user account and inventory databases will be updated but the order will not be updated.
public 

In the following example, the hasReadWriteAccess method uses bit masks and bit operators to determine if a user has read and write privileges for a particular process. The variable mask is defined as a bit mask from the BIT_READ and BIT_WRITE constants that have been defined. The variable mask is used within the predicate of the hasReadWriteAccess method to determine if the userMask input parameter has the read and write bits set.
However the bit operator used to initialize the mask variable is the AND operator rather than the intended OR operator (CWE-480), this resulted in the variable mask being set to 0. As a result, the if statement will always evaluate to false and never get executed.
#define BIT_READ 0x0001 // 00000001 #define BIT_WRITE 0x0010 // 00010000 
                      unsi
CWE-571: Expression is Always True

Description:
The product contains an expression that will always evaluate to true.

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

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:
  - [Implementation] Consider refactoring the code, or determine if the code is not including a condition that could cause the expression to become false.

Demonstrative examples:
In the following Java example the updateInventory() method used within an e-business product ordering/inventory application will check if the input product number is in the store or in the warehouse. If the product is found, the method will update the store or warehouse database as well as the aggregate product database. If the product is not found, the method intends to do some special processing without updating any database.
However, the method never sets the isDelayed variable and instead will always update the isProductAvailable variable to true. The result is that the predicate testing the isProductAvailable boolean will always evaluate to true and therefore always update the product database. Further, since the isDelayed variable is initialized to false and never changed, the expres
CWE-572: Call to Thread run() instead of start()

Description:
The product calls a thread's run() method instead of calling start(), which causes the code to run in the thread of the caller instead of the callee.

Extended Description:
In most cases a direct call to a Thread object's run() method is a bug. The programmer intended to begin a new thread of control, but accidentally called run() instead of start(), so the run() method will execute in the caller's thread of control.

Affected languages: Java
Parent weaknesses: CWE-821

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:
  - [Implementation] Use the start() method instead of the run() method.

Demonstrative examples:
The following excerpt from a Java program mistakenly calls run() instead of start().

Thread thr = new Thread() { public void run() { ... } }; 
                      thr.run();
CWE-573: Improper Following of Specification by Caller

Description:
The product does not follow or incorrectly follows the specifications as required by the implementation language, environment, framework, protocol, or platform.

Extended Description:
When leveraging external functionality, such as an API, it is important that the caller does so in accordance with the requirements of the external functionality or else unintended behaviors may result, possibly leaving the system vulnerable to any number of exploits.

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

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

Real-world examples:
  - CVE-2006-7140: Crypto implementation removes padding when it shouldn't, allowing forged signatures
  - CVE-2006-4339: Crypto implementation removes padding when it shouldn't, allowing forged signatures
CWE-574: EJB Bad Practices: Use of Synchronization Primitives

Description:
The product violates the Enterprise JavaBeans (EJB) specification by using thread synchronization primitives.

Extended Description:
The Enterprise JavaBeans specification requires that every bean provider follow a set of programming guidelines designed to ensure that the bean will be portable and behave consistently in any EJB container. In this case, the product violates the following EJB guideline: "An enterprise bean must not use thread synchronization primitives to synchronize execution of multiple instances." The specification justifies this requirement in the following way: "This rule is required to ensure consistent runtime semantics because while some EJB containers may use a single JVM to execute all enterprise bean's instances, others may distribute the instances across multiple JVMs."

Affected languages: Java
Parent weaknesses: CWE-695, CWE-821

Consequences:
  - Other: Quality Degradation

Mitigations:
  - [Implementation] Do not use Synchronization Primitives when writing EJBs.

Demonstrative examples:
In the following Java example a Customer Entity EJB provides access to customer information in a database for a business application.
However, the customer entity EJB uses the synchronized keyword for the set methods to attempt to provide thread safe synchronization for the member variables. The use of synchronized methods violate the restriction of the EJB specification against the use synchronization primitives within EJBs. Using synchronization primitives may cause inconsistent behavior of the EJB when used within different EJB containers.
@Entity public class Customer implements Serializable { 
                      
                         private String id; private String firstName; private String lastName; private Address address; 
                            public Customer() {...
CWE-575: EJB Bad Practices: Use of AWT Swing

Description:
The product violates the Enterprise JavaBeans (EJB) specification by using AWT/Swing.

Extended Description:
The Enterprise JavaBeans specification requires that every bean provider follow a set of programming guidelines designed to ensure that the bean will be portable and behave consistently in any EJB container. In this case, the product violates the following EJB guideline: "An enterprise bean must not use the AWT functionality to attempt to output information to a display, or to input information from a keyboard." The specification justifies this requirement in the following way: "Most servers do not allow direct interaction between an application program and a keyboard/display attached to the server system."

Affected languages: Java
Parent weaknesses: CWE-695

Consequences:
  - Other: Quality Degradation

Mitigations:
  - [Architecture and Design] Do not use AWT/Swing when writing EJBs.

Demonstrative examples:
The following Java example is a simple converter class for converting US dollars to Yen. This converter class demonstrates the improper practice of using a stateless session Enterprise JavaBean that implements an AWT Component and AWT keyboard event listener to retrieve keyboard input from the user for the amount of the US dollars to convert to Yen.
This use of the AWT and Swing APIs within any kind of Enterprise JavaBean not only violates the restriction of the EJB specification against using AWT or Swing within an EJB but also violates the intended use of Enterprise JavaBeans to separate business logic from presentation logic.
@Stateless public class ConverterSessionBean extends Component implements KeyListener, ConverterSessionRemote {
CWE-576: EJB Bad Practices: Use of Java I/O

Description:
The product violates the Enterprise JavaBeans (EJB) specification by using the java.io package.

Extended Description:
The Enterprise JavaBeans specification requires that every bean provider follow a set of programming guidelines designed to ensure that the bean will be portable and behave consistently in any EJB container. In this case, the product violates the following EJB guideline: "An enterprise bean must not use the java.io package to attempt to access files and directories in the file system." The specification justifies this requirement in the following way: "The file system APIs are not well-suited for business components to access data. Business components should use a resource manager API, such as JDBC, to store data."

Affected languages: Java
Parent weaknesses: CWE-695

Consequences:
  - Other: Quality Degradation

Mitigations:
  - [Implementation] Do not use Java I/O when writing EJBs.

Demonstrative examples:
The following Java example is a simple stateless Enterprise JavaBean that retrieves the interest rate for the number of points for a mortgage. In this example, the interest rates for various points are retrieved from an XML document on the local file system, and the EJB uses the Java I/O API to retrieve the XML document from the local file system.
This use of the Java I/O API within any kind of Enterprise JavaBean violates the EJB specification by using the java.io package for accessing files within the local filesystem.
@Stateless public class InterestRateBean implements InterestRateRemote { 
                      
                         private Document interestRateXMLDocument = null; private File interestRateFile = null; 
                            public InterestRateBean() {
CWE-577: EJB Bad Practices: Use of Sockets

Description:
The product violates the Enterprise JavaBeans (EJB) specification by using sockets.

Extended Description:
The Enterprise JavaBeans specification requires that every bean provider follow a set of programming guidelines designed to ensure that the bean will be portable and behave consistently in any EJB container. In this case, the product violates the following EJB guideline: "An enterprise bean must not attempt to listen on a socket, accept connections on a socket, or use a socket for multicast." The specification justifies this requirement in the following way: "The EJB architecture allows an enterprise bean instance to be a network socket client, but it does not allow it to be a network server. Allowing the instance to become a network server would conflict with the basic function of the enterprise bean-- to serve the EJB clients."

Affected languages: Java
Parent weaknesses: CWE-573

Consequences:
  - Other: Quality Degradation

Mitigations:
  - [Architecture and Design] Do not use Sockets when writing EJBs.

Demonstrative examples:
The following Java example is a simple stateless Enterprise JavaBean that retrieves stock symbols and stock values. The Enterprise JavaBean creates a socket and listens for and accepts connections from clients on the socket.
And the following Java example is similar to the previous example but demonstrates the use of multicast socket connections within an Enterprise JavaBean.
@Stateless public class StockSymbolBean implements StockSymbolRemote { 
                         
                            ServerSocket serverSocket = null; Socket clientSocket = null; 
                            public StockSymbolBean() { 
                               try { serverSocket = new ServerSocket(Constants.SOCKET_PORT); } catch (IOException ex) {...} 
                                  try { clientSocke
CWE-578: EJB Bad Practices: Use of Class Loader

Description:
The product violates the Enterprise JavaBeans (EJB) specification by using the class loader.

Extended Description:
The Enterprise JavaBeans specification requires that every bean provider follow a set of programming guidelines designed to ensure that the bean will be portable and behave consistently in any EJB container. In this case, the product violates the following EJB guideline: "The enterprise bean must not attempt to create a class loader; obtain the current class loader; set the context class loader; set security manager; create a new security manager; stop the JVM; or change the input, output, and error streams." The specification justifies this requirement in the following way: "These functions are reserved for the EJB container. Allowing the enterprise bean to use these functions could compromise security and decrease the container's ability to properly manage the runtime environment."

Affected languages: Java
Parent weaknesses: CWE-573

Consequences:
  - Confidentiality: Execute Unauthorized Code or Commands

Mitigations:
  - [Architecture and Design] Do not use the Class Loader when writing EJBs.

Demonstrative examples:
The following Java example is a simple stateless Enterprise JavaBean that retrieves the interest rate for the number of points for a mortgage. The interest rates for various points are retrieved from an XML document on the local file system, and the EJB uses the Class Loader for the EJB class to obtain the XML document from the local file system as an input stream.
This use of the Java Class Loader class within any kind of Enterprise JavaBean violates the restriction of the EJB specification against obtaining the current class loader as this could compromise the security of the application using the EJB.
@Stateless public class InterestRateBean implements InterestRateRemote { 
                      
                         private Document interestRateXMLDocument = null; 
                

An EJB is also restricted from creating a custom class loader and creating a class and instance of a class from the class loader, as shown in the following example.

@Stateless public class LoaderSessionBean implements LoaderSessionRemote { 
                      
                         public LoaderSessionBean() { try { ClassLoader loader = new CustomClassLoader(); Class c = loader.loadClass("someClass"); Object obj = c.newInstance(); /* perform some task that uses the new class instance member variables or functions */ ... } catch (Exception ex) {...} } 
                            public class CustomClassLoader extends ClassLoader { 
                            } 
                      }
CWE-579: J2EE Bad Practices: Non-serializable Object Stored in Session

Description:
The product stores a non-serializable object as an HttpSession attribute, which can hurt reliability.

Extended Description:
A J2EE application can make use of multiple JVMs in order to improve application reliability and performance. In order to make the multiple JVMs appear as a single application to the end user, the J2EE container can replicate an HttpSession object across multiple JVMs so that if one JVM becomes unavailable another can step in and take its place without disrupting the flow of the application. This is only possible if all session data is serializable, allowing the session to be duplicated between the JVMs.

Affected languages: Java
Parent weaknesses: CWE-573

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:
  - [Implementation] In order for session replication to work, the values the product stores as attributes in the session must implement the Serializable interface.

Demonstrative examples:
The following class adds itself to the session, but because it is not serializable, the session can no longer be replicated.

public class DataGlob { 
                         String globName; String globValue; 
                            public void addToSession(HttpSession session) { session.setAttribute("glob", this); } 
                      }