deardaniel/secdata-raw huggingface dataset:
CWE-653: Improper Isolation or Compartmentalization

Description:
The product does not properly compartmentalize or isolate functionality, processes, or resources that require different privilege levels, rights, or permissions.

Extended Description:
When a weakness occurs in functionality that is accessible by lower-privileged users, then without strong boundaries, an attack might extend the scope of the damage to higher-privileged users.

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

Consequences:
  - Access Control: Gain Privileges or Assume Identity

Detection methods:
  - Automated Static Analysis - Binary or Bytecode: According to SOAR, the following detection techniques may be useful: 
                   
                      Cost effective for partial coverage: 
                         
                        
  - Manual Static Analysis - Source Code: According to SOAR, the following detection techniques may be useful: 
                   
                      Highly cost effective: 
                         
                            Manual Sou
  - Architecture or Design Review: According to SOAR, the following detection techniques may be useful: 
                   
                      Highly cost effective: 
                         
                            Inspection

Mitigations:
  - [Architecture and Design] Break up privileges between different modules, objects, or entities. Minimize the interfaces between modules and require strong access control between them.

Demonstrative examples:
Single sign-on technology is intended to make it easier for users to access multiple resources or domains without having to authenticate each time. While this is highly convenient for the user and attempts to address problems with psychological acceptability, it also means that a compromise of a user's credentials can provide immediate access to all other resources or domains.

The traditional UNIX privilege model provides root with arbitrary access to all resources, but root is frequently the only user that has privileges. As a result, administrative tasks require root privileges, even if those tasks are limited to a small area, such as updating user manpages. Some UNIX flavors have a "bin" user that is the owner of system executables, but since root relies on executables owned by bin, a compromise of the bin account can be leveraged for root privileges by modifying a bin-owned executable, such as CVE-2007-4238.

Real-world examples:
  - CVE-2021-33096: Improper isolation of shared resource in a network-on-chip leads to denial of service
  - CVE-2019-6260: Baseboard Management Controller (BMC) device implements Advanced High-performance Bus (AHB) bridges that do not require authentication for arbitrary read and write access to the BMC's physical address
CWE-654: Reliance on a Single Factor in a Security Decision

Description:
A protection mechanism relies exclusively, or to a large extent, on the evaluation of a single condition or the integrity of a single object or entity in order to make a decision about granting access to restricted resources or functionality.

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

Consequences:
  - Access Control: Gain Privileges or Assume Identity
  - Non-Repudiation: Hide Activities

Mitigations:
  - [Architecture and Design] Use multiple simultaneous checks before granting access to critical operations or granting critical privileges. A weaker but helpful mitigation is to use several successive checks (multiple layers of security).
  - [Architecture and Design] Use redundant access rules on different choke points (e.g., firewalls).

Demonstrative examples:
Password-only authentication is perhaps the most well-known example of use of a single factor. Anybody who knows a user's password can impersonate that user.

When authenticating, use multiple factors, such as "something you know" (such as a password) and "something you have" (such as a hardware-based one-time password generator, or a biometric device).

Real-world examples:
  - CVE-2022-35248: Chat application skips validation when Central Authentication Service
			 (CAS) is enabled, effectively removing the second factor from
			 two-factor authentication
CWE-655: Insufficient Psychological Acceptability

Description:
The product has a protection mechanism that is too difficult or inconvenient to use, encouraging non-malicious users to disable or bypass the mechanism, whether by accident or on purpose.

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

Consequences:
  - Access Control: Bypass Protection Mechanism

Mitigations:
  - [Testing] Where possible, perform human factors and usability studies to identify where your product's security mechanisms are difficult to use, and why.
  - [Architecture and Design] Make the security mechanism as seamless as possible, while also providing the user with sufficient details when a security decision produces unexpected results.

Demonstrative examples:
In "Usability of Security: A Case Study" [REF-540], the authors consider human factors in a cryptography product. Some of the weakness relevant discoveries of this case study were: users accidentally leaked sensitive information, could not figure out how to perform some tasks, thought they were enabling a security option when they were not, and made improper trust decisions.

Enforcing complex and difficult-to-remember passwords that need to be frequently changed for access to trivial resources, e.g., to use a black-and-white printer. Complex password requirements can also cause users to store the passwords in an unsafe manner so they don't have to remember them, such as using a sticky note or saving them in an unencrypted file.
CWE-656: Reliance on Security Through Obscurity

Description:
The product uses a protection mechanism whose strength depends heavily on its obscurity, such that knowledge of its algorithms or key data is sufficient to defeat the mechanism.

Extended Description:
This reliance on "security through obscurity" can produce resultant weaknesses if an attacker is able to reverse engineer the inner workings of the mechanism. Note that obscurity can be one small part of defense in depth, since it can create more work for an attacker; however, it is a significant risk if used as the primary means of protection.

Affected languages: Not Language-Specific
Affected technologies: Not Technology-Specific
Parent weaknesses: CWE-657, CWE-693

Consequences:
  - Confidentiality: Other

Mitigations:
  - [Architecture and Design] Always consider whether knowledge of your code or design is sufficient to break it. Reverse engineering is a highly successful discipline, and financially feasible for motivated adversaries. Black-box techniques are established for binary analysis of executables that use obfuscation, runtime analysi
  - [Architecture and Design] When available, use publicly-vetted algorithms and procedures, as these are more likely to undergo more extensive security analysis and testing. This is especially the case with encryption and authentication.

Demonstrative examples:
The design of TCP relies on the secrecy of Initial Sequence Numbers (ISNs), as originally covered in CVE-1999-0077 [REF-542]. If ISNs can be guessed (due to predictability, CWE-330) or sniffed (due to lack of encryption during transmission, CWE-312), then an attacker can hijack or spoof connections. Many TCP implementations have had variations of this problem over the years, including CVE-2004-0641, CVE-2002-1463, CVE-2001-0751, CVE-2001-0328, CVE-2001-0288, CVE-2001-0163, CVE-2001-0162, CVE-2000-0916, and CVE-2000-0328.

Real-world examples:
  - CVE-2006-6588: Reliance on hidden form fields in a web application. Many web application vulnerabilities exist because the developer did not consider that "hidden" form fields can be processed using a modified clien
  - CVE-2006-7142: Hard-coded cryptographic key stored in executable program.
  - CVE-2005-4002: Hard-coded cryptographic key stored in executable program.
  - CVE-2006-4068: Hard-coded hashed values for username and password contained in client-side script, allowing brute-force offline attacks.
CWE-657: Violation of Secure Design Principles

Description:
The product violates well-established principles for secure design.

Extended Description:
This can introduce resultant weaknesses or make it easier for developers to introduce related weaknesses during implementation. Because code is centered around design, it can be resource-intensive to fix design problems.

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

Consequences:
  - Other: Other

Demonstrative examples:
Switches may revert their functionality to that of hubs when the table used to map ARP information to the switch interface overflows, such as when under a spoofing attack. This results in traffic being broadcast to an eavesdropper, instead of being sent only on the relevant switch interface. To mitigate this type of problem, the developer could limit the number of ARP entries that can be recorded for a given switch interface, while other interfaces may keep functioning normally. Configuration options can be provided on the appropriate actions to be taken in case of a detected failure, but safe defaults should be used.

The IPSEC specification is complex, which resulted in bugs, partial implementations, and incompatibilities between vendors.

Real-world examples:
  - CVE-2019-6260: Baseboard Management Controller (BMC) device implements Advanced High-performance Bus (AHB) bridges that do not require authentication for arbitrary read and write access to the BMC's physical address
  - CVE-2007-5277: The failure of connection attempts in a web browser resets DNS pin restrictions. An attacker can then bypass the same origin policy by rebinding a domain name to a different IP address. This was an at
  - CVE-2006-7142: Hard-coded cryptographic key stored in executable program.
  - CVE-2007-0408: Server does not properly validate client certificates when reusing cached connections.
CWE-66: Improper Handling of File Names that Identify Virtual Resources

Description:
The product does not handle or incorrectly handles a file name that identifies a "virtual" resource that is not directly specified within the directory that is associated with the file name, causing the product to perform file-based operations on a resource that is not a file.

Extended Description:
Virtual file names are represented like normal file names, but they are effectively aliases for other resources that do not behave like normal files. Depending on their functionality, they could be alternate entities. They are not necessarily listed in directories.

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

Consequences:
  - Other: Other

Detection methods:
  - Automated Static Analysis - Binary or Bytecode: According to SOAR [REF-1479], the following detection techniques may be useful: 
                   
                      Cost effective for partial coverage: 
                         
             
  - Manual Static Analysis - Binary or Bytecode: According to SOAR [REF-1479], the following detection techniques may be useful: 
                   
                      Cost effective for partial coverage: 
                         
             
  - Dynamic Analysis with Automated Results Interpretation: According to SOAR [REF-1479], the following detection techniques may be useful: 
                   
                      Cost effective for partial coverage: 
                         
             
  - Dynamic Analysis with Manual Results Interpretation: According to SOAR [REF-1479], the following detection techniques may be useful: 
                   
                      Cost effective for partial coverage: 
                         
             

Demonstrative examples:
Consider a web server that uses the Apple
               HFS+ file system. It interprets FILE.cgi as processing
               instructions.
An adversary could request
			   "FILE.cgi/..namedfork/data" to prevent FILE.cgi from
			   being executed, instead disclosing the source code for
			   FILE.cgi. This might occur because the web server
			   invokes the default handler which may return the
			   contents of the file.

Real-world examples:
  - CVE-1999-0278: In IIS, remote attackers can obtain source code for ASP files by appending "::$DATA" to the URL.
  - CVE-2004-1084: Server allows remote attackers to read files and resource fork content via HTTP requests to certain special file names related to multiple data streams in HFS+.
  - CVE-2002-0106: Server allows remote attackers to cause a denial of service via a series of requests to .JSP files that contain an MS-DOS device name.
CWE-663: Use of a Non-reentrant Function in a Concurrent Context

Description:
The product calls a non-reentrant function in a concurrent context in which a competing code sequence (e.g. thread or signal handler) may have an opportunity to call the same function or otherwise influence its state.

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

Consequences:
  - 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:
  - [Implementation] Use reentrant functions if available.
  - [Implementation] Add synchronization to your non-reentrant function.
  - [Implementation] In Java, use the ReentrantLock Class.

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.

The following code relies on getlogin() to determine whether or not a user is trusted. It is easily subverted.

[CREDENTIAL_REDACTED](getlogin()); if (isTrustedGroup(pwd->pw_gid)) { allow(); } else { deny(); }

Real-world examples:
  - CVE-2001-1349: unsafe calls to library functions from signal handler
  - CVE-2004-2259: SIGCHLD signal to FTP server can cause crash under heavy load while executing non-reentrant functions like malloc/free.
CWE-664: Improper Control of a Resource Through its Lifetime

Description:
The product does not maintain or incorrectly maintains control over a resource throughout its lifetime of creation, use, and release.

Extended Description:
Resources often have explicit instructions on how to be created, used and destroyed. When code does not follow these instructions, it can lead to unexpected behaviors and potentially exploitable states. 
             Even without explicit instructions, various principles are expected to be adhered to, such as "Do not use an object until after its creation is complete," or "do not use an object after it has been slated for destruction."

Affected languages: Not Language-Specific
Affected technologies: Not Technology-Specific

Consequences:
  - Other: Other

Detection methods:
  - Automated Static Analysis: Use Static analysis tools to check for unreleased resources.

Demonstrative examples:
This code allocates a socket and forks each time it receives a new connection.
The program does not track how many connections have been made, and it does not limit the number of connections. Because forking is a relatively expensive operation, an attacker would be able to cause the system to run out of CPU, processes, or memory by making a large number of connections. Alternatively, an attacker could consume all available connections, preventing others from accessing the system remotely.
sock=socket(AF_INET, SOCK_STREAM, 0); while (1) { newsock=accept(sock, ...); printf("A connection has been accepted\n"); pid = fork(); }

Real-world examples:
  - CVE-2[PII_REDACTED]: Cryptography API uses unsafe reflection when deserializing a private key
  - CVE-2019-19911: Chain: Python library does not limit the resources used to process images that specify a very large number of bands (CWE-1284), leading to excessive memory consumption (CWE-789) or an integer overflow
CWE-666: Operation on Resource in Wrong Phase of Lifetime

Description:
The product performs an operation on a resource at the wrong phase of the resource's lifecycle, which can lead to unexpected behaviors.

Extended Description:
A resource's lifecycle includes several phases: initialization, use, and release. For each phase, it is important to follow the specifications outlined for how to operate on the resource and to ensure that the resource is in the expected phase. Otherwise, if a resource is in one phase but the operation is not valid for that phase (i.e., an incorrect phase of the resource's lifetime), then this can produce resultant weaknesses. For example, using a resource before it has been fully initialized could cause corruption or incorrect data to be used.

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

Consequences:
  - Other: 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:
  - [Architecture and Design] Follow the resource's lifecycle from creation to release.

Demonstrative examples:
The following code shows a simple example of a double free vulnerability.
Double free vulnerabilities have two common (and sometimes overlapping) causes:
char* ptr = (char*)malloc (SIZE); 
				   ... 
				   if (abrt) {
				    
					 free(ptr);
				    
				   } 
				   ... 
				   free(ptr);

Real-world examples:
  - CVE-2006-5051: Chain: Signal handler contains too much functionality (CWE-828), introducing a race condition (CWE-362) that leads to a double free (CWE-415).
CWE-668: Exposure of Resource to Wrong Sphere

Description:
The product exposes a resource to the wrong control sphere, providing unintended actors with inappropriate access to the resource.

Extended Description:
Resources such as files and directories may be inadvertently exposed through mechanisms such as insecure permissions, or when a program accidentally operates on the wrong object. For example, a program may intend that private files can only be provided to a specific user. This effectively defines a control sphere that is intended to prevent attackers from accessing these private files. If the file permissions are insecure, then parties other than the user will be able to access those files. 
             A separate control sphere might effectively require that the user can only access the private files, but not any other files on the system. If the program does not ensure that the user is only requesting private files, then the user might be able to access other files on the system. 
             In either case, the end result is that a resource has been exposed to the wrong party.

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

Consequences:
  - Confidentiality: Read Application Data
  - Integrity: Modify Application Data
  - Other: Varies by Context
CWE-669: Incorrect Resource Transfer Between Spheres

Description:
The product does not properly transfer a resource/behavior to another sphere, or improperly imports a resource/behavior from another sphere, in a manner that provides unintended control over that resource.

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

Consequences:
  - Confidentiality: Read Application Data

Demonstrative examples:
The following code demonstrates the unrestricted upload of a file with a Java servlet and a path traversal vulnerability. The action attribute of an HTML form is sending the upload file request to the Java servlet.
When submitted the Java servlet's doPost method will receive the request, extract the name of the file from the Http request header, read the file contents from the request and output the file to the local upload directory.
<form action="FileUploadServlet" method="post" enctype="multipart/form-data"> 
                      Choose a file to upload: <input type="file" name="filename"/> <br/> <input type="submit" name="submit" value="Submit"/> 
                      </form>
public class FileUploadServlet extends HttpServlet { 
                      
                         ... 
  

This code includes an external script to get database credentials, then authenticates a user against the database, allowing access to the application.
This code does not verify that the external domain accessed is the intended one. An attacker may somehow cause the external domain name to resolve to an attack server, which would provide the information for a false database. The attacker may then steal the usernames and encrypted passwords from real user login attempts, or simply allow themself to access the application without a real user account.
//assume the password is already encrypted, avoiding CWE-312 
                      
                      function authenticate($username,$password){ 
                         include("http://external.example.com/dbInfo.php"); 
                 

Real-world examples:
  - CVE-2021-22909: Chain: router's firmware update procedure uses curl with "-k" (insecure) option that disables certificate validation (CWE-295), allowing adversary-in-the-middle (AITM) compromise with a malicious firm
  - CVE-2023-5227: PHP-based FAQ management app does not check the MIME type for uploaded images
  - CVE-2005-0406: Some image editors modify a JPEG image, but the original EXIF thumbnail image is left intact within the JPEG. (Also an interaction error).
CWE-67: Improper Handling of Windows Device Names

Description:
The product constructs pathnames from user input, but it does not handle or incorrectly handles a pathname containing a Windows device name such as AUX or CON. This typically leads to denial of service or an information exposure when the application attempts to process the pathname as a regular file.

Extended Description:
Not properly handling virtual filenames (e.g. AUX, CON, PRN, COM1, LPT1) can result in different types of vulnerabilities. In some cases an attacker can request a device via injection of a virtual filename in a URL, which may cause an error that leads to a denial of service or an error page that reveals sensitive information. A product that allows device names to bypass filtering runs the risk of an attacker injecting malicious code in a file with the name of a device.

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

Consequences:
  - Availability: DoS: Crash, Exit, or Restart

Mitigations:
  - [Implementation] Be familiar with the device names in the operating system where your system is deployed. Check input for these device names.

Real-world examples:
  - CVE-2002-0106: Server allows remote attackers to cause a denial of service via a series of requests to .JSP files that contain an MS-DOS device name.
  - CVE-2002-0200: Server allows remote attackers to cause a denial of service via an HTTP request for an MS-DOS device name.
  - CVE-2002-1052: Product allows remote attackers to use MS-DOS device names in HTTP requests to cause a denial of service or obtain the physical path of the server.
  - CVE-2001-0493: Server allows remote attackers to cause a denial of service via a URL that contains an MS-DOS device name.
  - CVE-2001-0558: Server allows a remote attacker to create a denial of service via a URL request which includes a MS-DOS device name.