attack-surface.md

Attack Surface Analysis for app-vnext/polly

Attack Surface: Policy Configuration Injection

• Description: Vulnerability where attackers can manipulate input data to alter the intended behavior of Polly policies by injecting malicious configurations. This arises when policy definitions are dynamically constructed based on untrusted input without proper validation.
• Polly Contribution: Polly's flexible and code-driven policy configuration mechanism, while powerful, becomes an attack vector if dynamic policy creation is not secured against injection.
• Example: An application dynamically builds a RetryPolicy where the RetryCount is taken directly from a user-supplied HTTP header. An attacker sets this header to an extremely large value, causing Polly to execute excessive retries, overwhelming backend services.
• Impact: Denial of Service (DoS), circumvention of intended resilience mechanisms, potential cascading failures, application instability.
• Risk Severity: High
• Mitigation Strategies:
  • Parameterize Policy Configuration: Favor defining policies in code or secure configuration files. If dynamic configuration is necessary, use parameterization and avoid directly embedding untrusted input into policy definitions.
  • Input Validation for Policy Parameters: Strictly validate and sanitize any external input that must be used to configure Polly policies. Use allow-lists and enforce type and range constraints.
  • Immutable Policy Definitions: Where possible, define policies as immutable objects to prevent runtime modification based on untrusted input.

Attack Surface: Resource Exhaustion through Policy Abuse (Specifically Bulkhead and Cache Policies)

• Description: Vulnerability where attackers can abuse specific Polly policies, particularly Bulkhead and Cache, to cause resource exhaustion in the application or dependent systems. This occurs when these policies are not configured with appropriate resource limits.
• Polly Contribution: Polly's Bulkhead and Cache policies, designed for resource management and performance, can become attack vectors if their configuration allows for unbounded resource consumption.
• Example (Bulkhead): An attacker floods the application with concurrent requests, targeting a Polly Bulkhead policy that lacks properly configured MaxParallelization or MaxQueuingActions limits. This leads to thread pool exhaustion, request queuing overload, and application slowdown or DoS.
• Example (Cache): An attacker repeatedly requests unique data that is cached by a Polly Cache policy without size limits or eviction strategies. This fills the cache with attacker-controlled data, leading to memory exhaustion and potential cache poisoning if malicious data is served later.
• Impact: Denial of Service (DoS), application performance degradation, resource starvation, potential cache poisoning.
• Risk Severity: High
• Mitigation Strategies:
  • Configure Resource Limits for Bulkhead: Always set appropriate MaxParallelization and MaxQueuingActions limits for Bulkhead policies based on application capacity and resource constraints.
  • Implement Cache Size Limits and Eviction: For Cache policies, configure maximum cache sizes and appropriate eviction strategies (e.g., LRU, FIFO) to prevent unbounded cache growth and memory exhaustion.
  • Rate Limiting in Conjunction with Bulkhead/Cache: Use rate limiting mechanisms before requests reach Polly policies to control the overall request rate and prevent abuse that could overwhelm Bulkhead or Cache.
  • Monitoring Resource Usage: Monitor resource consumption (threads, memory, cache size) related to Bulkhead and Cache policies to detect and respond to potential resource exhaustion attacks.

Attack Surface: Serialization/Deserialization Issues in Polly Caching or Fallback (If Implemented)

• Description: Critical vulnerability if Polly policies (especially Cache or custom Fallback policies) involve serialization and deserialization of data using insecure methods. This can lead to Remote Code Execution if malicious serialized data is processed.
• Polly Contribution: While Polly itself doesn't enforce specific serialization methods, if developers choose to implement caching or fallback logic within Polly policies that involves serialization/deserialization, they can introduce this critical attack surface.
• Example (Cache): A custom Polly Cache provider uses a vulnerable serialization library (e.g., insecurely configured BinaryFormatter in .NET). An attacker crafts malicious serialized data that, when retrieved from the cache and deserialized by the application through Polly, results in remote code execution.
• Example (Fallback): A custom Fallback policy handler deserializes data from an external source (e.g., a message queue) using an insecure deserialization method. An attacker can inject malicious serialized data into the queue, which is then processed by the Fallback policy, leading to RCE.
• Impact: Remote Code Execution (RCE), complete system compromise, data breaches, Denial of Service.
• Risk Severity: Critical
• Mitigation Strategies:
  • Avoid Deserializing Untrusted Data: Absolutely minimize or eliminate deserialization of data from untrusted sources within Polly policies. If unavoidable, treat deserialized data with extreme caution.
  • Use Secure Serialization Methods: If serialization is necessary, use secure and modern serialization libraries that are less prone to deserialization vulnerabilities (e.g., JSON.NET with safe settings, Protobuf). Avoid vulnerable serializers like BinaryFormatter in .NET.
  • Input Validation and Sanitization (Post-Deserialization): After deserialization (if unavoidable), rigorously validate and sanitize the deserialized data before using it within the application to prevent further exploitation.
  • Principle of Least Privilege for Deserialization: If deserialization is required, perform it in the least privileged context possible to limit the impact of potential vulnerabilities.