deardaniel/secdata-raw huggingface dataset:
CWE-756: Missing Custom Error Page

Description:
The product does not return custom error pages to the user, possibly exposing sensitive information.

Affected languages: Not Language-Specific
Affected technologies: Web Server
Parent weaknesses: CWE-755

Consequences:
  - Confidentiality: Read Application Data

Demonstrative examples:
In the snippet below, an unchecked runtime exception thrown from within the try block may cause the container to display its default error page (which may contain a full stack trace, among other things).

Public void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { try { ... } catch (ApplicationSpecificException ase) { logger.error("Caught: " + ase.toString()); } }

The mode attribute of the <customErrors> tag in the Web.config file defines whether custom or default error pages are used.
In the following insecure ASP.NET application setting, custom error message mode is turned off. An ASP.NET error message with detailed stack trace and platform versions will be returned.
<customErrors mode="Off" />
<customErrors mode="RemoteOnly" />

Real-world examples:
  - CVE-2023-27998: analytics platform does not have a custom error page, allowing access to sensitive information
CWE-757: Selection of Less-Secure Algorithm During Negotiation ('Algorithm Downgrade')

Description:
A protocol or its implementation supports interaction between multiple actors and allows those actors to negotiate which algorithm should be used as a protection mechanism such as encryption or authentication, but it does not select the strongest algorithm that is available to both parties.

Extended Description:
When a security mechanism can be forced to downgrade to use a less secure algorithm, this can make it easier for attackers to compromise the product by exploiting weaker algorithm. The victim might not be aware that the less secure algorithm is being used. For example, if an attacker can force a communications channel to use cleartext instead of strongly-encrypted data, then the attacker could read the channel by sniffing, instead of going through extra effort of trying to decrypt the data using brute force techniques.

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

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

Real-world examples:
  - CVE-2006-4302: Attacker can select an older version of the software to exploit its vulnerabilities.
  - CVE-2006-4407: Improper prioritization of encryption ciphers during negotiation leads to use of a weaker cipher.
  - CVE-2005-2969: chain: SSL/TLS implementation disables a verification step (CWE-325) that enables a downgrade attack to a weaker protocol.
  - CVE-2001-1444: Telnet protocol implementation allows downgrade to weaker authentication and encryption using an Adversary-in-the-Middle AITM attack.
  - CVE-2002-1646: SSH server implementation allows override of configuration setting to use weaker authentication schemes. This may be a composite with CWE-642.
CWE-758: Reliance on Undefined, Unspecified, or Implementation-Defined Behavior

Description:
The product uses an API function, data structure, or other entity in a way that relies on properties that are not always guaranteed to hold for that entity.

Extended Description:
This can lead to resultant weaknesses when the required properties change, such as when the product is ported to a different platform or if an interaction error (CWE-435) occurs.

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

Consequences:
  - Other: Reduce Maintainability

Detection methods:
  - 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:
This code assumes a particular function will always be found at a particular address. It assigns a pointer to that address and calls the function.
The same function may not always be found at the same memory address. This could lead to a crash, or an attacker may alter the memory at the expected address, leading to arbitrary code execution.
int (*pt2Function) (float, char, char)=0x08040000; int result2 = (*pt2Function) (12, 'a', 'b'); 
                      // Here we can inject code to execute.

The following function returns a stack address.

char* getName() { char name[STR_MAX]; fillInName(name); return name; }

Real-world examples:
  - CVE-2006-1902: Change in C compiler behavior causes resultant buffer overflows in programs that depend on behaviors that were undefined in the C standard.
CWE-76: Improper Neutralization of Equivalent Special Elements

Description:
The product correctly neutralizes certain special elements, but it improperly neutralizes equivalent special elements.

Extended Description:
The product may have a fixed list of special characters it believes is complete. However, there may be alternate encodings, or representations that also have the same meaning. For example, the product may filter out a leading slash (/) to prevent absolute path names, but does not account for a tilde (~) followed by a user name, which on some *nix systems could be expanded to an absolute pathname. Alternately, the product might filter a dangerous "-e" command-line switch when calling an external program, but it might not account for "--exec" or other switches that have the same semantics.

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

Consequences:
  - Other: Other

Mitigations:
  - [Requirements] Programming languages and supporting technologies might be chosen which are not subject to these issues.
  - [Implementation] Utilize an appropriate mix of allowlist and denylist parsing to filter equivalent special element syntax from all input.
CWE-760: Use of a One-Way Hash with a Predictable Salt

Description:
The product uses a one-way cryptographic hash against an input that should not be reversible, such as a password, but the product uses a predictable salt as part of the input.

Extended Description:
This makes it easier for attackers to pre-compute the hash value using dictionary attack techniques such as rainbow tables, effectively disabling the protection that an unpredictable salt would provide. 
             It should be noted that, despite common perceptions, the use of a good salt with a hash does not sufficiently increase the effort for an attacker who is targeting an individual password, or who has a large amount of computing resources available, such as with cloud-based services or specialized, inexpensive hardware. Offline password cracking can still be effective if the hash function is not expensive to compute; many cryptographic functions are designed to be efficient and can be vulnerable to attacks using massive computing resources, even if the hash is cryptographically strong. The use of a salt only slightly increases the computing requirements for an attacker compared to other strategies such as adaptive hash functions. See CWE-916 for more details.

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

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:
  - [Architecture and Design] Use an adaptive hash function that can be configured to change the amount of computational effort needed to compute the hash, such as the number of iterations ("stretching") or the amount of memory required. Some hash functions perform salting automatically. These functions can significantly increas
  - [Implementation] If a technique that requires extra computational effort can not be implemented, then for each password that is processed, generate a new random salt using a strong random number generator with unpredictable seeds. Add the salt to the plaintext password before hashing it. When storing the hash, also 

Real-world examples:
  - CVE-2008-4905: Blogging software uses a hard-coded salt when calculating a password hash.
  - CVE-2002-1657: Database server uses the username for a salt when encrypting passwords, simplifying brute force attacks.
  - CVE-2001-0967: Server uses a constant salt when encrypting passwords, simplifying brute force attacks.
  - CVE-2005-0408: chain: product generates predictable MD5 hashes using a constant value combined with username, allowing authentication bypass.
CWE-764: Multiple Locks of a Critical Resource

Description:
The product locks a critical resource more times than intended, leading to an unexpected state in the system.

Extended Description:
When a product is operating in a concurrent environment and repeatedly locks a critical resource, the consequences will vary based on the type of lock, the lock's implementation, and the resource being protected. In some situations such as with semaphores, the resources are pooled and extra locking calls will reduce the size of the total available pool, possibly leading to degraded performance or a denial of service. If this can be triggered by an attacker, it will be similar to an unrestricted lock (CWE-412). In the context of a binary lock, it is likely that any duplicate locking attempts will never succeed since the lock is already held and progress may not be possible.

Affected languages: Not Language-Specific
Parent weaknesses: CWE-667, CWE-675, CWE-662, CWE-662

Consequences:
  - Availability: DoS: Resource Consumption (CPU)

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] When locking and unlocking a resource, try to be sure that all control paths through the code in which the resource is locked one or more times correspond to exactly as many unlocks. If the software acquires a lock and then determines it is not able to perform its intended behavior, be sure to relea
CWE-765: Multiple Unlocks of a Critical Resource

Description:
The product unlocks a critical resource more times than intended, leading to an unexpected state in the system.

Extended Description:
When the product is operating in a concurrent environment and repeatedly unlocks a critical resource, the consequences will vary based on the type of lock, the lock's implementation, and the resource being protected. In some situations such as with semaphores, the resources are pooled and extra calls to unlock will increase the count for the number of available resources, likely resulting in a crash or unpredictable behavior when the system nears capacity.

Affected languages: Not Language-Specific
Parent weaknesses: CWE-667, CWE-675

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:
  - [Implementation] When locking and unlocking a resource, try to be sure that all control paths through the code in which the resource is locked one or more times correspond to exactly as many unlocks. If the product acquires a lock and then determines it is not able to perform its intended behavior, be sure to releas

Real-world examples:
  - CVE-2009-0935: Attacker provides invalid address to a memory-reading function, causing a mutex to be unlocked twice
CWE-766: Critical Data Element Declared Public

Description:
The product declares a critical variable, field, or member to be public when intended security policy requires it to be private.

Extended Description:
This issue makes it more difficult to maintain the product, which indirectly affects security by making it more difficult or time-consuming to find and/or fix vulnerabilities.  It also might make it easier to introduce vulnerabilities.

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

Consequences:
  - Integrity: Read Application Data
  - Other: Reduce Maintainability

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

Demonstrative examples:
The following example declares a critical variable public, making it accessible to anyone with access to the object in which it is contained.
Instead, the critical data should be declared private.
public: char* password;
private: char* password;

The following example shows a basic user account class that includes member variables for the username and password as well as a public constructor for the class and a public method to authorize access to the user account.
However, the member variables username and password are declared public and therefore will allow access and changes to the member variables to anyone with access to the object. These member variables should be declared private as shown below to prevent unauthorized access and changes.
#define MAX_PASSWORD_LENGTH 15 #define MAX_USERNAME_LENGTH 15 
                      class UserAccount { 
                         public: 
                               UserAccount(char *username, char *password) { if ((strlen(username) > MAX_USERNAME_LENGTH) || (strlen(password) > MAX_PA

Real-world examples:
  - CVE-2010-3860: variables declared public allow remote read of system properties such as user name and home directory.
CWE-767: Access to Critical Private Variable via Public Method

Description:
The product defines a public method that reads or modifies a private variable.

Extended Description:
If an attacker modifies the variable to contain unexpected values, this could violate assumptions from other parts of the code. Additionally, if an attacker can read the private variable, it may expose sensitive information or make it easier to launch further attacks.

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

Consequences:
  - Integrity: Modify Application Data

Mitigations:
  - [Implementation] Use class accessor and mutator methods appropriately. Perform validation when accepting data from a public method that is intended to modify a critical private variable. Also be sure that appropriate access controls are being applied when a public method interfaces with critical data.

Demonstrative examples:
The following example declares a critical variable to be private, and then allows the variable to be modified by public methods.

private: float price; public: void changePrice(float newPrice) { price = newPrice; }

The following example could be used to implement a user forum where a single user (UID) can switch between multiple profiles (PID).
The programmer implemented setPID with the intention of modifying the PID variable, but due to a typo. accidentally specified the critical variable UID instead. If the program allows profile IDs to be between 1 and 10, but a UID of 1 means the user is treated as an admin, then a user could gain administrative privileges as a result of this typo.
public class Client { private int UID; public int PID; private String userName; public Client(String userName){ PID = getDefaultProfileID(); UID = mapUserNametoUID( userName ); this.userName = userName; } public void setPID(int ID) { UID = ID; } }
CWE-768: Incorrect Short Circuit Evaluation

Description:
The product contains a conditional statement with multiple logical expressions in which one of the non-leading expressions may produce side effects. This may lead to an unexpected state in the program after the execution of the conditional, because short-circuiting logic may prevent the side effects from occurring.

Extended Description:
Usage of short circuit evaluation, though well-defined in the C standard, may alter control flow in a way that introduces logic errors that are difficult to detect, possibly causing errors later during the product's execution. If an attacker can discover such an inconsistency, it may be exploitable to gain arbitrary control over a system. 
             If the first condition of an "or" statement is assumed to be true under normal circumstances, or if the first condition of an "and" statement is assumed to be false, then any subsequent conditional may contain its own logic errors that are not detected during code review or testing. 
             Finally, the usage of short circuit evaluation may decrease the maintainability of the code.

Affected languages: Not Language-Specific, C
Parent weaknesses: CWE-691

Consequences:
  - Confidentiality: 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] Minimizing the number of statements in a conditional that produce side effects will help to prevent the likelihood of short circuit evaluation to alter control flow in an unexpected way.

Demonstrative examples:
The following function attempts to take a size value from a user and allocate an array of that size (we ignore bounds checking for simplicity). The function tries to initialize each spot with the value of its index, that is, A[len-1] = len - 1; A[len-2] = len - 2; ... A[1] = 1; A[0] = 0; However, since the programmer uses the prefix decrement operator, when the conditional is evaluated with i == 1, the decrement will result in a 0 value for the first part of the predicate, causing the second portion to be bypassed via short-circuit evaluation. This means we cannot be sure of what value will be in A[0] when we return the array to the user.
When compiled and run, the above code will output a privilege level of 1, or PRIV_REGULAR for every user but the user with id 0 since the prefix incremen
CWE-771: Missing Reference to Active Allocated Resource

Description:
The product does not properly maintain a reference to a resource that has been allocated, which prevents the resource from being reclaimed.

Extended Description:
This does not necessarily apply in languages or frameworks that automatically perform garbage collection, since the removal of all references may act as a signal that the resource is ready to be reclaimed.

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

Consequences:
  - Availability: DoS: Resource Consumption (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:
  - [Operation] Use resource-limiting settings provided by the operating system or environment. For example, when managing system resources in POSIX, setrlimit() can be used to set limits for certain types of resources, and getrlimit() can determine how many resources are available. However, these functions are not
CWE-773: Missing Reference to Active File Descriptor or Handle

Description:
The product does not properly maintain references to a file descriptor or handle, which prevents that file descriptor/handle from being reclaimed.

Extended Description:
This can cause the product to consume all available file descriptors or handles, which can prevent other processes from performing critical file processing operations.

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

Consequences:
  - Availability: DoS: Resource Consumption (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:
  - [Operation] Use resource-limiting settings provided by the operating system or environment. For example, when managing system resources in POSIX, setrlimit() can be used to set limits for certain types of resources, and getrlimit() can determine how many resources are available. However, these functions are not
CWE-774: Allocation of File Descriptors or Handles Without Limits or Throttling

Description:
The product allocates file descriptors or handles on behalf of an actor without imposing any restrictions on how many descriptors can be allocated, in violation of the intended security policy for that actor.

Extended Description:
This can cause the product to consume all available file descriptors or handles, which can prevent other processes from performing critical file processing operations.

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

Consequences:
  - Availability: DoS: Resource Consumption (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:
  - [Operation] Use resource-limiting settings provided by the operating system or environment. For example, when managing system resources in POSIX, setrlimit() can be used to set limits for certain types of resources, and getrlimit() can determine how many resources are available. However, these functions are not
CWE-775: Missing Release of File Descriptor or Handle after Effective Lifetime

Description:
The product does not release a file descriptor or handle after its effective lifetime has ended, i.e., after the file descriptor/handle is no longer needed.

Extended Description:
When a file descriptor or handle is not released after use (typically by explicitly closing it), attackers can cause a denial of service by consuming all available file descriptors/handles, or otherwise preventing other system processes from obtaining their own file descriptors/handles.

Affected languages: Not Language-Specific
Parent weaknesses: CWE-772, CWE-404, CWE-404

Consequences:
  - Availability: DoS: Resource Consumption (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:
  - [Operation] Use resource-limiting settings provided by the operating system or environment. For example, when managing system resources in POSIX, setrlimit() can be used to set limits for certain types of resources, and getrlimit() can determine how many resources are available. However, these functions are not

Real-world examples:
  - CVE-2007-0897: Chain: anti-virus product encounters a malformed file but returns from a function without closing a file descriptor (CWE-775) leading to file descriptor consumption (CWE-400) and failed scans.