deardaniel/secdata-raw huggingface dataset:
CWE-152: Improper Neutralization of Macro Symbols

Description:
The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could be interpreted as macro symbols when they are sent to a downstream component.

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

Consequences:
  - Integrity: Unexpected State

Mitigations:
  - [Implementation] Developers should anticipate that macro symbols will be injected/removed/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.
  - [Implementation] 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 pe
  - [Implementation] Use and specify an output encoding that can be handled by the downstream component that is reading the output. Common encodings include ISO-8859-1, UTF-7, and UTF-8. When an encoding is not specified, a downstream component may choose a different encoding, either by assuming a default encoding or au
  - [Implementation] Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174). Such errors could be used to bypass allowlist validation schemes by introducing dangerous i

Real-world examples:
  - CVE-2002-0770: Server trusts client to expand macros, allows macro characters to be expanded to trigger resultant information exposure.
  - CVE-2008-2018: Attacker can obtain sensitive information from a database by using a comment containing a macro, which inserts the data during expansion.
CWE-153: Improper Neutralization of Substitution Characters

Description:
The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could be interpreted as substitution characters when they are sent to a downstream component.

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

Consequences:
  - Integrity: Unexpected State

Mitigations:
  - Developers should anticipate that substitution characters will be injected/removed/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.
  - [Implementation] 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 pe
  - [Implementation] While it is risky to use dynamically-generated query strings, code, or commands that mix control and data together, sometimes it may be unavoidable. Properly quote arguments and escape any special characters within those arguments. The most conservative approach is to escape or filter all characters
  - [Implementation] Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174). Such errors could be used to bypass allowlist validation schemes by introducing dangerous i

Real-world examples:
  - CVE-2002-0770: Server trusts client to expand macros, allows macro characters to be expanded to trigger resultant information exposure.
CWE-154: Improper Neutralization of Variable Name Delimiters

Description:
The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could be interpreted as variable name delimiters when they are sent to a downstream component.

Extended Description:
As data is parsed, an injected delimiter may cause the process to take unexpected actions that result in an attack. Example: "$" for an environment variable.

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

Consequences:
  - Integrity: Unexpected State

Mitigations:
  - Developers should anticipate that variable name delimiters will be injected/removed/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.
  - [Implementation] 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 pe
  - [Implementation] While it is risky to use dynamically-generated query strings, code, or commands that mix control and data together, sometimes it may be unavoidable. Properly quote arguments and escape any special characters within those arguments. The most conservative approach is to escape or filter all characters
  - [Implementation] Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174). Such errors could be used to bypass allowlist validation schemes by introducing dangerous i

Real-world examples:
  - CVE-2005-0129: "%" variable is expanded by wildcard function into disallowed commands.
  - CVE-2002-0770: Server trusts client to expand macros, allows macro characters to be expanded to trigger resultant information exposure.
CWE-155: Improper Neutralization of Wildcards or Matching Symbols

Description:
The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could be interpreted as wildcards or matching symbols when they are sent to a downstream component.

Extended Description:
As data is parsed, an injected element may cause the process to take unexpected actions.

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

Consequences:
  - Integrity: Unexpected State

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:
  - Developers should anticipate that wildcard or matching elements will be injected/removed/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.
  - [Implementation] 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 pe
  - [Implementation] While it is risky to use dynamically-generated query strings, code, or commands that mix control and data together, sometimes it may be unavoidable. Properly quote arguments and escape any special characters within those arguments. The most conservative approach is to escape or filter all characters
  - [Implementation] Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174). Such errors could be used to bypass allowlist validation schemes by introducing dangerous i

Real-world examples:
  - CVE-2002-0433: List files in web server using "*.ext"
  - CVE-2002-1010: Bypass file restrictions using wildcard character.
  - CVE-2001-0334: Wildcards generate long string on expansion.
  - CVE-2004-1962: SQL injection involving "/**/" sequences.
CWE-156: Improper Neutralization of Whitespace

Description:
The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could be interpreted as whitespace when they are sent to a downstream component.

Extended Description:
This can include space, tab, etc.

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

Consequences:
  - Integrity: Unexpected State

Mitigations:
  - Developers should anticipate that whitespace will be injected/removed/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.
  - [Implementation] 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 pe
  - [Implementation] While it is risky to use dynamically-generated query strings, code, or commands that mix control and data together, sometimes it may be unavoidable. Properly quote arguments and escape any special characters within those arguments. The most conservative approach is to escape or filter all characters
  - [Implementation] Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174). Such errors could be used to bypass allowlist validation schemes by introducing dangerous i

Real-world examples:
  - CVE-2002-0637: MIE. virus protection bypass with RFC violations involving extra whitespace, or missing whitespace.
  - CVE-2004-0942: CPU consumption with MIME headers containing lines with many space characters, probably due to algorithmic complexity (RESOURCE.AMP.ALG).
  - CVE-2003-1015: MIE. whitespace interpreted differently by mail clients.
CWE-157: Failure to Sanitize Paired Delimiters

Description:
The product does not properly handle the characters that are used to mark the beginning and ending of a group of entities, such as parentheses, brackets, and braces.

Extended Description:
Paired delimiters might include: 
                
                   < and > angle brackets 
                   ( and ) parentheses 
                   { and } braces 
                   [ and ] square brackets 
                   " " double quotes 
                   ' ' single quotes

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

Consequences:
  - Integrity: Unexpected State

Mitigations:
  - Developers should anticipate that grouping elements will be injected/removed/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.
  - [Implementation] 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 pe
  - [Implementation] While it is risky to use dynamically-generated query strings, code, or commands that mix control and data together, sometimes it may be unavoidable. Properly quote arguments and escape any special characters within those arguments. The most conservative approach is to escape or filter all characters
  - [Implementation] Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174). Such errors could be used to bypass allowlist validation schemes by introducing dangerous i

Real-world examples:
  - CVE-2004-0956: Crash via missing paired delimiter (open double-quote but no closing double-quote).
  - CVE-2000-1165: Crash via message without closing ">".
  - CVE-2005-2933: Buffer overflow via mailbox name with an opening double quote but missing a closing double quote, causing a larger copy than expected.
CWE-158: Improper Neutralization of Null Byte or NUL Character

Description:
The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes NUL characters or null bytes when they are sent to a downstream component.

Extended Description:
As data is parsed, an injected NUL character or null byte may cause the product to believe the input is terminated earlier than it actually is, or otherwise cause the input to be misinterpreted. This could then be used to inject potentially dangerous input that occurs after the null byte or otherwise bypass validation routines and other protection mechanisms.

Affected languages: Not Language-Specific, C, C++
Affected technologies: Not Technology-Specific
Parent weaknesses: CWE-138

Consequences:
  - Integrity: Unexpected State

Mitigations:
  - Developers should anticipate that null characters or null bytes will be injected/removed/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.
  - [Implementation] 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 pe
  - [Implementation] Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174). Such errors could be used to bypass allowlist validation schemes by introducing dangerous i

Real-world examples:
  - CVE-2008-1284: NUL byte in theme name causes directory traversal impact to be worse
  - CVE-2005-2008: Source code disclosure using trailing null.
  - CVE-2005-3293: Source code disclosure using trailing null.
  - CVE-2005-2061: Trailing null allows file include.
  - CVE-2002-1774: Null character in MIME header allows detection bypass.
CWE-159: Improper Handling of Invalid Use of Special Elements

Description:
The product does not properly filter, remove, quote, or otherwise manage the invalid use of special elements in user-controlled input, which could cause adverse effect on its behavior and integrity.

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

Consequences:
  - Integrity: Unexpected State

Mitigations:
  - Developers should anticipate that special elements will be injected/removed/manipulated in the input vectors of their software system. Use an appropriate combination of denylists and allowlists to ensure only valid, expected and appropriate input is processed by the system.
  - [Implementation] 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 pe
  - [Implementation] While it is risky to use dynamically-generated query strings, code, or commands that mix control and data together, sometimes it may be unavoidable. Properly quote arguments and escape any special characters within those arguments. The most conservative approach is to escape or filter all characters
  - [Implementation] Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174). Such errors could be used to bypass allowlist validation schemes by introducing dangerous i

Real-world examples:
  - CVE-2002-1362: Crash via message type without separator character
  - CVE-2000-0116: Extra "<" in front of SCRIPT tag bypasses XSS prevention.
CWE-160: Improper Neutralization of Leading Special Elements

Description:
The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes leading special elements that could be interpreted in unexpected ways when they are sent to a downstream component.

Extended Description:
As data is parsed, improperly handled leading special elements may cause the process to take unexpected actions that result in an attack.

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

Consequences:
  - Integrity: Unexpected State

Mitigations:
  - Developers should anticipate that leading special elements will be injected/removed/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.
  - [Implementation] 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 pe
  - [Implementation] While it is risky to use dynamically-generated query strings, code, or commands that mix control and data together, sometimes it may be unavoidable. Properly quote arguments and escape any special characters within those arguments. The most conservative approach is to escape or filter all characters
  - [Implementation] Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174). Such errors could be used to bypass allowlist validation schemes by introducing dangerous i

Real-world examples:
  - CVE-2002-1345: Multiple FTP clients write arbitrary files via absolute paths in server responses
CWE-161: Improper Neutralization of Multiple Leading Special Elements

Description:
The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes multiple leading special elements that could be interpreted in unexpected ways when they are sent to a downstream component.

Extended Description:
As data is parsed, improperly handled multiple leading special elements may cause the process to take unexpected actions that result in an attack.

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

Consequences:
  - Integrity: Unexpected State

Mitigations:
  - Developers should anticipate that multiple leading special elements will be injected/removed/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.
  - [Implementation] 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 pe
  - [Implementation] While it is risky to use dynamically-generated query strings, code, or commands that mix control and data together, sometimes it may be unavoidable. Properly quote arguments and escape any special characters within those arguments. The most conservative approach is to escape or filter all characters
  - [Implementation] Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174). Such errors could be used to bypass allowlist validation schemes by introducing dangerous i

Real-world examples:
  - CVE-2002-1238: Server allows remote attackers to bypass access restrictions for files via an HTTP request with a sequence of multiple / (slash) characters such as http://www.example.com///file/.
CWE-162: Improper Neutralization of Trailing Special Elements

Description:
The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes trailing special elements that could be interpreted in unexpected ways when they are sent to a downstream component.

Extended Description:
As data is parsed, improperly handled trailing special elements may cause the process to take unexpected actions that result in an attack.

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

Consequences:
  - Integrity: Unexpected State

Mitigations:
  - Developers should anticipate that trailing special elements will be injected/removed/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.
  - [Implementation] 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 pe
  - [Implementation] While it is risky to use dynamically-generated query strings, code, or commands that mix control and data together, sometimes it may be unavoidable. Properly quote arguments and escape any special characters within those arguments. The most conservative approach is to escape or filter all characters
  - [Implementation] Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174). Such errors could be used to bypass allowlist validation schemes by introducing dangerous i

Real-world examples:
  - CVE-2004-0847: web framework for .NET allows remote attackers to bypass authentication for .aspx files in restricted directories via a request containing a (1) "\" (backslash) or (2) "%5C" (encoded backslash)
  - CVE-2002-1451: Trailing space ("+" in query string) leads to source code disclosure.
  - CVE-2001-0446: Application server allows remote attackers to read source code for .jsp files by appending a / to the requested URL.