Currently, the web session cache handles races between concurrently connecting clients with a singleflight session group. While this works well in the happy path, a misbehaving or noncompliant connection can result in session retrieval failures for all clients racing to cache a new session, providing a thin window for a DoS attack with a stolen web session cookie.
Caveats:
- The proxy that handled login/renewal will always have the session properly cached, leaving no window for a DoS.
- Once a legitimate client successfully connects and caches a session on a given proxy, the window for a DoS is closed.
- Since the client's web cookie is cleared by the shared IP pinning failure, the client would need to win every race to avoid being forced to re-login.
My proposed fix is to replace the session group with a different primitive, such as a mutex, so that concurrent calls do not share success/failure in caching a new session.
Issue originally spotted by Codex - #65086 (comment)
Currently, the web session cache handles races between concurrently connecting clients with a singleflight session group. While this works well in the happy path, a misbehaving or noncompliant connection can result in session retrieval failures for all clients racing to cache a new session, providing a thin window for a DoS attack with a stolen web session cookie.
Caveats:
My proposed fix is to replace the session group with a different primitive, such as a mutex, so that concurrent calls do not share success/failure in caching a new session.
Issue originally spotted by Codex - #65086 (comment)