Skip to content

Latest commit

 

History

History
70 lines (59 loc) · 6.01 KB

threat-modeling.md

File metadata and controls

70 lines (59 loc) · 6.01 KB

Threat Model Analysis for facebook/litho

Threat: Excessive Component Re-layouts (DoS)

  • Description: An attacker provides crafted input that causes rapid and continuous updates to the data driving Litho components. The attacker exploits a poorly implemented shouldComponentUpdate method, or a component that reacts excessively to minor data changes, or triggers deeply nested updates.
    • Impact: The application's UI freezes (becomes unresponsive), leading to a poor user experience. In severe cases, the application may crash due to an ANR (Application Not Responding) error.
    • Affected Litho Component: Component (specifically, the lifecycle methods like shouldComponentUpdate, onUpdateState, and the overall component tree structure), Sections (if data changes affect large lists).
    • Risk Severity: High
    • Mitigation Strategies:
      • Developer: Implement efficient shouldComponentUpdate logic in all components. Use arePropsEqual and areStateEqual.
      • Developer: Profile the application using Litho's profiling tools (Systrace, Litho Profiler).
      • Developer: Debounce or throttle user input that triggers UI updates.
      • Developer: Avoid deeply nested component hierarchies.
      • Developer: Use useCached to memoize expensive calculations.
      • Developer: Sanitize and validate all input data.
      • Developer: Use the Sections API's diffing capabilities effectively.

Threat: Memory Exhaustion via Component Inflation (DoS)

  • Description: An attacker manipulates data to force Litho to create an extremely large number of components, exceeding available memory. The attacker might exploit a vulnerability in how the application handles list data or pagination.
    • Impact: The application crashes due to an OutOfMemoryError.
    • Affected Litho Component: Sections (particularly when handling large or unbounded lists), ComponentTree.
    • Risk Severity: High
    • Mitigation Strategies:
      • Developer: Implement robust pagination for all lists.
      • Developer: Set reasonable limits on the maximum number of items displayed.
      • Developer: Carefully manage the lifecycle of components within lists, ensuring proper recycling.
      • Developer: Monitor memory usage and set alerts.
      • Developer: Validate the size and structure of data received from external sources.

Threat: Sensitive Data Exposure in Component Props (Information Disclosure)

  • Description: An attacker uses debugging tools to inspect the view hierarchy or application memory, finding sensitive data that was passed as props to Litho components.
    • Impact: Leakage of sensitive user data or application secrets.
    • Affected Litho Component: Component (specifically, the props), LayoutSpec.
    • Risk Severity: Critical
    • Mitigation Strategies:
      • Developer: Never pass sensitive data directly as props.
      • Developer: Store sensitive data securely (Android Keystore, encrypted SharedPreferences).
      • Developer: Pass only identifiers or keys to components.
      • Developer: Use @Prop(resType = ResType.PRIVATE) as an additional layer of protection (but do not rely on it as the sole security measure).
      • Developer: Implement data redaction techniques.

Threat: Unintentional Logging of Sensitive Data (Information Disclosure)

  • Description: An attacker gains access to application logs and finds sensitive data that was inadvertently logged by Litho's internal logging or by custom logging statements within components.
    • Impact: Leakage of sensitive user data or application secrets.
    • Affected Litho Component: Component (any component with logging statements), Litho's internal logging (controlled by ComponentsConfiguration).
    • Risk Severity: High
    • Mitigation Strategies:
      • Developer: Review all logging statements and ensure they do not include sensitive data.
      • Developer: Use a logging library that supports redaction or filtering.
      • Developer: Configure Litho's internal logging appropriately. Disable or reduce verbosity in production. Use ComponentsConfiguration.IS_INTERNAL_BUILD.
      • Developer: Implement a secure logging strategy.

Threat: Injection of Malicious Components (Tampering/Elevation of Privilege)

  • Description: The application dynamically loads Litho components based on external input. An attacker provides a malicious component that executes arbitrary code or compromises the UI.
    • Impact: The attacker gains complete control over the application's UI, potentially leading to arbitrary code execution, data theft, or other malicious actions.
    • Affected Litho Component: Any mechanism used for dynamic component loading (e.g., a custom ComponentTree builder).
    • Risk Severity: Critical
    • Mitigation Strategies:
      • Developer: Strongly avoid dynamically loading Litho components from untrusted sources.
      • Developer: If dynamic component loading is absolutely necessary, implement extremely strict validation and sandboxing:
        • Code Signing: Verify the digital signature.
        • Input Validation: Thoroughly validate the structure and content.
        • Sandboxing: Run components in a restricted environment.
        • Capability Restrictions: Define a security policy that limits capabilities.
        • Regular Audits: Conduct regular security audits.