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 and since 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 is the limit of the browser, 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 gets an available socket. This waiting period will give the attacker the network timing of the \(256^{th}\) socket, which belongs to the target page. This occurs because the \(255\) sockets in step 2. are still blocked, so if the pool got 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


Similarly 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 ↩︎