Skip to content

Latest commit

 

History

History
49 lines (39 loc) · 5.75 KB

threat-modeling.md

File metadata and controls

49 lines (39 loc) · 5.75 KB

Threat Model Analysis for shopify/liquid

Threat: Unintended Information Disclosure (Data Leakage)

  • Threat: Unintended Information Disclosure (Data Leakage)

    • Description: An attacker could craft specific requests or observe application behavior to gain access to sensitive data exposed through the Liquid template. This might involve manipulating input parameters that influence the template's output or analyzing error messages that reveal internal object structures. The attacker might try different combinations of valid and invalid inputs to see what data is returned.
    • Impact: Exposure of sensitive data such as internal IDs, API keys, user details, database structures, or other confidential information. This could lead to further attacks, data breaches, or reputational damage.
    • Liquid Component Affected: Template rendering engine, object access (e.g., {{ object }}, {{ object.property }}), loops ({% for ... %}), conditional statements ({% if ... %}).
    • Risk Severity: High (Potentially Critical if highly sensitive data is exposed)
    • Mitigation Strategies:
      • Strict Data Control: Pass only the absolute minimum necessary data to the Liquid context. Use view models/presenters to expose only required fields.
      • Explicit Field Access: Always use dot notation to access specific object properties (e.g., {{ user.name }}), never {{ object }} directly.
      • Template Review: Thoroughly review all Liquid templates, paying close attention to loops and conditionals, to ensure no unintended data exposure.
      • Linter/Static Analysis: Employ linters or static analysis tools designed for Liquid templates to detect potential data leakage.
      • Regular Audits: Conduct regular audits of the application's output to verify that no sensitive information is being leaked.

Threat: Denial of Service (DoS) via Resource Exhaustion

  • Threat: Denial of Service (DoS) via Resource Exhaustion

    • Description: An attacker could submit crafted input that causes the Liquid template to consume excessive server resources (CPU, memory). This could involve triggering deeply nested loops, performing extensive string manipulations, or abusing custom filters/tags that perform expensive operations (although the abuse of custom filters/tags is the direct Liquid threat, the vulnerability itself would be in the implementation of those filters/tags). The attacker might send a large number of requests designed to trigger these resource-intensive operations.
    • Impact: The application becomes unresponsive or crashes, preventing legitimate users from accessing it. This can lead to service disruption, financial losses, and reputational damage.
    • Liquid Component Affected: Template rendering engine, loops ({% for ... %}), string manipulation filters (e.g., append, prepend, replace), and the invocation of custom filters/tags (even if the vulnerability is in their implementation).
    • Risk Severity: High
    • Mitigation Strategies:
      • Input Size Limits: Limit the size of collections and strings passed to the Liquid context. Implement pagination.
      • Liquid Resource Limits: Configure Liquid rendering limits:
        • Rendering Time: Set a maximum rendering time.
        • Iteration Count: Limit the number of loop iterations.
        • Output Size: Restrict the maximum size of the rendered output.
      • Custom Filter/Tag Optimization: Review and optimize custom filters/tags for efficiency. Implement caching where appropriate. Crucially, ensure the custom filters/tags themselves are not vulnerable.
      • Server Monitoring: Monitor server resource usage (CPU, memory, rendering time) to detect potential DoS attacks.
      • Rate Limiting: Implement rate limiting on endpoints that render Liquid templates, especially those processing user input.

Threat: Template Injection (User-Controlled Templates)

  • Threat: Template Injection (User-Controlled Templates)

    • Description: If users are allowed to directly input or modify Liquid template code, they can inject malicious Liquid syntax. While Liquid is designed to be relatively safe, an attacker could still cause denial-of-service or attempt to access internal data. The attacker would directly input malicious Liquid code into a field that is then rendered as a template.
    • Impact: Denial of service (most likely). Potentially limited information disclosure if the attacker can access internal variables. Unlikely to lead to full code execution due to Liquid's sandboxed nature.
    • Liquid Component Affected: The entire Liquid rendering engine.
    • Risk Severity: High
    • Mitigation Strategies:
      • Prohibit User-Provided Templates: Never allow users to directly input or modify Liquid template code. This is the most crucial mitigation.
      • Whitelist Approach: If user input must influence the template, use a strict whitelist of allowed variables and filters. Do not allow arbitrary Liquid syntax.
      • Restricted Context: Use a separate, highly restricted Liquid context for any user-influenced content. This context should have minimal access to variables and filters.
      • Alternative Templating Engine: If user-provided templates are a requirement, consider using a different templating engine specifically designed for this purpose, with built-in sandboxing and security features. Liquid is not designed for this use case.