Krutikp/ComplianceLLM huggingface dataset:
CWE-15: External Control of System or Configuration Setting (Base)

Description: One or more system settings or configuration elements can be externally controlled by a user.

Extended Description: Allowing external control of system settings can disrupt service or cause an application to behave in unexpected, and potentially malicious ways.



Applicable Platforms: ::TECHNOLOGY CLASS:Not Technology-Specific:TECHNOLOGY PREVALENCE:Undetermined::TECHNOLOGY CLASS:ICS/OT:TECHNOLOGY PREVALENCE:Undetermined::

Modes of Introduction: ::PHASE:Implementation:NOTE:Setting manipulation vulnerabilities occur when an attacker can control values that govern the behavior of the system, manage specific resources, or in some way affect the functionality of the application.::PHASE:Implementation:NOTE:REALIZATION: This weakness is caused during implementation of an architectural security tactic.::



Common Consequences: ::SCOPE:Other: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:Architecture and Design:STRATEGY:Separation of Privilege:DESCRIPTION:Compartmentalize the system to have safe areas where trust boundaries can be unambiguously drawn. Do not allow sensitive data to go outside of the trust boundary and always be careful when interfacing with a compartment outside of the safe area. Ensure that appropriate compartmentalization is built into the system design, and the compartmentalization allows for and reinforces privilege separation functionality. Architects and designers should rely on the principle of least privilege to decide the appropriate time to use privileges and the time to drop privileges.::PHASE:Implementation Architecture and Design:DESCRIPTION:Because setting manipulation covers a diverse set of functions, any attempt at illustrating it will inevitably be incomplete. Rather than searching for a tight-knit relationship between the functions addressed in the setting manipulation category, take a step back and consider the sorts of system values that an attacker should not be allowed to control.::PHASE:Implementation Architecture and Design:DESCRIPTION:In general, do not allow user-provided or otherwise untrusted data to control sensitive values. The leverage that an attacker gains by controlling these values is not always immediately obvious, but do not underestimate the creativity of the attacker.::
CWE-76: Improper Neutralization of Equivalent Special Elements (Base)

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.



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

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



Common Consequences: ::SCOPE:Other:IMPACT:Other::


Potential Mitigations: ::PHASE:Requirements:DESCRIPTION:Programming languages and supporting technologies might be chosen which are not subject to these issues.::PHASE:Implementation:DESCRIPTION:Utilize an appropriate mix of allowlist and denylist parsing to filter equivalent special element syntax from all input.::
CWE-93: Improper Neutralization of CRLF Sequences ('CRLF Injection') (Base)

Description: The product uses CRLF (carriage return line feeds) as a special element, e.g. to separate lines or records, but it does not neutralize or incorrectly neutralizes CRLF sequences from inputs.




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

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



Common Consequences: ::SCOPE:Integrity:IMPACT:Modify 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:Implementation:DESCRIPTION:Avoid using CRLF as a special sequence.::PHASE:Implementation:DESCRIPTION:Appropriately filter or quote CRLF sequences in user-controlled input.::

Observed Examples: ::REFERENCE:CVE-2002-1771:DESCRIPTION:CRLF injection enables spam proxy (add mail headers) using email address or name.:LINK:https://www.cve.org/CVERecord?id=CVE-2002-1771::REFERENCE:CVE-2002-1783:DESCRIPTION:CRLF injection in API function arguments modify headers for outgoing requests.:LINK:https://www.cve.org/CVERecord?id=CVE-2002-1783::REFERENCE:CVE-2004-1513:DESCRIPTION:Spoofed entries in web server log file via carriage returns:LINK:https://www.cve.org/CVERecord?id=CVE-2004-1513::REFERENCE:CVE-2006-4624:DESCRIPTION:Chain: inject fake log entries with fake timestamps using CRLF injection:LINK:https://www.cve.org/CVERecord?id=CVE-2006-4624::REFERENCE:CVE-2005-1951:DESCRIPTION:Chain: Application accepts CRLF in an object ID, allowing HTTP response splitting.:LINK:https://www.cve.org/CVERecord?id=CVE-2005-1951::REFERENCE:CVE-2004-1687:DESCRIPTION:Chain: HTTP response splitting via CRLF in parameter related to URL.:LINK:https://www.cve.org/CVERecord?id=CVE-2004-1687::
CWE-112: Missing XML Validation (Base)

Description: The product accepts XML from an untrusted source but does not validate the XML against the proper schema.

Extended Description: Most successful attacks begin with a violation of the programmer's assumptions. By accepting an XML document without validating it against a DTD or XML schema, the programmer leaves a door open for attackers to provide unexpected, unreasonable, or malicious input.



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

Modes of Introduction: ::PHASE:Implementation::



Common Consequences: ::SCOPE:Integrity:IMPACT:Unexpected State::

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:STRATEGY:Input Validation:DESCRIPTION:Always validate XML input against a known XML Schema or DTD. It is not possible for an XML parser to validate all aspects of a document's content because a parser cannot understand the complete semantics of the data. However, a parser can do a complete and thorough job of checking the document's structure and therefore guarantee to the code that processes the document that the content is well-formed.::
CWE-115: Misinterpretation of Input (Base)

Description: The product misinterprets an input, whether from an attacker or another product, in a security-relevant fashion.




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

Modes of Introduction: ::PHASE:Architecture and Design::PHASE:Implementation::



Common Consequences: ::SCOPE:Integrity:IMPACT:Unexpected State::

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::


Observed Examples: ::REFERENCE:CVE-2005-2225:DESCRIPTION:Product sees dangerous file extension in free text of a group discussion, disconnects all users.:LINK:https://www.cve.org/CVERecord?id=CVE-2005-2225::REFERENCE:CVE-2001-0003:DESCRIPTION:Product does not correctly import and process security settings from another product.:LINK:https://www.cve.org/CVERecord?id=CVE-2001-0003::



Notes: ::TYPE:Research Gap:NOTE:This concept needs further study. It is likely a factor in several weaknesses, possibly resultant as well. Overlaps Multiple Interpretation Errors (MIE).::
CWE-128: Wrap-around Error (Base)

Description: Wrap around errors occur whenever a value is incremented past the maximum value for its type and therefore wraps around to a very small, negative, or undefined value.


Background Details: ::Due to how addition is performed by computers, if a primitive is incremented past the maximum value possible for its storage space, the system will not recognize this, and therefore increment each bit as if it still had extra space. Because of how negative numbers are represented in binary, primitives interpreted as signed may wrap to very large negative values.::


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

Modes of Introduction: ::PHASE:Implementation::



Common Consequences: ::SCOPE:Availability:IMPACT:DoS: Crash, Exit, or Restart:IMPACT:DoS: Resource Consumption (CPU):IMPACT:DoS: Resource Consumption (Memory):IMPACT:DoS: Instability:NOTE:This weakness will generally lead to undefined behavior and therefore crashes. In the case of overflows involving loop index variables, the likelihood of infinite loops is also high.::SCOPE:Integrity:IMPACT:Modify Memory:NOTE:If the value in question is important to data (as opposed to flow), simple data corruption has occurred. Also, if the wrap around results in other conditions such as buffer overflows, further memory corruption may occur.::SCOPE:Confidentiality:SCOPE:Availability:SCOPE:Access Control:IMPACT:Execute Unauthorized Code or Commands:IMPACT:Bypass Protection Mechanism:NOTE:This weakness can sometimes trigger buffer overflows which can be used to execute arbitrary code. This is usually outside the scope of a program's implicit security policy.::


Potential Mitigations: ::PHASE::DESCRIPTION:Requirements specification: The choice could be made to use a language that is not susceptible to these issues.::PHASE:Architecture and Design:DESCRIPTION:Provide clear upper and lower bounds on the scale of any protocols designed.::PHASE:Implementation:DESCRIPTION:Perform validation on all incremented variables to ensure that they remain within reasonable bounds.::




Notes: ::TYPE:Relationship:NOTE:The relationship between overflow and wrap-around needs to be examined more closely, since several entries (including CWE-190) are closely related.::
CWE-166: Improper Handling of Missing Special Element (Base)

Description: The product receives input from an upstream component, but it does not handle or incorrectly handles when an expected special element is missing.




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

Modes of Introduction: ::PHASE:Implementation::



Common Consequences: ::SCOPE:Availability:IMPACT:DoS: Crash, Exit, or Restart::


Potential Mitigations: ::PHASE::DESCRIPTION:Developers should anticipate that special elements will be removed in the input vectors of their product. Use an appropriate combination of denylists and allowlists to ensure only valid, expected and appropriate input is processed by the system.::PHASE:Implementation:STRATEGY:Input Validation:DESCRIPTION:Assume all input is malicious. Use an accept known good input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, boat may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as red or blue. Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.::PHASE:Implementation:STRATEGY:Input Validation:DESCRIPTION: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 inputs after they have been checked.::

Observed Examples: ::REFERENCE:CVE-2002-1362:DESCRIPTION:Crash via message type without separator character:LINK:https://www.cve.org/CVERecord?id=CVE-2002-1362::REFERENCE:CVE-2002-0729:DESCRIPTION:Missing special character (separator) causes crash:LINK:https://www.cve.org/CVERecord?id=CVE-2002-0729::REFERENCE:CVE-2002-1532:DESCRIPTION:HTTP GET without rnrn CRLF sequences causes product to wait indefinitely and prevents other users from accessing it:LINK:https://www.cve.org/CVERecord?id=CVE-2002-1532::
CWE-168: Improper Handling of Inconsistent Special Elements (Base)

Description: The product does not properly handle input in which an inconsistency exists between two or more special characters or reserved words.

Extended Description: An example of this problem would be if paired characters appear in the wrong order, or if the special characters are not properly nested.



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

Modes of Introduction: ::PHASE:Implementation::



Common Consequences: ::SCOPE:Availability:SCOPE:Access Control:SCOPE:Non-Repudiation:IMPACT:DoS: Crash, Exit, or Restart:IMPACT:Bypass Protection Mechanism:IMPACT:Hide Activities::


Potential Mitigations: ::PHASE::DESCRIPTION:Developers should anticipate that inconsistent special elements will be injected/manipulated in the input vectors of their product. Use an appropriate combination of denylists and allowlists to ensure only valid, expected and appropriate input is processed by the system.::PHASE:Implementation:STRATEGY:Input Validation:DESCRIPTION:Assume all input is malicious. Use an accept known good input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, boat may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as red or blue. Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.::PHASE:Implementation:STRATEGY:Input Validation:DESCRIPTION: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 inputs after they have been checked.::
CWE-183: Permissive List of Allowed Inputs (Base)

Description: The product implements a protection mechanism that relies on a list of inputs (or properties of inputs) that are explicitly allowed by policy because the inputs are assumed to be safe, but the list is too permissive - that is, it allows an input that is unsafe, leading to resultant weaknesses.



Alternate Terms: ::TERM:Allowlist / Allow List:DESCRIPTION:This is used by CWE and CAPEC instead of other commonly-used terms. Its counterpart is denylist.::TERM:Safelist / Safe List:DESCRIPTION:This is often used by security tools such as firewalls, email or web gateways, proxies, etc.::TERM:Whitelist / White List:DESCRIPTION:This term is frequently used, but usage has been declining as organizations have started to adopt other terms.::

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

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::


Observed Examples: ::REFERENCE:CVE-2019-12799:DESCRIPTION:chain: bypass of untrusted deserialization issue (CWE-502) by using an assumed-trusted class (CWE-183):LINK:https://www.cve.org/CVERecord?id=CVE-2019-12799::REFERENCE:CVE-2019-10458:DESCRIPTION:sandbox bypass using a method that is on an allowlist:LINK:https://www.cve.org/CVERecord?id=CVE-2019-10458::REFERENCE:CVE-2017-1000095:DESCRIPTION:sandbox bypass using unsafe methods that are on an allowlist:LINK:https://www.cve.org/CVERecord?id=CVE-2017-1000095::REFERENCE:CVE-2019-10458:DESCRIPTION:CI/CD pipeline feature has unsafe elements in allowlist, allowing bypass of script restrictions:LINK:https://www.cve.org/CVERecord?id=CVE-2019-10458::REFERENCE:CVE-2017-1000095:DESCRIPTION:Default allowlist includes unsafe methods, allowing bypass of sandbox:LINK:https://www.cve.org/CVERecord?id=CVE-2017-1000095::
CWE-186: Overly Restrictive Regular Expression (Base)

Description: A regular expression is overly restrictive, which prevents dangerous values from being detected.

Extended Description: This weakness is not about regular expression complexity. Rather, it is about a regular expression that does not match all values that are intended. Consider the use of a regexp to identify acceptable values or to spot unwanted terms. An overly restrictive regexp misses some potentially security-relevant values leading to either false positives *or* false negatives, depending on how the regexp is being used within the code. Consider the expression /[0-8]/ where the intention was /[0-9]/. This expression is not complex but the value 9 is not matched when maybe the programmer planned to check for it.



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

Modes of Introduction: ::PHASE:Implementation::



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


Potential Mitigations: ::PHASE:Implementation:DESCRIPTION:Regular expressions can become error prone when defining a complex language even for those experienced in writing grammars. Determine if several smaller regular expressions simplify one large regular expression. Also, subject your regular expression to thorough testing techniques such as equivalence partitioning, boundary value analysis, and robustness. After testing and a reasonable confidence level is achieved, a regular expression may not be foolproof. If an exploit is allowed to slip through, then record the exploit and refactor your regular expression.::

Observed Examples: ::REFERENCE:CVE-2005-1604:DESCRIPTION:MIE. .php.ns bypasses .php$ regexp but is still parsed as PHP by Apache. (manipulates an equivalence property under Apache):LINK:https://www.cve.org/CVERecord?id=CVE-2005-1604::



Notes: ::TYPE:Relationship:NOTE:Can overlap allowlist/denylist errors (CWE-183/CWE-184)::