Vulnerability details

### Summary When making any HTTP request, the automatically enabled and self-managed `CookieStore` (aka cookie jar) will silently replace explicitly defined `Cookie`s with any that have the same name from the cookie jar. For services that operate with multiple users, this can result in one user's `Cookie` being used for another user's requests. ### Details This issue is described without security warnings here: https://github.com/AsyncHttpClient/async-http-client/issues/1964 A PR to fix this issue has been made: https://github.com/AsyncHttpClient/async-http-client/pull/2033 ### PoC 1. Add an auth `Cookie` to the `CookieStore` - This is identical to receiving an HTTP response that uses `Set-Cookie`, as shown in issue #1964 above. 2. Handle a different user's request where the same `Cookie` is provided as a passthrough, like a JWT, and attempt to use it by explicitly providing it. 3. Observe that the user's cookie in step 2 is passed as the Cookie in step 1. ### Impact This is generally going to be a problem for developers of backend services that implement third party auth features and use other features like token refresh. The moment a third party service responds by _setting_ a cookie in the response, the `CookieStore` will effectively break almost every follow-up request (hopefully by being rejected, but possibly by revealing a different user's information). If your service sets cookies based on the response that happens here, it's possible to lead to even greater levels of exposure. ### Workaroud You can avoid this issue by disabling the `CookieStore` during client creation: ```java DefaultAsyncHttpClientConfig.Builder clientBuilder = Dsl.config() .setCookieStore(null) // other configuration ; ```