Connection Pool

Connection Pool

October 1, 2020
Abuse Connection Pool, Browser Limits
Category Attack
Defenses Fetch Metadata, SameSite Cookies

Another way to measure the network timing of a request consists of abusing the socket pool of a browser 1. Browsers use sockets to communicate with servers. As the operating system and the hardware it runs on have limited resources, browsers have to impose a limit.

To exploit the existence of this limit, attackers can:

  1. Check what the limit of the browser is, for example 256 global sockets.
  2. Block \(255\) sockets for a long period of time by performing \(255\) requests to different hosts that simply hang the connection
  3. Use the \(256^{th}\) socket by performing a request to the target page.
  4. Perform a \(257^{th}\) request to another host. Since all the sockets are being used (in steps 2 and 3), this request must wait until the pool receives an available socket. This waiting period provides the attacker with the network timing of the \(256^{th}\) socket, which belongs to the target page. This works because the \(255\) sockets in step 2 are still blocked, so if the pool received an available socket, it was caused by the release of the socket in step 3. The time to release the \(256^{th}\) socket is directly connected with the time taken to complete the request.

Defense #

SameSite Cookies (Lax) COOP Framing Protections Isolation Policies


Similar to partitioned caches, some browsers are considering to extend the principle of “split per site/origin” of resources to socket pools.

References #

  1. Leak cross-window request timing by exhausting connection pool, link ↩︎