Skip to content

Latest commit

 

History

History
119 lines (82 loc) · 8.63 KB

mitigations.md

File metadata and controls

119 lines (82 loc) · 8.63 KB

Mitigation Strategies Analysis for ljharb/qs

Mitigation Strategy: Upgrade qs to the Latest Version

  • Description:

    • Step 1: Identify the current version of qs used in your project by checking package.json or your dependency lock file.
    • Step 2: Check the qs GitHub repository or npm page for the latest stable version.
    • Step 3: Update the qs dependency in package.json to the latest version.
    • Step 4: Run npm install or yarn install to update and refresh your lock file.
    • Step 5: Test your application, focusing on query string parsing functionality, to ensure compatibility.

  • List of Threats Mitigated:

    • Prototype Pollution - Severity: High (Latest versions patch known prototype pollution vulnerabilities in qs)
    • Denial of Service (DoS) - Severity: Medium (Newer versions may include performance improvements and bug fixes relevant to DoS)

  • Impact:

    • Prototype Pollution: High Reduction (Significantly reduces risk by incorporating latest security patches in qs)
    • Denial of Service (DoS): Medium Reduction (May improve performance and fix DoS-related bugs in qs)

  • Currently Implemented: [Specify Yes/No/Partially and where it is implemented. Example: Yes - package.json and dependency lock file]

  • Missing Implementation: [Specify where it is missing if not fully implemented. Example: N/A - Fully Implemented / Missing in specific microservice X]

Mitigation Strategy: Input Validation and Sanitization of Query Parameters (Pre-qs Parsing)

  • Description:

    • Step 1: Define a strict schema for expected query parameters before they are processed by qs.
    • Step 2: Implement validation logic before calling qs.parse(). This validation should check against the defined schema.
    • Step 3: Sanitize or reject invalid parameters before passing them to qs.parse().
      • Reject requests with unexpected parameters or values.
      • Sanitize values to conform to expected types if possible.
      • Specifically reject parameters resembling prototype pollution attacks (e.g., __proto__, constructor.prototype).
    • Step 4: Ensure consistent validation across all query parameter handling in your application before qs.parse() is invoked.

  • List of Threats Mitigated:

    • Prototype Pollution - Severity: High (Prevents malicious parameters from being parsed by qs and polluting prototypes)
    • Denial of Service (DoS) - Severity: Low (Reduces DoS risk by rejecting complex or malicious structures before qs parsing)
    • Data Injection Attacks - Severity: Medium (Validation helps prevent broader data injection issues by controlling input to qs)

  • Impact:

    • Prototype Pollution: High Reduction (Strongly reduces risk by pre-parsing input filtering)
    • Denial of Service (DoS): Low Reduction (Minor DoS reduction through early rejection of malformed input)
    • Data Injection Attacks: Medium Reduction (Effectiveness depends on validation schema comprehensiveness)

  • Currently Implemented: [Specify Yes/No/Partially and where it is implemented. Example: Partially - Implemented in API Gateway but not in backend services]

  • Missing Implementation: [Specify where it is missing if not fully implemented. Example: Missing in backend service X and Y]

Mitigation Strategy: Use Object.create(null) for Processing Parsed Data (Post-qs Parsing)

  • Description:

    • Step 1: After parsing with qs.parse(), create a new object using Object.create(null).
    • Step 2: Iterate through the properties of the object returned by qs.parse().
    • Step 3: Copy validated and sanitized properties from the qs.parse() result to the Object.create(null) object. Only copy properties that passed pre-qs input validation.
    • Step 4: Use the Object.create(null) object for all subsequent application logic, isolating from potential prototype pollution from qs parsing.

  • List of Threats Mitigated:

    • Prototype Pollution - Severity: High (Isolates application logic from prototype pollution originating from qs parsing)

  • Impact:

    • Prototype Pollution: High Reduction (Effectively eliminates prototype pollution impact on application logic using the Object.create(null) object)

  • Currently Implemented: [Specify Yes/No/Partially and where it is implemented. Example: No - Not implemented anywhere]

  • Missing Implementation: [Specify where it is missing if not fully implemented. Example: Should be implemented in all modules processing query parameters parsed by qs]

Mitigation Strategy: Freeze or Seal Parsed Objects (Post-qs Parsing)

  • Description:

    • Step 1: After parsing with qs.parse() and processing the data (especially if not using Object.create(null)), apply Object.freeze() or Object.seal() to the object returned by qs.parse(). Object.freeze() is recommended for stronger protection.
    • Step 2: Ensure application logic does not attempt to modify the frozen or sealed object after this step.

  • List of Threats Mitigated:

    • Prototype Pollution - Severity: Medium (Prevents further prototype pollution attempts after qs parsing by making the object immutable)

  • Impact:

    • Prototype Pollution: Medium Reduction (Reduces the window for post-parsing prototype pollution, but doesn't prevent initial pollution during qs parsing if the library is vulnerable)

  • Currently Implemented: [Specify Yes/No/Partially and where it is implemented. Example: No - Not implemented anywhere]

  • Missing Implementation: [Specify where it is missing if not fully implemented. Example: Should be implemented after parsing query parameters with qs in relevant modules]

Mitigation Strategy: Limit Query String Length (DoS related to qs parsing)

  • Description:

    • Step 1: Define a maximum acceptable query string length relevant to your application and server capabilities. Consider the impact of long strings on qs parsing performance.
    • Step 2: Implement a check for query string length before processing with qs.parse().
    • Step 3: Reject requests with query strings exceeding the defined limit, returning a 414 or 400 error.
    • Step 4: Log rejected requests for monitoring and potential DoS detection.

  • List of Threats Mitigated:

    • Denial of Service (DoS) - Severity: Medium (Prevents DoS attacks exploiting qs parsing with excessively long query strings)

  • Impact:

    • Denial of Service (DoS): Medium Reduction (Reduces DoS risk from overly long query strings processed by qs)

  • Currently Implemented: [Specify Yes/No/Partially and where it is implemented. Example: Yes - Implemented in API Gateway configuration]

  • Missing Implementation: [Specify where it is missing if not fully implemented. Example: N/A - Fully Implemented / Needs to be implemented in backend services as a fallback]

Mitigation Strategy: Restrict Parameter Depth and Array Limit in qs Options

  • Description:

    • Step 1: When calling qs.parse(), configure the depth and arrayLimit options to restrict parsing complexity.
      • depth: Set a maximum nesting depth for objects (e.g., 5-10).
      • arrayLimit: Set a maximum array element count (e.g., 20-50).
    • Step 2: Apply these options consistently wherever qs.parse() is used.
    • Step 3: Document the chosen depth and arrayLimit values and their purpose.

  • List of Threats Mitigated:

    • Denial of Service (DoS) - Severity: Medium (Prevents DoS attacks exploiting qs parsing performance with complex nested objects or large arrays)

  • Impact:

    • Denial of Service (DoS): Medium Reduction (Significantly reduces DoS risk from complex query strings parsed by qs by limiting parsing complexity)

  • Currently Implemented: [Specify Yes/No/Partially and where it is implemented. Example: Partially - Implemented in some modules but not consistently]

  • Missing Implementation: [Specify where it is missing if not fully implemented. Example: Missing in modules X, Y, and Z. Needs consistent application across the application]