Browser-Powered Desync Attacks: A New Frontier in HTTP Request Smuggling

## Overview

In this presentation, James Kettle introduces **Browser-Powered Desync Attacks** (also termed client-side desync attacks), describing a shift in HTTP request smuggling research. Historically, HTTP request smuggling required an active attacker sending crafted requests through a front-end reverse proxy to desynchronize communication with a back-end server. Kettle reveals that browsers themselves can be weaponized to launch desync attacks directly against web servers. This discovery eliminates the traditional requirement of having a separate attacker in the communication path or even relying on an intermediary front-end proxy, fundamentally expanding the attack surface.

## Research Background and Connection Reuse

The discovery stemmed from an investigation into request smuggling methodology spanning several years: * **Late 2019:** A wave of false positives in request smuggling detection occurred (even causing an incorrect CVE for Nginx). The initial countermeasure was to avoid reusing HTTP/1 connections during scans. * **Connection-Locked Smuggling:** Kettle discovered that certain vulnerabilities ("connection-locked" request smuggling) could only be detected if HTTP/1 connections were actively reused. * **Refined Methodology:** By deliberately slowing down requests and closely analyzing the exact sequence of events, it became possible to reuse persistent HTTP/1 connections while accurately separating true vulnerabilities from false positives. * **Core Mental Shift:** Kettle emphasizes that "the request is a lie." HTTP/1 is simply a raw byte stream over a TCP connection; assuming statelessness obscures edge-case behaviors introduced by persistent connection reuse.

## HTTP Handling Anomalies and Exploitation Techniques

Before delving into browser-driven attacks, the presentation outlines foundational connection-reuse anomalies: * **Host Header Validation Flaws:** Certain reverse proxies validate access control (e.g., public vs. internal network destinations) using only the `Host` header of the first request on a persistent connection. Sending a legitimate request followed by a request to an internal target over the same connection bypasses the restriction. * **First Request Routing:** A widespread architectural pattern where front-ends inspect the routing metadata of the initial request and naively route all subsequent pipelined/reused requests on that connection to the same back-end. Kettle demonstrates chaining this to bypass front-end routing checks and supply arbitrary, poisoned headers (e.g., poisoning password reset email Host headers).

## Methodology, Scope, and Tooling

Kettle outlines the roadmap and deliverables demonstrated throughout the research: * **Target Coverage:** Real-world exploits and vulnerabilities identified across Apache, Akamai, Varnish, amazon.com, and various web VPNs. * **Methodologies Introduced:** Detailed exploration of client-side desync via four case studies, alongside **pause-based desync** techniques demonstrated live. * **Tooling and Community Artifacts:** Open-source code releases for every finding presented, full proof-of-concept exploit code provided in the accompanying white paper, and free online replica labs allowing practitioners to test and reproduce the techniques on real environments.