http-desync-guardian
Analyze HTTP requests to minimize risks of HTTP Desync attacks (precursor for HTTP request smuggling/splitting).
Overview
HTTP/1.1 went through a long evolution since 1991 to 2014:
This means there is a variety of servers and clients, which might have different views on request boundaries, creating opportunities for desynchronization attacks (a.k.a. HTTP Desync).
It might seem simple to follow the latest RFC recommendations. However, for large-scale systems that have been there for a while, it may come with an unacceptable availability impact.
http_desync_guardian library is designed to analyze HTTP requests to prevent HTTP Desync attacks, balancing security and availability. It classifies requests into different categories and provides recommendations on how each tier should be handled.
It can be used either for raw HTTP request headers or already parsed by an HTTP engine. Consumers may configure logging and metrics collection. Logging is rate limited and all user data is obfuscated.
If you think you might have found a security-impacting issue, please follow our Security Notification Process.
Priorities
- Uniformity across services is key. This means request classification, logging, and metrics must happen under the hood and with minimally available settings (e.g., such as log file destination).
- Focus on reviewability. The test suite must require no knowledge about the library/programming languages but only about HTTP protocol. So it’s easy to review, contribute, and re-use.
- Security is efficient when it’s easy for users. Our goal is to make the integration of the library as simple as possible.
- Ultralight. The overhead must be minimal and impose no tangible tax on request handling (see benchmarks).
Supported HTTP versions
The main focus of this library is HTTP/1.1. See tests for all covered cases. Predecessors of HTTP/1.1 don’t support connection re-use which limits opportunities for HTTP Desync, however some proxies may upgrade such requests to HTTP/1.1 and re-use backend connections, which may allow to craft malicious HTTP/1.0 requests. That’s why they are analyzed using the same criteria as HTTP/1.1. For other protocol versions have the following exceptions:
HTTP/0.9requests are never consideredCompliant, but are classified asAcceptable. If any ofContent-Length/Transfer-Encodingis present then it’sAmbiguous.HTTP/1.0– the presence ofTransfer-Encodingmakes a requestAmbiguous.HTTP/2+is out of scope. But if your proxy downgradesHTTP/2toHTTP/1.1, make sure the outgoing request is analyzed.
