Skip to content

Latest commit

 

History

History
70 lines (51 loc) · 5.7 KB

File metadata and controls

70 lines (51 loc) · 5.7 KB

Mitigation Strategies Analysis for touchlab/kermit

Description:

  1. Wrapper Functions for Kermit: Create Kotlin wrapper functions around Kermit's logging methods (e.g., safeLogI(tag: String, message: () -> String), safeLogE(tag: String, throwable: Throwable, message: () -> String)). These are the only allowed way to interact with Kermit.
  2. Sanitization within Wrappers: Inside each wrapper function, call a centralized sanitization function (e.g., sanitizeLogMessage(message: String): String) to remove or mask sensitive data before passing the message to the underlying Kermit logging function.
  3. Custom LogWriter (Defense in Depth): Implement a custom LogWriter and configure Kermit to use it. Within this LogWriter, again call the sanitizeLogMessage function on the received log message. This acts as a final safety net, catching any cases where the wrapper functions were bypassed.
  4. Throwable Handling: Within the safeLogE wrapper (and the custom LogWriter), specifically sanitize the exception message and consider limiting the stack trace length before logging.
  5. Enforcement: Enforce through code reviews and potentially static analysis that only the wrapper functions are used for logging. Direct calls to Kermit's API should be prohibited.
  • Threats Mitigated:

    • Sensitive Data Exposure in Logs (Severity: High): Prevents sensitive data from being written to logs by sanitizing all messages passed to Kermit.
    • Log Injection (Severity: Medium): Sanitization reduces the risk of injected content, although Kermit's string template usage already offers some protection.
  • Impact:

    • Sensitive Data Exposure: Risk is significantly reduced (near-eliminated with correct implementation). The wrappers and custom LogWriter provide multiple layers of sanitization.
    • Log Injection: Risk is reduced, but other strategies (outside the scope of Kermit) are more important for this threat.
  • Currently Implemented:

    • Example: "Wrapper functions (safeLogI, safeLogE, etc.) are in logging/SafeLogger.kt. A custom LogWriter is in logging/SanitizingLogWriter.kt."
  • Missing Implementation:

    • Example: "The custom LogWriter (SanitizingLogWriter.kt) needs to be updated to include the full sanitization logic. Code reviews are not consistently enforcing the use of the wrapper functions."

Description:

  1. Explicit LogWriter: Always explicitly configure Kermit to use a custom LogWriter in your application's initialization code. Do not rely on Kermit's default LogWriter for the target platform without thorough review.
  2. Custom LogWriter Functionality: The custom LogWriter should:
    • Implement sanitization (as described above).
    • Implement rate limiting (see below).
    • Potentially implement escaping for log analysis tools (though this is less directly related to Kermit).
  3. Configuration Validation: If any part of Kermit's configuration (including the LogWriter choice) is loaded from an external source, validate this configuration before initializing Kermit. This prevents malicious or unexpected settings.
  • Threats Mitigated:

    • Misconfiguration of Kermit (Severity: Low to Medium): Prevents vulnerabilities or unexpected behavior due to incorrect Kermit settings.
    • Sensitive Data Exposure (Severity: High): The custom LogWriter provides a crucial layer of sanitization.
    • Denial of Service (DoS) (Severity: Medium): The custom LogWriter can implement rate limiting.
  • Impact:

    • Misconfiguration: Reduces the risk of misconfiguration.
    • Sensitive Data Exposure: Significantly reduces risk through sanitization.
    • Denial of Service: Reduces risk through rate limiting.
  • Currently Implemented:

    • Example: "The application explicitly configures a custom LogWriter (SanitizingLogWriter.kt) during initialization."
  • Missing Implementation:

    • Example: "Configuration validation is not currently implemented. The custom LogWriter does not yet implement rate limiting."

Description:

  1. Implement Rate Limiting: Within your custom LogWriter, implement a rate-limiting mechanism. This could use a token bucket algorithm, a sliding window, or another suitable approach.
  2. Configurable Thresholds: Define configurable thresholds for the rate limits (e.g., messages per second, per minute) for different log levels. Allow these thresholds to be adjusted without restarting the application (ideally).
  3. Integration with Kermit: This strategy is entirely implemented within the custom LogWriter that you provide to Kermit. Kermit itself doesn't have built-in rate limiting.
  • Threats Mitigated:

    • Denial of Service (DoS) via Excessive Logging (Severity: Medium): Prevents attackers or bugs from flooding the logging system.
  • Impact:

    • Denial of Service: Significantly reduces the risk of DoS attacks targeting the logging system.
  • Currently Implemented:

    • Example: "Not yet implemented."
  • Missing Implementation:

    • Example: "Rate limiting needs to be implemented within the custom LogWriter (SanitizingLogWriter.kt)."