When a ws:// request is routed through an HTTP proxy with proxy authentication configured, the client tunnels the connection with an HTTP CONNECT, the same as it does for https://. Once the tunnel is open, the WebSocket upgrade request that follows is sent through the tunnel directly to the origin server, not to the proxy. The proxy-auth gate and the companion request-target selection keyed only on whether the URI was …
With WebSocket compression enabled, the client inflates permessage-deflate messages with no limit on the decompressed size. It installed Netty's shared WebSocketClientCompressionHandler.INSTANCE, whose inflater is unbounded, and webSocketMaxFrameSize and webSocketMaxBufferSize only bound the compressed bytes, because the frame aggregator sits in front of the inflater. A malicious or compromised WebSocket server, or anyone on the path of a ws:// connection, can therefore send a message of about 2 MiB that inflates …
When a request is replayed onto a different host, the client updates only the current request and leaves the target request pointing at the original host. Four consumers read that stale value, and each one sends the first host's request, credentials, or both to the second host. A replay happens through documented, ordinary features: a ResponseFilter that returns a different request, which is the supported failover pattern, and the IOException …
The fix for GHSA-vvp4-63h8-v5pm in 3.0.13 folded the authenticated principal into the HTTP/1.1 connection pool key, so that a connection one principal authenticated with NTLM, Kerberos or SPNEGO is not handed to another. It left three cases out. In each, a socket that one identity authenticated can still be drawn by a request belonging to a different identity, and the server serves that request as the first one. A login …
A Digest challenge that does not yield a usable nonce is treated as a Basic challenge. The client then answers it with Authorization: Basic, which carries the username and password base64 encoded and so recoverable by anyone who sees the request. Any of these is enough, sent by whoever writes the 401 or 407: WWW-Authenticate: Digest realm="protected" WWW-Authenticate: Digest realm="protected", nonce="" The challenge announces itself as Digest, so it passes …
The client nonce used in HTTP Digest authentication was generated from ThreadLocalRandom, a fast but non-cryptographic pseudorandom number generator. RFC 7616 section 3.3 requires the cnonce to be unpredictable, since it is part of what protects the Digest exchange against chosen-plaintext and precomputation attacks on the credentials. An attacker able to observe or influence enough of the generator's output could reduce the unpredictability the protocol depends on. NTLM (and, on …
The cookie store ignores the scheme a Set-Cookie arrived on. draft-ietf-httpbis-rfc6265bis-22 (approved to obsolete RFC 6265, in the RFC Editor queue) Section 5.7 requires a user agent to ignore a cookie with the Secure attribute unless it arrived over a secure connection (step 13), and to ignore a non-Secure cookie from an insecure connection when it would overlay a Secure cookie the store already holds (step 16). Neither rule is …
The cookie store decides whether a Domain attribute may be accepted using only the domain-matching rule of RFC 6265 Section 5.1.3, which asks whether the request host is the domain or ends with a dot followed by it. Section 5.3 step 5, which additionally requires rejecting a Domain that is a public suffix, is not implemented anywhere in the client. So a host under a multi-label public suffix can set …
With the cookie store enabled, which is the default, a Cookie header that the caller sets on a request with setHeader or addHeader is thrown away whenever the store holds any cookie for the request's origin: the request's cookie list is written into that header afterwards and replaces it. CVE-2024-53990 fixed the same problem for cookies added with addCookie, but that fix works on the cookie list, and a header …
With automatic response decompression enabled (the default), the HTTP/1.1 path decompresses response bodies with no limit on the total output size. A hostile or compromised server, or an attacker who can change a response in transit, can send a small compressed body that inflates without bound in memory, exhausting the client's heap and causing an OutOfMemoryError. gzip, deflate and snappy are always available as vectors; brotli and zstd apply only …
When a request uses an HTTP proxy to reach an HTTPS origin, the client opens the tunnel with a plaintext CONNECT sent to the proxy before any TLS exists. On affected versions the origin's preemptive credentials were added to that CONNECT. A Basic realm sent Authorization: Basic base64(user:pass) to the proxy in the clear, and NTLM, SPNEGO or Kerberos realms sent their token. The proxy, and anyone who can read …
A client configured with a client-wide realm (a Realm set on the config builder rather than on an individual request) and following redirects could re-send those credentials to a redirect target on a different origin. The redirect code strips the per-exchange realm, but when the target answered 401 the credentials were re-derived from the client config, handing Basic or Digest credentials, or a Negotiate or NTLM token, to an attacker …
For SCRAM, and for Digest with mutual authentication, the client computes the server's verification value (the SCRAM ServerSignature, or the Digest rspauth) but does not act on the result. If the value is present and does not verify, the client only logs it and still delivers the response to the application as a successful, authenticated result. A server that never proved knowledge of the shared secret is accepted, so the …
A cookie tossing / cookie injection issue (CWE-1275). ThreadSafeCookieStore stored a cookie under the value of its Domain attribute without verifying that the responding host is allowed to set a cookie for that domain (RFC 6265 §5.3 step 6). A host the client connects to can therefore plant a cookie scoped to an unrelated domain, and the client will then send that cookie on later requests to that domain.
async-http-client leaks Cookie headers to cross-origin redirect targets. When following a redirect across a security boundary (different origin, or HTTPS→HTTP downgrade), the propagatedHeaders() method in Redirect30xInterceptor.java strips Authorization and Proxy-Authorization headers but does not strip Cookie, so session cookies and other sensitive cookie values are forwarded to the redirect target — which may be attacker-controlled.
When redirect following is enabled (followRedirect(true)), AsyncHttpClient forwards Authorization and Proxy-Authorization headers along with Realm credentials to arbitrary redirect targets regardless of domain, scheme, or port changes. This leaks credentials on cross-domain redirects and HTTPS-to-HTTP downgrades. Additionally, even when stripAuthorizationOnRedirect is set to true, the Realm object containing plaintext credentials is still propagated to the redirect request, causing credential re-generation for Basic and Digest authentication schemes via NettyRequestFactory. An attacker …
When redirect following is enabled (followRedirect(true)), AsyncHttpClient forwards Authorization and Proxy-Authorization headers along with Realm credentials to arbitrary redirect targets regardless of domain, scheme, or port changes. This leaks credentials on cross-domain redirects and HTTPS-to-HTTP downgrades. Additionally, even when stripAuthorizationOnRedirect is set to true, the Realm object containing plaintext credentials is still propagated to the redirect request, causing credential re-generation for Basic and Digest authentication schemes via NettyRequestFactory. An attacker …