Skip to content

Latest commit

 

History

History
113 lines (88 loc) · 7.39 KB

mitigations.md

File metadata and controls

113 lines (88 loc) · 7.39 KB

Mitigation Strategies Analysis for jakewharton/timber

Mitigation Strategy: 1. Mitigation Strategy: Data Masking/Redaction (using a Custom Tree)

  • Description:

    1. Identify Sensitive Data: Create a comprehensive list of all sensitive data types that might be logged.
    2. Create a Custom Tree: Subclass Timber.Tree to create a custom logging tree. This is the core of this strategy, as it intercepts all log messages within Timber.
    3. Implement Redaction Logic: Inside the log() method of your custom Tree, implement the redaction logic:
      • Use regular expressions or a dedicated library to match sensitive data patterns.
      • Replace matched patterns with placeholders.
      • Thoroughly test the redaction logic.
    4. Plant the Custom Tree: Replace any default Timber.plant() calls with your custom Tree. Example: Timber.plant(new MyRedactingTree());
    5. Regularly Review and Update: Periodically review the list of sensitive data types and the redaction logic.

  • Threats Mitigated:

    • Sensitive Data Exposure (Severity: High): Prevents accidental logging of sensitive information.
    • Log Injection (Severity: Medium): Provides a secondary layer of defense by redacting potentially malicious payloads that match redaction patterns.

  • Impact:

    • Sensitive Data Exposure: Significantly reduces the risk.
    • Log Injection: Provides some mitigation, but input validation is the primary defense.

  • Currently Implemented:

    • Partially implemented in AuthService.java with basic password redaction before calling Timber.d(). This is not a Timber-centric solution.

  • Missing Implementation:

    • A centralized, custom Tree is missing. Redaction should be handled within Timber.
    • Redaction logic is incomplete.
    • No regular review process.

Mitigation Strategy: 2. Mitigation Strategy: Structured Logging (with a Custom Tree for Enforcement)

  • Description:

    1. Define Log Event Classes: Create specific classes to represent different types of log events.
    2. Define Allowed Fields: Within each event class, define only the fields that are permitted to be logged.
    3. Create a Custom Tree (Enforcement): Create a custom Tree that enforces the use of these event classes. This is the key Timber-related step.
      • In the log() method, check the type of the logged object.
      • Only allow specific classes or fields to be logged.
      • Reject or modify log messages that don't conform to the structured logging format.
    4. Modify Logging Calls: Replace free-form text logging calls with calls that use the defined event classes.
    5. Serialization Control (within the Custom Tree): Control how event objects are serialized to strings (e.g., using a JSON library) within the custom Tree. Ensure only allowed fields are included.

  • Threats Mitigated:

    • Sensitive Data Exposure (Severity: High): Strictly controls the data that can be logged.
    • Log Injection (Severity: Low): Makes it slightly harder to inject arbitrary data.

  • Impact:

    • Sensitive Data Exposure: High impact.
    • Log Injection: Minor impact.

  • Currently Implemented:

    • Not implemented.

  • Missing Implementation:

    • No defined log event classes.
    • No custom Tree to enforce structured logging within Timber.
    • All logging calls need refactoring.

Mitigation Strategy: 3. Mitigation Strategy: Dynamic Logging Level Control (using Timber's Planting)

  • Description:

    1. Choose a Configuration Mechanism: Decide how to control logging levels dynamically (e.g., config file, environment variables).
    2. Implement a Configuration Loader: Create a component to load the logging configuration.
    3. Integrate with Timber: Modify your Timber setup (in application initialization) to read the logging level from the configuration. This is the Timber-specific part:
      • You might need to unplant existing trees: Timber.uprootAll();
      • Then, re-plant your Tree (or trees) with the desired level: Timber.plant(new Timber.DebugTree()); or if (logLevel >= Log.INFO) { Timber.plant(new MyInfoTree()); }
    4. Implement Configuration Change Mechanism: Provide a way to safely modify the configuration.
    5. Consider a Watcher (Optional): For file-based configurations, consider a file watcher.

  • Threats Mitigated:

    • Excessive Logging/Storage (Severity: Medium): Allows reducing logging verbosity.
    • Sensitive Data Exposure (Severity: Medium): Reduces the risk by lowering the logging level in production.

  • Impact:

    • Excessive Logging/Storage: Medium impact.
    • Sensitive Data Exposure: Medium impact.

  • Currently Implemented:

    • Not implemented.

  • Missing Implementation:

    • No mechanism for dynamically changing logging levels. The entire implementation is missing. The key missing piece is the dynamic Timber.plant() and Timber.uprootAll() calls based on configuration.

Mitigation Strategy: 4. Mitigation Strategy: Custom Tree for Log Rotation (If Writing to Files Directly)

  • Description: This strategy is only relevant if you are using a custom Tree that writes directly to files, bypassing any platform-provided logging system.

    1. Choose a Rotation Strategy: Decide how to rotate log files (size, time, or both).
    2. Implement Rotation Logic (within the Custom Tree): This is entirely within the custom Tree's log() method:
      • Check the file size or date/time.
      • If rotation criteria are met:
        • Close the current file.
        • Create a new file (with a timestamped name).
        • Update the Tree to write to the new file.
    3. (Separate Task) Implement Deletion: Create a separate scheduled task (not part of Timber) to delete old log files. This is not a Timber-specific task.

  • Threats Mitigated:

    • Excessive Logging/Storage (Severity: Medium): Prevents log files from growing indefinitely.
    • Data Retention Issues (Severity: Medium): Facilitates compliance with data retention policies (though the deletion itself is a separate task).
    • Sensitive Data Exposure (Severity: Low): Reduces the window of opportunity for access to old data.

  • Impact:

    • Excessive Logging/Storage: High impact.
    • Data Retention Issues: High impact (for compliance).
    • Sensitive Data Exposure: Low impact.

  • Currently Implemented:

    • Basic log rotation is configured through the Android logging system (for Timber.DebugTree()), but this strategy is about custom trees.

  • Missing Implementation:

    • If any custom Tree writes directly to files, full rotation logic within that Tree is missing.
    • Automated, secure deletion (a separate task) is also missing.