mitigations.md

Mitigation Strategies Analysis for square/workflow-kotlin

Mitigation Strategy: Principle of Least Privilege for State (Workflow-Kotlin Focused)

• Description:

  1. Minimize State Scope: Create separate data classes for the State of each Workflow and sub-Workflow. Avoid a single, large state object. Each State class should only contain data absolutely necessary for that specific workflow.
  2. Visibility Modifiers within Workflow: Use Kotlin's visibility modifiers (private, internal, protected) within your Workflow and State classes. Restrict access to state properties. Only expose what is absolutely necessary. Avoid public for state properties unless strictly required for rendering (and even then, prefer a separate RenderingT).
  3. Careful RenderingT Design: Review all RenderingT types. If a RenderingT directly includes sensitive state, create a separate DTO (Data Transfer Object). This DTO should contain only the data needed for display, transforming the internal State into a safe-to-expose representation.
  4. Controlled Event Propagation: Define custom, strongly-typed event classes (e.g., data class UserLoggedIn(val userId: String)). Avoid generic event types. In the Workflow's onAction, only emit events that are necessary. Be explicit about which workflows subscribe to which events using the Workflow APIs.

• Threats Mitigated:

  • Unintentional State Exposure / Leaks (Severity: High): Reduces exposure through renderings, events, or direct access to the Workflow's state.
  • Workflow Composition Vulnerabilities (Severity: Medium): Limits state accessible to child Workflows, reducing unintended interactions.

• Impact:

  • Unintentional State Exposure / Leaks: Significant reduction.
  • Workflow Composition Vulnerabilities: Moderate reduction.

• Currently Implemented:

  • Visibility modifiers used in WorkflowA and WorkflowB state.
  • Separate DTOs for rendering in WorkflowC.
  • Strongly-typed events for user authentication.

• Missing Implementation:

  • WorkflowD uses a large state object. Needs refactoring.
  • WorkflowE exposes sensitive state in RenderingT. Needs a DTO.
  • Generic events used between WorkflowF and WorkflowG.

Mitigation Strategy: Isolate Side Effects with Workers

• Description:

  1. Identify Side Effects: List all external interactions (databases, APIs, etc.).
  2. Create Workers: For each distinct side effect, create a separate Worker implementation. The Worker should encapsulate only that specific side effect.
  3. Worker Input Validation: Treat the input to the Worker as untrusted. Implement rigorous input validation within the Worker's run method to ensure the input conforms to expected types, ranges, and formats. Use Kotlin's type system.
  4. Rate Limiting/Circuit Breakers (Using Workers): While the implementation of rate limiting and circuit breakers might be external, the decision to apply them and the integration point is within the Workflow that uses the Worker. You would use the Worker API to handle the results of these patterns (e.g., checking for a Worker result indicating a rate limit was hit).

• Threats Mitigated:

  • Side Effect Mismanagement / Injection (Severity: High): Isolates side effects, making them easier to audit and control.
  • Denial of Service (DoS) via Workflow Overload (Severity: Medium): Rate limiting and circuit breakers, integrated through the Worker API, help.

• Impact:

  • Side Effect Mismanagement / Injection: Significant reduction.
  • Denial of Service (DoS): Moderate reduction.

• Currently Implemented:

  • Database interactions in DatabaseWorker.
  • API calls to ServiceX in ServiceXWorker.
  • Input validation in ServiceXWorker.

• Missing Implementation:

  • FileAccessWorker lacks input validation.
  • Rate limiting/circuit breakers not integrated for ServiceXWorker or ServiceYWorker.

Mitigation Strategy: Well-Defined Workflow Contracts (Using Workflow APIs)

• Description:

  1. Define Inputs/Outputs/Events: For each Workflow, especially child workflows, clearly define:
     • Inputs: Strongly-typed data classes for data received from the parent.
     • Outputs: Strongly-typed data classes for data returned to the parent.
     • Events: Strongly-typed event classes the child Workflow might emit.
  2. Limit Parent Access: Avoid giving child Workflows direct access to the parent Workflow's state. Pass data explicitly through inputs and outputs.
  3. Review compose Method: In the parent Workflow's compose method, carefully review:
     • How child Workflows are instantiated and configured.
     • How inputs are passed to child Workflows.
     • How outputs from child Workflows are handled.
     • How events from child Workflows are handled. Use the Workflow's event handling mechanisms to manage subscriptions.

• Threats Mitigated:

  • Workflow Composition Vulnerabilities (Severity: Medium): Reduces unintended interactions between parent and child Workflows.
  • Unintentional State Exposure / Leaks (Severity: Medium): Limits access to parent's state.

• Impact:

  • Workflow Composition Vulnerabilities: Moderate reduction.
  • Unintentional State Exposure / Leaks: Moderate reduction.

• Currently Implemented:

  • WorkflowH and WorkflowI have defined input/output classes.

• Missing Implementation:

  • WorkflowK lacks definitions, interacts with parent's state. Needs refactoring.
  • WorkflowL's compose method needs review.

Mitigation Strategy: Workflow Timeouts (Using withTimeout in Workflow)

• Description:

  1. Identify Long-Running Workflows: Analyze workflows for potential long-running operations.
  2. Implement Timeouts: Use Kotlin coroutines' withTimeout or withTimeoutOrNull functions within the Workflow's compose or onAction methods, especially when launching child workflows or Workers. This ensures that the timeout is managed within the workflow-kotlin context.

• Threats Mitigated:

  • Denial of Service (DoS) via Workflow Overload (Severity: Medium): Prevents workflows from running indefinitely.

• Impact:

  • Denial of Service (DoS): Significant reduction.

• Currently Implemented:

  • Timeouts for long-running workflows using withTimeout.

• Missing Implementation:

  • Needs more comprehensive application across all potentially long-running workflows and workers.

Mitigation Strategy: Idempotency within Workflows

• Description:

  1. Analyze Workflow Actions: Examine each Workflow's onAction method and any Worker interactions. Identify operations that modify external state (databases, APIs, etc.).
  2. Design for Idempotency:
     • Conditional Updates: Before performing an update, check if the update has already been applied. For example, if inserting a record into a database, check if a record with the same unique identifier already exists.
     • Unique Request IDs: If interacting with external APIs, include a unique request ID in each request. The API can then use this ID to detect and prevent duplicate processing.
     • Use Worker Results: Leverage the Worker API to check for successful completion of previous operations before retrying.
  3. Test for Idempotency: Write specific tests that repeatedly execute the same Workflow actions with the same inputs to verify that the outcome is consistent.

• Threats Mitigated:

  • Replay Attacks / State Corruption (Severity: Medium): Reduces the impact of replaying a workflow or restoring a previous state.

• Impact:

  • Replay Attacks / State Corruption: Moderately reduces the risk and impact.

• Currently Implemented:

  • Partial idempotency implemented in WorkflowM for database updates.

• Missing Implementation:

  • Needs a comprehensive review and implementation across all workflows that modify external state, particularly WorkflowN and interactions with ServiceZWorker.