attack-surface.md

Attack Surface Analysis for google/guava

Attack Surface: Hash Collision Denial of Service (DoS)

• Description: An attacker crafts input data specifically to cause hash collisions within Guava's hash-based collections, leading to significant performance degradation and potentially a Denial of Service. This exploits the algorithmic complexity of hash table lookups in collision scenarios.
• Guava Contribution: Guava provides core hash-based collections like HashMultimap, HashSet, and ImmutableMap (and indirectly HashMap). These collections rely on hashing algorithms, and if used with attacker-controlled keys, are susceptible to collision attacks. Guava's com.google.common.hash package also provides hash function implementations that, while generally robust, are the foundation for these collections.
• Example: An application uses Guava's HashMultimap to manage request routing based on client-provided identifiers. An attacker sends a flood of requests with identifiers carefully chosen to generate hash collisions within the HashMultimap. This causes the HashMultimap's internal hash table to degrade into long linked lists, drastically increasing lookup times for all requests and leading to a service-wide slowdown or crash due to CPU exhaustion.
• Impact: Denial of Service, application crash, significant performance degradation, resource exhaustion.
• Risk Severity: High to Critical (Critical if core application functionality is severely impacted and publicly accessible).
• Mitigation Strategies:
  • Input Validation and Sanitization: Validate and sanitize input keys used for Guava hash-based collections to reduce attacker control over hash values. Consider limiting the length or character sets of keys.
  • Randomized Hash Seeds (where applicable): While not a complete solution, using randomized hash seeds in the underlying hash function (if configurable in your environment - JVM level for HashMap for example, though less direct control with Guava collections) can make collision attacks harder to predict.
  • Limit Collection Size: Implement maximum size limits on Guava hash-based collections to prevent unbounded growth from malicious input, mitigating the impact of a collision attack by limiting its scale.
  • Resource Monitoring and Rate Limiting: Monitor application performance and resource usage (CPU, memory) to detect potential DoS attacks early. Implement rate limiting to restrict the number of requests from a single source, making it harder to flood the application with collision-inducing inputs.
  • Consider Alternative Data Structures: For extremely security-sensitive scenarios where hash collision DoS is a primary concern, evaluate if alternative data structures less susceptible to this attack (like tree-based structures or specialized data structures) are suitable replacements for Guava's hash collections in critical parts of the application.

Attack Surface: Cache Poisoning via Guava Caching

• Description: An attacker manipulates the caching mechanism provided by Guava's CacheBuilder to inject malicious or incorrect data into the cache. This leads to subsequent legitimate requests being served the attacker's poisoned data, compromising application integrity and potentially leading to further attacks.
• Guava Contribution: Guava's CacheBuilder is the direct source of this attack surface. If cache keys or values are derived from untrusted input without rigorous sanitization, or if the cache update/invalidation logic is flawed, it becomes vulnerable to poisoning.
• Example: An application uses Guava's LoadingCache to cache DNS resolution results based on domain names. If domain names used as cache keys are not strictly validated, an attacker could initiate a DNS lookup for a specially crafted domain name designed to resolve to a malicious IP address. If this malicious DNS result is cached by Guava, subsequent legitimate requests for the same (or similar, depending on key normalization) domain name might retrieve the poisoned, malicious IP address from the Guava cache, potentially redirecting users to attacker-controlled servers.
• Impact: Serving malicious content, data corruption, redirection to malicious sites, potential for further attacks (e.g., phishing, man-in-the-middle), compromise of application integrity.
• Risk Severity: High to Critical (Critical if the poisoned data leads to direct compromise of user accounts or critical application functions).
• Mitigation Strategies:
  • Strict Input Sanitization for Cache Keys and Values: Thoroughly sanitize and validate all input used to construct cache keys and values. Use allow-lists and strong validation rules. For example, for domain names, enforce valid domain name formats and potentially use a trusted DNS resolver for initial validation before caching.
  • Secure Cache Key Generation: Ensure cache keys are generated in a secure and predictable manner, minimizing the attacker's ability to influence key creation and predict keys for poisoning.
  • Robust Cache Invalidation and Refresh Mechanisms: Implement reliable cache invalidation and refresh strategies. Use time-based expiration, event-driven invalidation, or background refresh processes to ensure cached data remains fresh and accurate and to limit the window of opportunity for poisoned data to persist.
  • Integrity Checks on Cached Data: If caching sensitive data, consider adding integrity checks (e.g., digital signatures or checksums) to cached values. Verify the integrity of cached data upon retrieval to detect and reject potentially poisoned entries.
  • Principle of Least Privilege for Cache Access: Restrict access to the cache to only necessary components of the application. Limit the ability to modify or invalidate cache entries to authorized processes.

Attack Surface: Unbounded Cache Growth Leading to Memory Exhaustion (DoS)

• Description: Improper configuration or lack of resource limits in Guava's CacheBuilder can allow an attacker to intentionally or unintentionally cause the cache to grow without bounds, consuming excessive memory and leading to Out-of-Memory errors, application crashes, or severe performance degradation (DoS).
• Guava Contribution: CacheBuilder's flexibility in configuration is both a strength and a potential risk. If developers fail to set appropriate size limits or eviction policies, or if the chosen policies are ineffective against specific attack patterns, the Guava cache can become a vector for memory exhaustion.
• Example: An application uses Guava's CacheBuilder to cache API responses based on request parameters. The CacheBuilder is initialized without a maximumSize or effective eviction policy (e.g., only expireAfterWrite with a very long duration). An attacker floods the API with requests using a large number of unique, but valid, request parameter combinations. Each unique request generates a new cache entry. The Guava cache grows continuously, consuming all available memory on the server, eventually causing the application to crash due to an Out-of-Memory error.
• Impact: Denial of Service, application crash, resource exhaustion, instability of the hosting system.
• Risk Severity: High (especially if the application is critical and memory exhaustion leads to significant downtime).
• Mitigation Strategies:
  • Mandatory Maximum Cache Size: Always configure CacheBuilder with a maximumSize(long) or maximumWeight(long, Weigher) to enforce a hard limit on the cache's size. Choose a size appropriate for the application's memory constraints and expected cache usage patterns.
  • Effective Eviction Policies: Implement appropriate eviction policies using CacheBuilder.expireAfterAccess(long, TimeUnit), expireAfterWrite(long, TimeUnit), or removalListener(RemovalListener). Select policies that align with the data's volatility and access patterns to prevent the cache from becoming stale and growing unnecessarily.
  • Proactive Cache Size Monitoring and Alerting: Implement monitoring of the Guava cache's size and memory consumption. Set up alerts to trigger when the cache approaches its maximum size or when memory usage exceeds acceptable thresholds. This allows for proactive intervention before a DoS occurs.
  • Appropriate Cache Scope and Lifetime: Carefully consider the scope and lifetime of data cached in Guava. Avoid caching data that is highly dynamic, has a short lifespan, or is generated frequently from untrusted input if it contributes to rapid and unbounded cache growth. Consider using more targeted or short-lived caching strategies for such data.
  • Resource Limits (Containerization/OS Level): In addition to Guava-level limits, consider implementing resource limits at the containerization or operating system level (e.g., memory limits in Docker, cgroups) to provide an additional layer of protection against memory exhaustion, even if the Guava cache configuration is somehow bypassed or misconfigured.