Skip to content

Latest commit

 

History

History
116 lines (91 loc) · 8.65 KB

mitigations.md

File metadata and controls

116 lines (91 loc) · 8.65 KB

Mitigation Strategies Analysis for facebook/litho

Mitigation Strategy: Server-Side State Validation (for Litho-Driven UI)

Description:

  1. Identify Litho State Triggers: Identify all user interactions within Litho components that should trigger a state change with security implications. This goes beyond simple UI updates; focus on actions that affect permissions, data access, or business logic.
  2. API-Driven State Updates: Instead of directly updating the Litho component's state on the client, send a request to a dedicated server-side API endpoint. This request should describe the intended state change.
  3. Server-Side Validation and Authorization: The API endpoint should:
    • Authenticate the user.
    • Authorize the user to perform the requested action (based on roles, permissions, and the current server-side application state).
    • Fetch the authoritative data (not relying on the client's potentially manipulated state).
    • Validate the intended state change against the authoritative data and user permissions.
    • Apply the state change only if valid and authorized.
  4. Server-Driven UI Updates: The server's response should include the new, validated state. The Litho component should update its UI exclusively based on this server-provided state, using Litho's @State and @Prop mechanisms to re-render as needed. Never directly update the UI based on client-side input without server validation.

Threats Mitigated:

  • Component State Manipulation (Client-Side): (Severity: High) Prevents attackers from directly manipulating the Litho component's state to bypass security checks or trigger unauthorized actions.
  • Unintended Component Rendering (Client-Side): (Severity: Medium) Reduces the risk by ensuring that state changes that lead to component rendering are validated on the server.

Impact:

  • Component State Manipulation: Risk significantly reduced (approaching elimination with comprehensive implementation).
  • Unintended Component Rendering: Risk moderately reduced; complements component-level authorization.

Currently Implemented:

  • /api/user/profile: Implemented for profile updates. Server validates changes.
  • /api/data/fetch: Implemented for sensitive data. Server verifies authorization.

Missing Implementation:

  • /api/component/visibility: Missing. No server-side validation for component visibility.
  • /api/actions/submit: Partially implemented. Some actions lack server-side validation.

Mitigation Strategy: Minimal State Exposure (within Litho Components)

Description:

  1. Audit Litho State: Carefully review all @State variables within your Litho components.
  2. Identify Sensitive Data: Identify any sensitive data stored in these @State variables (e.g., user details, tokens, internal application state).
  3. Refactor for Server-Side Storage: For each piece of sensitive data:
    • Prefer Server-Side: Store the data exclusively on the server whenever possible.
    • Fetch On Demand: Use Litho's @Prop to pass data into the component only when needed for rendering. Fetch this data from the server using a secure API call.
    • Short-Lived State: If temporary client-side storage is unavoidable, use @State but ensure the data is:
      • Minimal: Store only the absolute minimum required data.
      • Cleared: Use Litho's lifecycle methods (e.g., onComponentWillUnmount) to explicitly clear the @State variable when the component is no longer in use.
    • Avoid Derived State: Do not derive sensitive state from other state variables within the component. Fetch all sensitive data directly from the server.

Threats Mitigated:

  • Component State Manipulation (Client-Side): (Severity: High) Reduces the impact of successful state manipulation by minimizing the sensitive data available.
  • Data Exposure through Layout Specs: (Severity: Medium) Indirectly mitigates this by reducing the chance of sensitive data being present in the component's state.

Impact:

  • Component State Manipulation: Risk significantly reduced.
  • Data Exposure through Layout Specs: Risk moderately reduced.

Currently Implemented:

  • Authentication tokens are in HTTP-only cookies, not Litho state.
  • Sensitive user data is fetched from the server, not stored in @State.

Missing Implementation:

  • Some less-sensitive user data (name, email) is in @State for convenience. Needs review.
  • Error messages sometimes contain sensitive information.

Mitigation Strategy: Data Binding, Not Hardcoding (in Litho Layout Specs)

Description:

  1. Review Layout Code: Examine all Litho component code that defines layouts (typically within onCreateLayout).
  2. Identify Hardcoded Values: Look for any hardcoded strings, numbers, or other values directly within the layout definition (e.g., within Text.create(), Image.create(), etc.).
  3. Use @Prop for Dynamic Data: Replace all hardcoded values with @Prop variables. These props should be passed into the component from a parent component or fetched from a secure data source (ideally, the server).
  4. Avoid Literal Values in Layout: The goal is to have no literal sensitive values within the onCreateLayout method itself. All data should be dynamically provided through props.

Threats Mitigated:

  • Data Exposure through Layout Specs: (Severity: High) Prevents sensitive data from being directly embedded in the layout, which could be exposed through client-side inspection.

Impact:

  • Data Exposure through Layout Specs: Risk significantly reduced (near elimination with complete implementation).

Currently Implemented:

  • Most components use @Prop for dynamic content.
  • Data fetching uses HTTPS and authentication.

Missing Implementation:

  • Some static text labels (error messages, info components) have hardcoded values. Needs review.
  • Older components might have hardcoded data; a full audit is needed.

Mitigation Strategy: Component-Level Authorization (within Litho's Rendering)

Description:

  1. Define Component Permissions: Create a system for defining which users (or roles) are authorized to view specific Litho components.
  2. Associate Permissions: Associate these permissions with individual Litho components. This could be done via:
    • Annotations: Custom annotations on the component class.
    • Configuration: A separate configuration file mapping components to permissions.
    • Service: A dedicated authorization service.
  3. onCreateLayout Checks: Within each Litho component's onCreateLayout method:
    • Fetch User Context: Obtain the current user's context (ID, roles, permissions). This should ultimately come from a secure server-side source, even if it's initially passed down through props.
    • Authorization Check: Use the defined permissions and the user context to determine if the user is authorized to view this component.
    • Conditional Rendering:
      • Authorized: If authorized, proceed with the normal onCreateLayout logic, returning the component's layout.
      • Unauthorized: If not authorized, return:
        • null or an empty Component (to hide the component completely).
        • A Component that displays an "Unauthorized" message.
  4. Server-Side Enforcement: This is a client-side check for rendering, but it must be backed by server-side authorization for any data fetching or actions performed by the component.

Threats Mitigated:

  • Unintended Component Rendering (Client-Side): (Severity: High) Prevents unauthorized components from being rendered, even if an attacker manipulates state or routing.
  • Component State Manipulation (Client-Side): (Severity: Medium) Adds a layer of defense by preventing unauthorized rendering even with state manipulation.

Impact:

  • Unintended Component Rendering: Risk significantly reduced.
  • Component State Manipulation: Risk moderately reduced (secondary defense).

Currently Implemented:

  • Partially implemented. Some components have basic role-based checks, but it's inconsistent.

Missing Implementation:

  • A comprehensive, centralized authorization system is lacking.
  • Need more granular permissions beyond basic roles.
  • Need consistent checks in all components.