Krutikp/ComplianceLLM huggingface dataset:
CWE-515: Covert Storage Channel (Base)

Description: A covert storage channel transfers information through the setting of bits by one program and the reading of those bits by another. What distinguishes this case from that of ordinary operation is that the bits are used to convey encoded information.

Extended Description: Covert storage channels occur when out-of-band data is stored in messages for the purpose of memory reuse. Covert channels are frequently classified as either storage or timing channels. Examples would include using a file intended to hold only audit information to convey user passwords--using the name of a file or perhaps status bits associated with it that can be read by all users to signal the contents of the file. Steganography, concealing information in such a manner that no one but the intended recipient knows of the existence of the message, is a good example of a covert storage channel.




Modes of Introduction: ::PHASE:Implementation::



Common Consequences: ::SCOPE:Confidentiality:IMPACT:Read Application Data:NOTE:Covert storage channels may provide attackers with important information about the system in question.::SCOPE:Integrity:SCOPE:Confidentiality:IMPACT:Read Application Data:NOTE:If these messages or packets are sent with unnecessary data contained within, it may tip off malicious listeners as to the process that created the message. With this information, attackers may learn any number of things, including the hardware platform, operating system, or algorithms used by the sender. This information can be of significant value to the user in launching further attacks.::


Potential Mitigations: ::PHASE:Implementation:DESCRIPTION:Ensure that all reserved fields are set to zero before messages are sent and that no unnecessary information is included.::




Notes: ::TYPE:Maintenance:NOTE:As of CWE 4.9, members of the CWE Hardware SIG are working to improve CWE's coverage of transient execution weaknesses, which include issues related to Spectre, Meltdown, and other attacks that create or exploit covert channels. As a result of that work, this entry might change in CWE 4.10.::
CWE-523: Unprotected Transport of Credentials (Base)

Description: Login pages do not use adequate measures to protect the user name and password while they are in transit from the client to the server.


Background Details: ::SSL (Secure Socket Layer) provides data confidentiality and integrity to HTTP. By encrypting HTTP messages, SSL protects from attackers eavesdropping or altering message contents.::



Modes of Introduction: ::PHASE:Architecture and Design:NOTE:OMISSION: This weakness is caused by missing a security tactic during the architecture and design phase.::



Common Consequences: ::SCOPE:Access Control:IMPACT:Gain Privileges or Assume Identity::

Detection Methods: ::METHOD:Automated Static Analysis:DESCRIPTION: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 having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect sources (origins of input) with sinks (destinations where the data interacts with external components, a lower layer such as the OS, etc.):EFFECTIVENESS:High::

Potential Mitigations: ::PHASE:Operation System Configuration:DESCRIPTION:Enforce SSL use for the login page or any page used to transmit user credentials or other sensitive information. Even if the entire site does not use SSL, it MUST use SSL for login. Additionally, to help prevent phishing attacks, make sure that SSL serves the login page. SSL allows the user to verify the identity of the server to which they are connecting. If the SSL serves login page, the user can be certain they are talking to the proper end system. A phishing attack would typically redirect a user to a site that does not have a valid trusted server certificate issued from an authorized supplier.::
CWE-524: Use of Cache Containing Sensitive Information (Base)

Description: The code uses a cache that contains sensitive information, but the cache can be read by an actor outside of the intended control sphere.

Extended Description: Applications may use caches to improve efficiency when communicating with remote entities or performing intensive calculations. A cache maintains a pool of objects, threads, connections, pages, financial data, passwords, or other resources to minimize the time it takes to initialize and access these resources. If the cache is accessible to unauthorized actors, attackers can read the cache and obtain this sensitive information.




Modes of Introduction: ::PHASE:Implementation::



Common Consequences: ::SCOPE:Confidentiality:IMPACT:Read Application Data::

Detection Methods: ::METHOD:Automated Static Analysis:DESCRIPTION: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 having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect sources (origins of input) with sinks (destinations where the data interacts with external components, a lower layer such as the OS, etc.):EFFECTIVENESS:High::

Potential Mitigations: ::PHASE:Architecture and Design:DESCRIPTION:Protect information stored in cache.::PHASE:Architecture and Design:DESCRIPTION:Do not store unnecessarily sensitive information in the cache.::PHASE:Architecture and Design:DESCRIPTION:Consider using encryption in the cache.::
CWE-538: Insertion of Sensitive Information into Externally-Accessible File or Directory (Base)

Description: The product places sensitive information into files or directories that are accessible to actors who are allowed to have access to the files, but not to the sensitive information.




Applicable Platforms: ::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::

Modes of Introduction: ::PHASE:Implementation:NOTE:OMISSION: This weakness is caused by missing a security tactic during the architecture and design phase.::PHASE:Operation:NOTE:OMISSION: This weakness is caused by missing a security tactic during the architecture and design phase.::



Common Consequences: ::SCOPE:Confidentiality:IMPACT:Read Files or Directories::

Detection Methods: ::METHOD:Automated Static Analysis:DESCRIPTION: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 having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect sources (origins of input) with sinks (destinations where the data interacts with external components, a lower layer such as the OS, etc.):EFFECTIVENESS:High::

Potential Mitigations: ::PHASE:Architecture and Design Operation System Configuration:DESCRIPTION:Do not expose file and directory information to the user.::

Observed Examples: ::REFERENCE:CVE-2018-1999036:DESCRIPTION:SSH password for private key stored in build log:LINK:https://www.cve.org/CVERecord?id=CVE-2018-1999036::



Notes: ::TYPE:Maintenance:NOTE:Depending on usage, this could be a weakness or a category. Further study of all its children is needed, and the entire sub-tree may need to be clarified. The current organization is based primarily on the exposure of sensitive information as a consequence, instead of as a primary weakness.::TYPE:Maintenance:NOTE:There is a close relationship with CWE-552, which is more focused on weaknesses. As a result, it may be more appropriate to convert CWE-538 to a category.::
CWE-544: Missing Standardized Error Handling Mechanism (Base)

Description: The product does not use a standardized method for handling errors throughout the code, which might introduce inconsistent error handling and resultant weaknesses.

Extended Description: If the product handles error messages individually, on a one-by-one basis, this is likely to result in inconsistent error handling. The causes of errors may be lost. Also, detailed information about the causes of an error may be unintentionally returned to the user.




Modes of Introduction: ::PHASE:Architecture and Design:NOTE:OMISSION: This weakness is caused by missing a security tactic during the architecture and design phase.::



Common Consequences: ::SCOPE:Integrity:SCOPE:Other:IMPACT:Quality Degradation:IMPACT:Unexpected State:IMPACT:Varies by Context::


Potential Mitigations: ::PHASE:Architecture and Design:DESCRIPTION:define a strategy for handling errors of different severities, such as fatal errors versus basic log events. Use or create built-in language features, or an external package, that provides an easy-to-use API and define coding standards for the detection and handling of errors.::
CWE-547: Use of Hard-coded, Security-relevant Constants (Base)

Description: The product uses hard-coded constants instead of symbolic names for security-critical values, which increases the likelihood of mistakes during code maintenance or security policy change.

Extended Description: If the developer does not find all occurrences of the hard-coded constants, an incorrect policy decision may be made if one of the constants is not changed. Making changes to these values will require code changes that may be difficult or impossible once the system is released to the field. In addition, these hard-coded values may become available to attackers if the code is ever disclosed.




Modes of Introduction: ::PHASE:Implementation::



Common Consequences: ::SCOPE:Other:IMPACT:Varies by Context:IMPACT:Quality Degradation:NOTE:The existence of hardcoded constants could cause unexpected behavior and the introduction of weaknesses during code maintenance or when making changes to the code if all occurrences are not modified. The use of hardcoded constants is an indication of poor quality.::

Detection Methods: ::METHOD:Automated Static Analysis:DESCRIPTION: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 having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect sources (origins of input) with sinks (destinations where the data interacts with external components, a lower layer such as the OS, etc.):EFFECTIVENESS:High::

Potential Mitigations: ::PHASE:Implementation:DESCRIPTION:Avoid using hard-coded constants. Configuration files offer a more flexible solution.::
CWE-549: Missing Password Field Masking (Base)

Description: The product does not mask passwords during entry, increasing the potential for attackers to observe and capture passwords.





Modes of Introduction: ::PHASE:Implementation::



Common Consequences: ::SCOPE:Access Control:IMPACT:Bypass Protection Mechanism::

Detection Methods: ::METHOD:Automated Static Analysis:DESCRIPTION: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 having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect sources (origins of input) with sinks (destinations where the data interacts with external components, a lower layer such as the OS, etc.):EFFECTIVENESS:High::

Potential Mitigations: ::PHASE:Implementation Requirements:DESCRIPTION:Recommendations include requiring all password fields in your web application be masked to prevent other users from seeing this information.::
CWE-551: Incorrect Behavior Order: Authorization Before Parsing and Canonicalization (Base)

Description: If a web server does not fully parse requested URLs before it examines them for authorization, it may be possible for an attacker to bypass authorization protection.

Extended Description: For instance, the character strings /./ and / both mean current directory. If /SomeDirectory is a protected directory and an attacker requests /./SomeDirectory, the attacker may be able to gain access to the resource if /./ is not converted to / before the authorization check is performed.




Modes of Introduction: ::PHASE:Implementation:NOTE:REALIZATION: This weakness is caused during implementation of an architectural security tactic.::



Common Consequences: ::SCOPE:Access Control:IMPACT:Bypass Protection Mechanism::


Potential Mitigations: ::PHASE:Architecture and Design:DESCRIPTION:URL Inputs should be decoded and canonicalized to the application's current internal representation before being validated and processed for authorization. Make sure that your application does not decode the same input twice. Such errors could be used to bypass allowlist schemes by introducing dangerous inputs after they have been checked.::
CWE-552: Files or Directories Accessible to External Parties (Base)

Description: The product makes files or directories accessible to unauthorized actors, even though they should not be.

Extended Description: Web servers, FTP servers, and similar servers may store a set of files underneath a root directory that is accessible to the server's users. Applications may store sensitive files underneath this root without also using access control to limit which users may request those files, if any. Alternately, an application might package multiple files or directories into an archive file (e.g., ZIP or tar), but the application might not exclude sensitive files that are underneath those directories. In cloud technologies and containers, this weakness might present itself in the form of misconfigured storage accounts that can be read or written by a public or anonymous user.



Applicable Platforms: ::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::TECHNOLOGY CLASS:Not Technology-Specific:TECHNOLOGY PREVALENCE:Undetermined::TECHNOLOGY CLASS:Cloud Computing:TECHNOLOGY PREVALENCE:Often::

Modes of Introduction: ::PHASE:Architecture and Design::PHASE:Implementation:NOTE:OMISSION: This weakness is caused by missing a security tactic during the architecture and design phase.::PHASE:Operation:NOTE:OMISSION: This weakness is caused by missing a security tactic during the architecture and design phase.::



Common Consequences: ::SCOPE:Confidentiality:SCOPE:Integrity:IMPACT:Read Files or Directories:IMPACT:Modify Files or Directories::

Detection Methods: ::METHOD:Automated Static Analysis:DESCRIPTION: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 having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect sources (origins of input) with sinks (destinations where the data interacts with external components, a lower layer such as the OS, etc.):EFFECTIVENESS:High::

Potential Mitigations: ::PHASE:Implementation System Configuration Operation:DESCRIPTION:When storing data in the cloud (e.g., S3 buckets, Azure blobs, Google Cloud Storage, etc.), use the provider's controls to disable public access.::

Observed Examples: ::REFERENCE:CVE-2005-1835:DESCRIPTION:Data file under web root.:LINK:https://www.cve.org/CVERecord?id=CVE-2005-1835::


Affected Resources: ::File or Directory::
CWE-562: Return of Stack Variable Address (Base)

Description: A function returns the address of a stack variable, which will cause unintended program behavior, typically in the form of a crash.

Extended Description: Because local variables are allocated on the stack, when a program returns a pointer to a local variable, it is returning a stack address. A subsequent function call is likely to re-use this same stack address, thereby overwriting the value of the pointer, which no longer corresponds to the same variable since a function's stack frame is invalidated when it returns. At best this will cause the value of the pointer to change unexpectedly. In many cases it causes the program to crash the next time the pointer is dereferenced.



Applicable Platforms: ::LANGUAGE NAME:C:LANGUAGE PREVALENCE:Undetermined::LANGUAGE NAME:C++:LANGUAGE PREVALENCE:Undetermined::

Modes of Introduction: ::PHASE:Implementation::



Common Consequences: ::SCOPE:Availability:SCOPE:Integrity:SCOPE:Confidentiality:IMPACT:Read Memory:IMPACT:Modify Memory:IMPACT:Execute Unauthorized Code or Commands:IMPACT:DoS: Crash, Exit, or Restart:NOTE:If the returned stack buffer address is dereferenced after the return, then an attacker may be able to modify or read memory, depending on how the address is used. If the address is used for reading, then the address itself may be exposed, or the contents that the address points to. If the address is used for writing, this can lead to a crash and possibly code execution.::

Detection Methods: ::METHOD:Fuzzing:DESCRIPTION: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 random inputs, it is often capable of generating unexpected results such as crashes, memory corruption, or resource consumption. Fuzzing effectively produces repeatable test cases that clearly indicate bugs, which helps developers to diagnose the issues.:EFFECTIVENESS:High::METHOD:Automated Static Analysis:DESCRIPTION: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 having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect sources (origins of input) with sinks (destinations where the data interacts with external components, a lower layer such as the OS, etc.):EFFECTIVENESS:High::

Potential Mitigations: ::PHASE:Testing:DESCRIPTION:Use static analysis tools to spot return of the address of a stack variable.::
CWE-563: Assignment to Variable without Use (Base)

Description: The variable's value is assigned but never used, making it a dead store.

Extended Description: After the assignment, the variable is either assigned another value or goes out of scope. It is likely that the variable is simply vestigial, but it is also possible that the unused variable points out a bug.


Alternate Terms: ::TERM:Unused Variable::


Modes of Introduction: ::PHASE:Implementation::



Common Consequences: ::SCOPE:Other:IMPACT:Quality Degradation:IMPACT:Varies by Context:NOTE:This weakness could be an indication of a bug in the program or a deprecated variable that was not removed and is an indication of poor quality. This could lead to further bugs and the introduction of weaknesses.::

Detection Methods: ::METHOD:Automated Static Analysis:DESCRIPTION: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 having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect sources (origins of input) with sinks (destinations where the data interacts with external components, a lower layer such as the OS, etc.):EFFECTIVENESS:High::

Potential Mitigations: ::PHASE:Implementation:DESCRIPTION:Remove unused variables from the code.::
CWE-565: Reliance on Cookies without Validation and Integrity Checking (Base)

Description: The product relies on the existence or values of cookies when performing security-critical operations, but it does not properly ensure that the setting is valid for the associated user.

Extended Description: Attackers can easily modify cookies, within the browser or by implementing the client-side code outside of the browser. Reliance on cookies without detailed validation and integrity checking can allow attackers to bypass authentication, conduct injection attacks such as SQL injection and cross-site scripting, or otherwise modify inputs in unexpected ways.




Modes of Introduction: ::PHASE:Architecture and Design:NOTE:OMISSION: This weakness is caused by missing a security tactic during the architecture and design phase.::PHASE:Implementation::



Common Consequences: ::SCOPE:Access Control:IMPACT:Gain Privileges or Assume Identity:NOTE:It is dangerous to use cookies to set a user's privileges. The cookie can be manipulated to escalate an attacker's privileges to an administrative level.::

Detection Methods: ::METHOD:Automated Static Analysis:DESCRIPTION: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 having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect sources (origins of input) with sinks (destinations where the data interacts with external components, a lower layer such as the OS, etc.):EFFECTIVENESS:High::

Potential Mitigations: ::PHASE:Architecture and Design:DESCRIPTION:Avoid using cookie data for a security-related decision.::PHASE:Implementation:DESCRIPTION:Perform thorough input validation (i.e.: server side validation) on the cookie data if you're going to use it for a security related decision.::PHASE:Architecture and Design:DESCRIPTION:Add integrity checks to detect tampering.::PHASE:Architecture and Design:DESCRIPTION:Protect critical cookies from replay attacks, since cross-site scripting or other attacks may allow attackers to steal a strongly-encrypted cookie that also passes integrity checks. This mitigation applies to cookies that should only be valid during a single transaction or session. By enforcing timeouts, you may limit the scope of an attack. As part of your integrity check, use an unpredictable, server-side value that is not exposed to the client.::

Observed Examples: ::REFERENCE:CVE-2008-5784:DESCRIPTION:e-dating application allows admin privileges by setting the admin cookie to 1.:LINK:https://www.cve.org/CVERecord?id=CVE-2008-5784::



Notes: ::TYPE:Relationship:NOTE:This problem can be primary to many types of weaknesses in web applications. A developer may perform proper validation against URL parameters while assuming that attackers cannot modify cookies. As a result, the program might skip basic input validation to enable cross-site scripting, SQL injection, price tampering, and other attacks..::
CWE-570: Expression is Always False (Base)

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




Applicable Platforms: ::LANGUAGE CLASS:Not Language-Specific:LANGUAGE PREVALENCE:Undetermined::

Modes of Introduction: ::PHASE:Implementation::



Common Consequences: ::SCOPE:Other:IMPACT:Quality Degradation:IMPACT:Varies by Context::

Detection Methods: ::METHOD:Automated Static Analysis:DESCRIPTION: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 having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect sources (origins of input) with sinks (destinations where the data interacts with external components, a lower layer such as the OS, etc.):EFFECTIVENESS:High::

Potential Mitigations: ::PHASE:Testing:DESCRIPTION:Use Static Analysis tools to spot such conditions.::