Skip to content

Latest commit

 

History

History
49 lines (40 loc) · 5.99 KB

threat-modeling.md

File metadata and controls

49 lines (40 loc) · 5.99 KB

Threat Model Analysis for square/okhttp

Threat: Certificate Pinning Bypass

  • Description: An attacker crafts a malicious certificate or compromises a Certificate Authority (CA) trusted by the system. If certificate pinning is misconfigured or absent within OkHttp, the attacker can perform a Man-in-the-Middle (MitM) attack. The attacker presents their malicious certificate, and the OkHttp client accepts it because it's either not validating the pin correctly or not pinning at all, allowing interception and modification of HTTPS traffic.
    • Impact: Complete compromise of communication confidentiality and integrity. The attacker can read and modify all data exchanged, including credentials and sensitive information, leading to account takeover and data breaches.
    • Affected OkHttp Component: CertificatePinner class, specifically the check() method and the configuration of pins via CertificatePinner.Builder().
    • Risk Severity: Critical
    • Mitigation Strategies:
      • Implement Correct Pinning: Use CertificatePinner.Builder() to add pins for the specific leaf certificate or a tightly controlled intermediate CA. Do not pin to root CAs or widely-used intermediates.
      • Multiple Pins: Include backup pins for certificate rotation.
      • Regular Pin Updates: Establish a process for updating pins before certificates expire.
      • Fail Closed: Ensure that if pinning validation fails, the connection is immediately terminated. Do not fall back to the system's trust store.
      • Testing: Thoroughly test the pinning implementation, including failure scenarios.
      • Certificate Transparency: Monitor Certificate Transparency logs for unexpected certificate issuance.

Threat: Hostname Verification Bypass

  • Description: An attacker obtains a valid certificate for any domain. If hostname verification is disabled or incorrectly implemented within OkHttp, the attacker can perform a MitM attack. The client connects to the attacker's server, which presents a valid (but incorrect for the target domain) certificate. The OkHttp client accepts it because it's not verifying that the certificate's Common Name (CN) or Subject Alternative Name (SAN) matches the intended hostname.
    • Impact: Complete compromise of communication confidentiality and integrity, allowing the attacker to intercept and modify all traffic. This is equivalent to a successful MitM attack.
    • Affected OkHttp Component: OkHttpClient.Builder.hostnameVerifier() method. The default HostnameVerifier is secure; the risk is from disabling it or using a custom, flawed implementation.
    • Risk Severity: Critical
    • Mitigation Strategies:
      • Never Disable: Do not disable hostname verification in production using hostnameVerifier(NoopHostnameVerifier).
      • Use Default: Rely on the default HostnameVerifier provided by OkHttp.
      • Custom Verifier (Extreme Caution): If a custom HostnameVerifier is absolutely required, it must be rigorously reviewed and tested. It must correctly compare the hostname with the certificate's CN and SAN fields.

Threat: Unbounded Response Buffering (DoS/OOM)

  • Description: An attacker sends a very large response to the client. If OkHttp is used in a way that buffers the entire response in memory before processing it, this can lead to excessive memory consumption and an OutOfMemoryError (OOM), crashing the application. This is a direct result of how the OkHttp response body is handled.
    • Impact: Application crash, leading to denial of service.
    • Affected OkHttp Component: How the response body is handled. Specifically, using response.body().string() (which buffers the entire response) vs. response.body().byteStream() (which provides a stream).
    • Risk Severity: High
    • Mitigation Strategies:
      • Streaming Responses: Use response.body().byteStream() to process responses incrementally, especially for large responses. Read and process the data in chunks instead of loading the entire response into memory.
      • Response Size Limits: Implement checks on the Content-Length header (if available) and set a maximum acceptable response size within the OkHttp client code. If the response exceeds this limit, terminate the connection.
      • Memory Monitoring: Monitor application memory usage.

Threat: Sensitive Data in Logs (Due to OkHttp Interceptor Misconfiguration)

  • Description: If OkHttp's logging interceptors are configured to log at a verbose level (e.g., BODY), and an attacker gains access to application logs, the logs may contain sensitive information like request headers (including authentication tokens), request bodies, and response bodies. This is a direct consequence of OkHttp's logging configuration.
    • Impact: Exposure of sensitive data, potentially leading to account takeover, data breaches, and privacy violations.
    • Affected OkHttp Component: HttpLoggingInterceptor class and its configuration (logging level). Custom interceptors that log data are also relevant.
    • Risk Severity: High
    • Mitigation Strategies:
      • Minimal Logging: Use the least verbose logging level necessary for debugging in production (e.g., BASIC or HEADERS). Avoid BODY level logging in production.
      • Redaction: Implement custom logging interceptors or modify HttpLoggingInterceptor to redact sensitive information (e.g., replace authentication tokens with ***, remove sensitive headers) before logging.
      • Secure Logging Infrastructure: Use a secure logging system (this is a general mitigation, but the vulnerability is in OkHttp's configuration).