fix(common): use cryptographically secure SHA-256 for transfer cache key generation - #69153
Conversation
…key generation Replace the custom 64-bit non-cryptographic combined DJB2 hashing implementation in HttpTransferCache with a robust, pure JavaScript, synchronous SHA-256 algorithm. Using DJB2 is vulnerable to pre-image and second-preimage attacks due to its small 64-bit keyspace and mathematical simplicity. An attacker could craft colliding request inputs to poison the cache, potentially causing a CDN or the application to serve the wrong cached response to legitimate users. SHA-256 provides strong cryptographic collision resistance, preventing cache key collision attacks. A custom synchronous implementation is required because the Web Crypto API (`crypto.subtle.digest`) is asynchronous, whereas the transfer cache state lookup and interceptor flow must operate synchronously. Also, update the unit tests to dynamically verify the custom SHA-256 output against the native Web Crypto API.
JeanMeche
left a comment
There was a problem hiding this comment.
AGENT: I have left a few inline suggestions regarding performance optimization for the synchronous SHA-256 implementation. Please consider moving the constants and TextEncoder out of the generateHash function to avoid unnecessary allocations on every request.
… cache key generation
… cache key generation
JeanMeche
left a comment
There was a problem hiding this comment.
AGENT: The updates look great! Thank you for addressing the performance feedback. Moving the constants and TextEncoder out of the function, along with the other optimizations, looks perfectly implemented.
… cache key generation
|
Looks like we'll need a patch backport. |
|
caretaker note: G3 failures are preexisting. |
|
This PR was merged into the repository. The changes were merged into the following branches:
|
|
This pull request has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
Replace the custom 64-bit non-cryptographic combined DJB2 hashing implementation in HttpTransferCache with a robust, pure JavaScript, synchronous SHA-256 algorithm.
Using DJB2 is vulnerable to pre-image and second-preimage attacks due to its small 64-bit keyspace and mathematical simplicity. An attacker could craft colliding request inputs to poison the cache, potentially causing a CDN or the application to serve the wrong cached response to legitimate users.
SHA-256 provides strong cryptographic collision resistance, preventing cache key collision attacks. A custom synchronous implementation is required because the Web Crypto API (
crypto.subtle.digest) is asynchronous, whereas the transfer cache state lookup and interceptor flow must operate synchronously.Also, update the unit tests to dynamically verify the custom SHA-256 output against the native Web Crypto API.