Skip to content

Latest commit

 

History

History
65 lines (56 loc) · 4.64 KB

File metadata and controls

65 lines (56 loc) · 4.64 KB

Threat Model Analysis for app-vnext/polly

  • Description: A system flaw (not necessarily an attacker) causes a non-idempotent operation (e.g., "create user," "process payment") to fail after its side effect occurs but before a success response. Polly's RetryPolicy, if misapplied, retries the operation, leading to duplicates.
    • Impact:
      • Duplicate data (multiple user accounts, orders).
      • Financial loss (double-charging).
      • Data inconsistency and corruption.
      • Violation of business rules.
    • Affected Component: RetryPolicy, RetryTResultPolicy
    • Risk Severity: High (significant data and financial risks)
    • Mitigation Strategies:
      • Idempotency Keys: Implement server-side idempotency keys.
      • Check Before Retry: (Complex) Attempt to determine if the previous operation succeeded before retrying.
      • Transactional Operations: (If possible) Wrap the operation and retry in a transaction.
      • Avoid Retries: Do not use RetryPolicy for inherently non-idempotent operations. Use FallbackPolicy.
      • CQRS: Separate commands (state changes) from queries (reads). Retries are safer on queries.
  • Description: An attacker, or a system fault, triggers repeated failures. An overly aggressive RetryPolicy (too many retries, short intervals) amplifies this, causing a denial-of-service (DoS) attack against the downstream service (potentially self-inflicted).
    • Impact:
      • Downstream service unavailability.
      • Cascading failures.
      • Application unresponsiveness.
      • Resource exhaustion.
    • Affected Component: RetryPolicy, WaitAndRetryPolicy, RetryTResultPolicy, WaitAndRetryTResultPolicy
    • Risk Severity: High (can lead to service outages)
    • Mitigation Strategies:
      • Exponential Backoff with Jitter: Use WaitAndRetryPolicy with increasing delays and random jitter.
      • Circuit Breaker: Use a CircuitBreakerPolicy before the RetryPolicy.
      • Rate Limiting: Implement client-side rate limiting in addition to Polly.
      • Reasonable Timeouts: Set appropriate timeouts.
      • Monitoring: Monitor retry counts, durations, and downstream service health.
  • Description: If all resilience strategies fail (retries, circuit breaker), and there's no FallbackPolicy, or the fallback itself fails (throws an exception, returns bad data), the application may crash or provide a very poor user experience. An attacker might trigger failures to expose this.
    • Impact:
      • Application crashes.
      • Unhandled exceptions exposed to the user.
      • Incorrect or stale data returned.
      • Poor user experience.
    • Affected Component: FallbackPolicy, FallbackAsyncPolicy
    • Risk Severity: High (can lead to application crashes and data issues)
    • Mitigation Strategies:
      • Always Use Fallback: Always configure a FallbackPolicy.
      • Robust Fallback Action: Ensure the fallback is simple, reliable, and fast; it should not throw exceptions.
      • Return Sensible Defaults: Return a default value, cached response (if appropriate), or a user-friendly error.
      • Log Fallback Execution: Log whenever the fallback is used.
      • Test Fallback Thoroughly: Test the fallback under failure conditions.
  • Description: A vulnerability is discovered in Polly itself or one of its dependencies. An attacker exploits this to compromise the application.
    • Impact:
      • Varies widely; could range from information disclosure to remote code execution (RCE).
    • Affected Component: The entire Polly library, or a specific dependency.
    • Risk Severity: Variable (depends on the vulnerability; could be Critical)
    • Mitigation Strategies:
      • Dependency Scanning: Use a software composition analysis (SCA) tool (e.g., OWASP Dependency-Check, Snyk).
      • Keep Polly Updated: Regularly update to the latest version of Polly.
      • Monitor Security Advisories: Monitor Polly's GitHub and security channels.