Skip to content

Latest commit

 

History

History
56 lines (43 loc) · 7.49 KB

threat-modeling.md

File metadata and controls

56 lines (43 loc) · 7.49 KB

Threat Model Analysis for jbogard/mediatr

Threat: Handler Bypass via Type Spoofing

  • Threat: Handler Bypass via Type Spoofing

    • Description: An attacker crafts a malicious request object that implements the IRequest<T> or INotification interface (or a custom interface used with MediatR) but is not the expected type for a registered handler. The attacker sends this crafted request. Because MediatR uses the interface for dispatch, it might route the request to an unintended handler, or a less secure handler that inadvertently accepts the malformed type, bypassing intended security checks. This exploits MediatR's dynamic dispatch mechanism.
    • Impact: Unauthorized execution of code, potential data breaches, bypassing security checks, or denial of service if the unintended handler is resource-intensive.
    • Affected Component: MediatR's Mediator class (specifically, the Send and Publish methods, which handle request dispatch), and potentially any IRequestHandler<TRequest, TResponse> or INotificationHandler<TNotification> implementations.
    • Risk Severity: High to Critical (depending on the application's security context).
    • Mitigation Strategies:
      • Strict Type Validation: Implement robust validation within the request/command objects themselves (using data annotations, FluentValidation, or custom validation logic) to ensure the object's properties conform to the expected schema before MediatR processes it. This validates the content and structure.
      • Input Validation in Handlers: Even with pre-MediatR validation, handlers should always validate the incoming request object as a first step. This acts as a second layer of defense. Never assume the request is valid.
      • Avoid Dynamic or object Types: Do not use dynamic or object as the request type in handlers. Always use strongly-typed requests.
      • Sealed Request Classes (Recommended): Consider making request/command classes sealed to prevent inheritance. This limits the possibility of unexpected subtypes being used.

Threat: Request Data Tampering within Pipeline

  • Threat: Request Data Tampering within Pipeline

    • Description: An attacker exploits a vulnerability in a custom IPipelineBehavior implementation. The malicious pipeline behavior modifies the request object after it has been dispatched by MediatR (using Mediator.Send or Mediator.Publish) but before it reaches the intended handler. This could involve changing sensitive data within the request, directly impacting the data MediatR passes to the handler.
    • Impact: Data corruption, unauthorized actions, bypassing security controls, potential elevation of privilege if the tampered data influences authorization decisions.
    • Affected Component: Custom IPipelineBehavior implementations. The Mediator itself facilitates the pipeline execution, making it indirectly involved.
    • Risk Severity: High
    • Mitigation Strategies:
      • Immutable Request Objects (Essential): Make request/command objects immutable (read-only after creation). This is the primary defense against this threat. Use record types in C# or other techniques to enforce immutability.
      • Pipeline Behavior Auditing: Thoroughly review and audit all custom IPipelineBehavior implementations. Look for any code that modifies the request object.
      • Principle of Least Privilege (Pipeline Behaviors): Ensure pipeline behaviors have only the necessary permissions. Avoid giving them broad access to system resources or sensitive data.
      • Unit and Integration Testing (Pipeline Behaviors): Write comprehensive unit and integration tests for all pipeline behaviors, specifically testing for unintended side effects and data modification.

Threat: Sensitive Data Exposure via Exceptions within MediatR Pipeline

  • Threat: Sensitive Data Exposure via Exceptions within MediatR Pipeline

    • Description: An exception is thrown within a handler (IRequestHandler or INotificationHandler) or a custom IPipelineBehavior during MediatR's processing. This exception contains sensitive data (e.g., database connection strings, API keys, user details) in its message or stack trace. If this exception is not handled properly within the MediatR pipeline, the sensitive data could be exposed.
    • Impact: Information disclosure, potential compromise of sensitive systems or data.
    • Affected Component: IRequestHandler<TRequest, TResponse>, INotificationHandler<TNotification>, and custom IPipelineBehavior implementations (where exceptions might be thrown or handled). The Mediator is involved as it orchestrates the execution.
    • Risk Severity: High to Critical (depending on the sensitivity of the exposed data).
    • Mitigation Strategies:
      • Global Exception Handling (Pipeline Behavior): Implement a custom IPipelineBehavior that acts as a global exception handler within the MediatR pipeline. This behavior should catch all exceptions originating from handlers or other behaviors, log them securely (without exposing sensitive data), and return a generic error message. This prevents the exception from propagating outside of MediatR's control.
      • Custom Exception Types: Define custom exception types for different error scenarios. Avoid including sensitive data in the default exception message. Control what information is exposed in each exception type.
      • Secure Logging Practices: Configure logging to avoid capturing sensitive data. Use redaction or masking techniques if necessary.

Threat: Unauthorized Handler Execution (through MediatR)

  • Threat: Unauthorized Handler Execution (through MediatR)
*   **Description:** An attacker sends a request that, *through MediatR's dispatch mechanism*, is routed to a handler that they should not have access to, based on their authorization level. This bypasses intended security controls because MediatR is the component performing the routing.
*   **Impact:** Elevation of privilege, unauthorized access to data or functionality.
*   **Affected Component:** `IRequestHandler<TRequest, TResponse>` (the handler itself), `Mediator` (as the dispatcher), and potentially `IPipelineBehavior` if authorization is implemented there (but this is less recommended).
*   **Risk Severity:** High to Critical
*   **Mitigation Strategies:**
    *   **Authorization within Handlers (Strongly Recommended):** Perform authorization checks *within* each handler, *before* executing any sensitive operations. Use the application's existing authorization mechanisms (e.g., claims-based authorization, role-based access control). This ensures that even if MediatR routes the request, the handler itself enforces authorization.
    *   **Authorization Pipeline Behavior (Less Preferred):** If using a pipeline behavior for authorization, ensure it's placed *before* any other behaviors that might perform sensitive operations and is thoroughly tested. Handler-level authorization is generally more secure and easier to reason about.
    *   **Principle of Least Privilege (Handlers):** Ensure handlers have only the necessary permissions to perform their tasks.