Cybersecurity In-Depth: Getting answers to questions about IT security threats and best practices from trusted cybersecurity professionals and industry experts.
Why Should I Care About HTTP Request Smuggling?
HTTP request smuggling is a growing vulnerability, but you can manage the risk with proper server configuration.
Question: What is HTTP request smuggling, what are the risks, and how does server configuration impact the severity?
Asaf Karas, CTO, JFrog Security: HTTP request smuggling is a type of vulnerability that has gained widespread community attention due to numerous high-paying bug bounty reports over the past few months. Not only is HTTP request smuggling gaining traction, but its impact can be detrimental depending on how the servers behind the proxy are configured. Threat actors use this technique to interfere with the way a website processes a sequence of HTTP requests, taking advantage of any inconsistencies.
The attack works when multiple requests are forwarded to the back-end server from the front-end server, which then doesn’t agree about where each message ends. This allows the attacker to insert an ambiguous message that gets interpreted as two separate HTTP requests by the back-end server.
Once a threat actor bypasses the initial security controls, they can wreak all kinds of havoc. Smuggling vulnerabilities may enable an attacker to gain access to forbidden resources such as site administration, hijack a user’s Web sessions, and view sensitive data. It also opens the door to other attacks, including cross-site scripting (XSS) without user interaction, cache poisoning, firewall protections bypass, and credential hijacking. During a cache-poisoning attack, the bad actor targets the cache server, presenting the user with the wrong page upon request.
Websites that do not include load balancers, content delivery networks (CDNs), and reverse proxies are usually safe from HTTP request smuggling. Variants of this type of vulnerability can easily be resolved if the front end of the website is configured to exclusively use HTTP/2 to communicate with the back-end servers.
Alternatively, if back-end connection reuse is entirely disabled, this vulnerability does not pose a threat. Any CDNs that do not want to expose their customers to this type of threat can also configure the front-end server to normalize ambiguous requests before forwarding them to the back end. Ultimately, make sure administrative Web endpoints and sensitive materials are guarded behind robust authentication mechanisms, instead of simple access-control list (ACL) rules in an external proxy or firewall.
Additionally, logged HTTP traffic should always be available to administrative users only – regardless of which part of the HTTP request is logged — to avoid exposing unintended parts of an HTTP request to potential attackers.
About the Author
You May Also Like