Skip to content

Latest commit

 

History

History
118 lines (89 loc) · 8.81 KB

mitigations.md

File metadata and controls

118 lines (89 loc) · 8.81 KB

Mitigation Strategies Analysis for apache/incubator-apisix

Mitigation Strategy: Rigorous Plugin Vetting (APISIX-Centric Aspects)

Mitigation Strategy: Implement a formal process for vetting all plugins, focusing on APISIX-specific interactions.

Description:

  1. Source Code Review (APISIX Focus): Review plugin code, paying specific attention to how it interacts with APISIX APIs and features:
    • How does it use APISIX's request/response modification capabilities? Are there potential injection vulnerabilities?
    • Does it interact with APISIX's routing logic? Could it be used to bypass intended routing rules?
    • Does it use APISIX's context variables? Are they handled securely?
    • Does it register custom filters or hooks? Are these implemented securely?
  2. APISIX Configuration Review: Examine the plugin's configuration within APISIX. Ensure it adheres to the principle of least privilege (see next strategy).
  3. Sandboxing (APISIX-Limited): While full sandboxing is often external, consider if APISIX's features (e.g., running plugins in separate worker processes, if supported) can provide some level of isolation. This is a weaker form of sandboxing.
  4. Documentation: Document how the plugin interacts with APISIX.

Threats Mitigated:

  • Malicious Plugin Injection (Severity: Critical): Prevents attackers from introducing malicious code that exploits APISIX's features.
  • Logic Flaws in Plugins (APISIX-Specific) (Severity: High/Critical): Identifies vulnerabilities related to how the plugin uses APISIX's APIs and features.

Impact:

  • Malicious Plugin Injection: Risk significantly reduced (focused on APISIX-related attack vectors).
  • Logic Flaws in Plugins (APISIX-Specific): Risk significantly reduced.

Currently Implemented:

  • Basic source code review is performed, but not specifically focused on APISIX interactions.

Missing Implementation:

  • Formalized review of plugin interactions with APISIX APIs.
  • Documentation of APISIX-specific plugin behavior.

Mitigation Strategy: Principle of Least Privilege (Plugin Level - APISIX Configuration)

Mitigation Strategy: Configure each plugin within APISIX with the absolute minimum permissions.

Description:

  1. Identify Plugin Needs (APISIX-Specific): Analyze the plugin's intended functionality and determine the minimum set of APISIX features it needs to access. This is entirely within APISIX's configuration. Examples:
    • request_uri_only: Does the plugin only need to read the request URI, or does it need to modify it?
    • header_filter: Does it need to modify all headers, or only specific ones? Use header filtering rules.
    • body_filter: Does it need to access the request/response body? If so, can you limit the size of the body it can access?
    • access_by_lua*: If the plugin uses Lua code, carefully review the code and ensure it only accesses the necessary APISIX context variables and functions.
  2. APISIX Configuration: Use APISIX's configuration options (within the plugin's configuration block in the route, service, or global configuration) to restrict its access. APISIX provides fine-grained control.
  3. Regular Review: Periodically review the plugin's configuration within APISIX to ensure it still adheres to the principle of least privilege.

Threats Mitigated:

  • Plugin Compromise (Severity: High/Critical): Limits the damage if a plugin is compromised through APISIX.
  • Unintentional Misconfiguration (Severity: Medium/High): Reduces the risk of accidentally granting excessive permissions within APISIX.

Impact:

  • Plugin Compromise: Risk significantly reduced (the degree depends on how granular APISIX's permissions are).
  • Unintentional Misconfiguration: Risk moderately reduced.

Currently Implemented:

  • Basic attempts are made to limit plugin permissions during initial configuration within APISIX.

Missing Implementation:

  • No formal process for regularly reviewing plugin permissions within APISIX's configuration.
  • No automated checks to ensure plugins are not granted excessive permissions within APISIX.

Mitigation Strategy: Rate Limiting and Connection Limiting (Using APISIX Plugins)

Mitigation Strategy: Implement rate limiting and connection limiting using APISIX's built-in plugins.

Description:

  1. Identify Critical Routes: Determine which routes are most critical and vulnerable to DoS attacks.
  2. Configure APISIX Plugins:
    • Use APISIX's limit-req, limit-conn, or limit-count plugins (or a combination). These are core APISIX features.
    • Configure these plugins within APISIX's route or service configurations.
    • Set appropriate rate limits (requests per second/minute) and connection limits for each route or group of routes.
    • Consider different limits for different client IPs or API keys (using APISIX's variables and routing capabilities).
  3. Testing: Thoroughly test the configurations through APISIX under simulated load.
  4. Monitoring (APISIX Metrics): Use APISIX's built-in monitoring capabilities (if available) or integrate with external monitoring tools to track rate limiting and connection limiting metrics. This allows you to see if limits are being hit and adjust them.

Threats Mitigated:

  • Denial of Service (DoS) against APISIX (Severity: High): Prevents attackers from overwhelming APISIX itself.
  • Resource Exhaustion (Severity: High): Protects APISIX from running out of resources.

Impact:

  • Denial of Service (DoS) against APISIX: Risk significantly reduced (effectiveness depends on the configuration).
  • Resource Exhaustion: Risk significantly reduced.

Currently Implemented:

  • Basic rate limiting is implemented on a few routes using the limit-req plugin within APISIX.

Missing Implementation:

  • Comprehensive rate limiting is not applied to all routes within APISIX.
  • Connection limiting (using APISIX plugins) is not implemented.
  • No use of APISIX's monitoring features for rate limiting.

Mitigation Strategy: Input Validation and Data Transformation (Using APISIX Plugins and Features)

Mitigation Strategy: Utilize APISIX's built-in plugins and features for input validation and data transformation to prevent injection attacks and data exposure.

Description:

  1. Identify Sensitive Inputs: Determine which request parameters, headers, or body fields contain sensitive data or are susceptible to injection attacks.
  2. Utilize APISIX Plugins:
    • Employ APISIX plugins like request-validation to define schemas and validate incoming requests against those schemas. This enforces data types, formats, and allowed values.
    • Use transformation plugins (e.g., custom Lua plugins or built-in transformation features) to sanitize or encode data before it's passed to upstream services. This can prevent SQL injection, XSS, and other injection attacks.
    • Leverage APISIX's URI rewriting and request/response modification capabilities to remove or replace sensitive data before it's logged or returned to the client.
  3. Configuration within APISIX: Configure these plugins and features within APISIX's route or service configurations. Define the validation rules, transformation logic, and data masking patterns.
  4. Testing: Thoroughly test the input validation and transformation rules through APISIX to ensure they are effective and do not introduce unintended side effects.

Threats Mitigated:

  • Injection Attacks (Severity: High/Critical): Prevents SQL injection, XSS, command injection, and other injection attacks by validating and sanitizing input data within APISIX.
  • Data Exposure (Severity: High): Reduces the risk of exposing sensitive data by masking or redacting it within APISIX before it's logged or returned to the client.

Impact:

  • Injection Attacks: Risk significantly reduced (effectiveness depends on the comprehensiveness of the validation and sanitization rules).
  • Data Exposure: Risk moderately to significantly reduced (depending on the data masking/redaction strategy).

Currently Implemented:

  • Limited use of the request-validation plugin for basic data type checks on a few routes.

Missing Implementation:

  • Comprehensive input validation using schemas is not implemented for all routes.
  • Data transformation and sanitization using APISIX plugins are not widely used.
  • No consistent approach to data masking or redaction within APISIX.