Skip to content

Latest commit

 

History

History
84 lines (65 loc) · 5.88 KB

mitigations.md

File metadata and controls

84 lines (65 loc) · 5.88 KB

Mitigation Strategies Analysis for airbnb/mavericks

Mitigation Strategy: Principle of Least Privilege for State (Mavericks-Specific)

Description:

  1. Component Analysis: For each component using a MavericksViewModel, determine the minimum set of state properties needed.
  2. selectSubscribe / select: Use Mavericks' selectSubscribe (for observing changes) or select (one-time read) to subscribe only to those specific properties. Do not use withState to access the entire state object unless absolutely necessary (and carefully justified). This leverages Mavericks' built-in selective subscription mechanism.
  3. Refactor withState: Actively refactor existing components using withState to use selectSubscribe or select for granular access. This is a direct application of Mavericks' intended usage pattern.

  • Threats Mitigated:

    • Unintentional State Exposure/Leakage (Severity: High): Directly prevents components from accessing data they don't need, leveraging Mavericks' core functionality.
    • Unauthorized State Modification (Severity: Medium): Indirectly mitigates by limiting the scope of potential damage, as components have a narrower view of the state.

  • Impact:

    • Unintentional State Exposure/Leakage: Significantly reduces risk by design.
    • Unauthorized State Modification: Moderate risk reduction.

  • Currently Implemented:

    • Example: UserProfileViewModel uses selectSubscribe(UserState::userName).
    • Location: app/src/main/java/com/example/app/viewmodels/UserProfileViewModel.kt

  • Missing Implementation:

    • DashboardViewModel uses withState. Refactor to use selectSubscribe.
    • Location: app/src/main/java/com/example/app/viewmodels/DashboardViewModel.kt
    • SettingsViewModel uses withState.
    • Location: app/src/main/java/com/example/app/viewmodels/SettingsViewModel.kt

Mitigation Strategy: Controlled State Updates (Mavericks-Specific)

Description:

  1. Encapsulated Updates: Instead of directly exposing Mavericks' setState or withState to external callers, create specific functions within the ViewModel that perform state updates. These functions act as controlled access points.
  2. internal/private Access: Make the setState and withState calls within the ViewModel internal or private. This is a key Mavericks-specific mitigation, preventing direct manipulation of these core functions from outside the ViewModel. This leverages Kotlin's visibility modifiers in conjunction with Mavericks' design.
  3. Validation within Encapsulated Functions: Perform validation and authorization before calling setState inside these controlled functions.

  • Threats Mitigated:

    • Unauthorized State Modification (Severity: High): The primary defense, directly controlling access to Mavericks' state modification mechanisms.
    • Unintentional State Exposure/Leakage (Severity: Low): Indirectly helps by promoting structured state management.

  • Impact:

    • Unauthorized State Modification: Significantly reduces risk.
    • Unintentional State Exposure/Leakage: Minor risk reduction.

  • Currently Implemented:

    • LoginViewModel has loginUser(username, password) which internally calls setState.
    • setState is often used directly from event handlers.

  • Missing Implementation:

    • Refactor most ViewModels to use encapsulated update functions.
    • Make setState/withState internal/private.
    • Add validation to update functions.
    • Review ProductDetailViewModel, CheckoutViewModel, SearchViewModel.
    • Locations:
      • app/src/main/java/com/example/app/viewmodels/ProductDetailViewModel.kt
      • app/src/main/java/com/example/app/viewmodels/CheckoutViewModel.kt
      • app/src/main/java/com/example/app/viewmodels/SearchViewModel.kt

Mitigation Strategy: Use Mavericks' Asynchronous Handling

Description:

  1. Identify Asynchronous Operations: Find all asynchronous operations in your ViewModels.
  2. async and awaitState: Use Mavericks' async to initiate asynchronous tasks and awaitState to safely access and update the state within the asynchronous block. This is crucial for correct state management with asynchronous code in Mavericks. This is the core Mavericks-specific aspect.
  3. Error Handling: Implement error handling within the async block, updating the state to reflect any failures.
  4. Avoid Manual Threading: Do not use manual threading; rely on Mavericks' provided mechanisms.

  • Threats Mitigated:

    • State Synchronization Issues (Severity: Medium): Prevents race conditions by using Mavericks' built-in asynchronous handling, which is designed for safe state updates.
    • Unauthorized State Modification (Severity: Low): Indirectly mitigates by ensuring controlled and predictable state updates, even asynchronously.

  • Impact:

    • State Synchronization Issues: Significantly reduces risk.
    • Unauthorized State Modification: Minor risk reduction.

  • Currently Implemented:

    • NetworkViewModel uses async and awaitState.
    • Inconsistent usage; some asynchronous operations use Coroutines directly.

  • Missing Implementation:

    • Refactor asynchronous operations to use async and awaitState consistently.
    • Ensure proper error handling.
    • Review ImageUploadViewModel and DataSyncViewModel.
    • Locations:
      • app/src/main/java/com/example/app/viewmodels/ImageUploadViewModel.kt
      • app/src/main/java/com/example/app/viewmodels/DataSyncViewModel.kt