Skip to content

Latest commit

 

History

History
97 lines (75 loc) · 9.25 KB

mitigations.md

File metadata and controls

97 lines (75 loc) · 9.25 KB

Mitigation Strategies Analysis for jetbrains/compose-jb

Mitigation Strategy: Platform-Specific Code Isolation with expect/actual

Mitigation Strategy: Platform-Specific Code Isolation using expect/actual.

Description:

  1. Identify Compose-Related Platform Differences: Analyze your Compose code for any areas where behavior or required APIs differ between Desktop and Web (or other future targets). This includes:
    • Window Management: Desktop applications have windows, while web applications run within a browser tab. Window size, position, and state management are handled differently.
    • Input Handling: Mouse, keyboard, and touch events may have subtle differences across platforms.
    • Rendering: While Compose abstracts much of the rendering, there might be platform-specific rendering quirks or limitations.
    • Resource Loading: Loading images, fonts, or other resources might require platform-specific approaches.
    • Clipboard Access: Accessing the system clipboard is platform-specific.
    • File System Access: As previously mentioned, file system access is handled very differently.
  2. Create expect Declarations: In the common code, define expect declarations for any Compose-related functions or classes that need platform-specific implementations.
  3. Implement actual Declarations: In each platform-specific module (desktopMain, webMain), provide actual implementations that use the appropriate Compose APIs and platform-specific logic.
  4. Use Common Code: The rest of your Compose UI code interacts with these platform-specific features only through the expect declarations.

Threats Mitigated:

  • Cross-Platform Compatibility Exploits (Medium Severity): Prevents vulnerabilities that might arise from using platform-specific Compose APIs incorrectly on a different platform. For example, attempting to directly manipulate a window handle in web code would be prevented.
  • Inconsistent UI Behavior (Low Severity): Ensures that the UI behaves consistently across platforms, reducing the risk of unexpected behavior that could be exploited.
  • Resource Loading Issues (Low Severity): Prevents issues with loading resources that might be handled differently on different platforms.

Impact:

  • Cross-Platform Compatibility Exploits: Risk reduced moderately (60-70%). The expect/actual mechanism forces developers to consider platform-specific differences.
  • Inconsistent UI Behavior: Risk reduced significantly (70-80%).
  • Resource Loading Issues: Risk reduced significantly (80-90%).

Currently Implemented:

  • Example: src/commonMain/kotlin/ClipboardUtils.kt (contains expect declarations for clipboard access).
  • Example: src/desktopMain/kotlin/ClipboardUtils.kt (contains actual implementation using AWT).
  • Example: src/jsMain/kotlin/ClipboardUtils.kt (contains actual implementation using the browser Clipboard API).

Missing Implementation:

  • Example: Window management (resizing, minimizing, etc.) is currently handled directly in the common code using desktop-specific APIs. This needs to be refactored to use expect/actual.
  • Example: Image loading is done using a common library, but it might have platform-specific performance or security implications that need to be addressed with expect/actual.

Mitigation Strategy: Secure State Management with remember and rememberSaveable

Mitigation Strategy: Understand and correctly use remember and rememberSaveable. Implement custom Saver for sensitive data. Clear sensitive state.

Description:

  1. remember vs. rememberSaveable: Use remember for in-memory state that should be cleared on recomposition or configuration changes. Use rememberSaveable only when state must persist across configuration changes or process death (e.g., user input in a form that should be preserved if the screen rotates).
  2. Avoid Sensitive Data in rememberSaveable: Do not store sensitive data (passwords, API keys, personal information) directly in rememberSaveable without additional protection.
  3. Custom Saver: If you must use rememberSaveable with sensitive data, implement a custom Saver that encrypts the data before saving and decrypts it when restoring. Use platform-appropriate secure storage for the encryption keys (e.g., Keychain on macOS, Credential Manager on Windows, or a secure server-side solution for web).
  4. Clear Sensitive State: In onDispose blocks of Composables or within a ViewModel's onCleared method, explicitly clear sensitive state (e.g., set variables to null or empty strings). This is crucial to prevent data leaks.
  5. Consider Snapshot State: For more complex state management, consider using mutableStateOf or mutableStateListOf within a ViewModel. This provides better control over state updates and allows for easier integration with unidirectional data flow patterns.

Threats Mitigated:

  • Information Leakage (Medium Severity): Prevents sensitive data from being unintentionally persisted or exposed across configuration changes, application restarts, or even in memory dumps.
  • Data Tampering (Low Severity): Makes it more difficult for an attacker to modify persisted state if a custom Saver with encryption is used.

Impact:

  • Information Leakage: Risk reduced significantly (70-80%) with proper use of remember, rememberSaveable, custom Saver and clearing of sensitive state.
  • Data Tampering: Risk reduced moderately (50-60%) with a custom Saver and encryption.

Currently Implemented:

  • Example: remember is used extensively for UI state.
  • Example: rememberSaveable is used in a few places to preserve form input.
  • Example: No custom Saver is implemented.

Missing Implementation:

  • Example: Need to audit all uses of rememberSaveable and determine if they are truly necessary and if they involve sensitive data.
  • Example: Implement a custom Saver with encryption for any rememberSaveable usage that involves sensitive data.
  • Example: Add onDispose blocks to Composables and onCleared to ViewModels to clear sensitive state variables.

Mitigation Strategy: Careful Management of Side Effects and Composition Lifecycle

Mitigation Strategy: Understand and carefully manage side effects and the Compose composition lifecycle.

Description:

  1. LaunchedEffect: Use LaunchedEffect to perform side effects (e.g., network requests, database operations) that should be tied to the lifecycle of a Composable. Ensure that any cleanup (e.g., canceling network requests, closing database connections) is performed in the onDispose block of the LaunchedEffect.
  2. DisposableEffect: Use DisposableEffect for side effects that require more fine-grained control over their lifecycle, especially when dealing with resources that need to be acquired and released.
  3. Avoid Side Effects in Composition: Do not perform side effects directly within the body of a Composable function. This can lead to unpredictable behavior and make it difficult to reason about the application's state.
  4. Understand Recomposition: Be aware of how recomposition works in Compose. Avoid unnecessary recompositions, as they can impact performance and potentially trigger unintended side effects.
  5. Keying: Use appropriate keys with remember and LaunchedEffect to control when they are re-executed. Incorrect keying can lead to unexpected behavior and potential memory leaks.

Threats Mitigated:

  • Resource Leaks (Low Severity): Prevents memory leaks, file handle leaks, or other resource leaks caused by improperly managed side effects.
  • Unintended Behavior (Low Severity): Reduces the risk of unexpected behavior caused by side effects being triggered at the wrong time or multiple times.
  • Denial of Service (DoS) (Low - in specific cases): In extreme cases, uncontrolled side effects (e.g., repeatedly launching network requests) could lead to a denial-of-service condition.

Impact:

  • Resource Leaks: Risk reduced significantly (80-90%) with proper use of LaunchedEffect and DisposableEffect.
  • Unintended Behavior: Risk reduced significantly (70-80%) by avoiding side effects in composition and understanding recomposition.
  • DoS: Risk reduction is context-dependent, but generally helps prevent uncontrolled resource consumption.

Currently Implemented:

  • Example: LaunchedEffect is used in some places to fetch data from a network.
  • Example: No DisposableEffect is used.

Missing Implementation:

  • Example: Need to review all Composables and ensure that side effects are handled correctly using LaunchedEffect or DisposableEffect.
  • Example: Need to add cleanup logic (e.g., canceling network requests) to the onDispose blocks of LaunchedEffect.
  • Example: Need to investigate potential resource leaks and address them using DisposableEffect where appropriate.
  • Example: Need to review keying of remember and LaunchedEffect.