Here's an equivalent request represented in the two protocols. I started this research by coding an HTTP/2 client from scratch, but I've concluded that for the attacks described in this paper, we can safely ignore the details of many lower-level features like frames and streams.Īlthough HTTP/2 is complex, it's designed to transmit the same information as HTTP/1.1. Fortunately, there's less to learn than you might think. The first step to exploiting HTTP/2 is learning the protocol fundamentals. This paper is focused entirely on the technical details - if you'd like extra insight into the research journey, please check out the presentation: It is also available as a printable whitepaper. This research paper accompanies a presentation at Black Hat USA and DEF CON, and a recording will be embedded on this page shortly. Finally, I'll share multiple new exploit-primitives introduced by HTTP/2, exposing fresh server-layer and application-layer attack surface. These achieve critical impact by hijacking clients, poisoning caches, and stealing credentials to net multiple max-bounties.Īfter that, I'll unveil novel techniques and tooling to crack open desync-powered request tunnelling - a widespread but overlooked request smuggling variant that is typically mistaken for a false positive. I'll start by showing how these flaws enable HTTP/2-exclusive desync attacks, with case studies targeting high-profile websites powered by servers ranging from Amazon's Application Load Balancer to WAFs, CDNs, and bespoke stacks by big tech. In this paper, I'll introduce multiple new classes of HTTP/2-exclusive threats caused by both implementation flaws and RFC imperfections. HTTP/2 is easily mistaken for a transport-layer protocol that can be swapped in with zero security implications for the website behind it.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |