Have you heard of the term HTTP Request Smuggling? What about HTTP/2 Downgrading? Well, these are vulnerabilities that can be exploited by cybercriminals when there are issues between the front-end and back-end of websites. If left unresolved, these can result in some very dire consequences for any business. The IT Security Guru chatted with Love Andren, Junior Application Security Auditor, Ghostlabs AppSec at Outpost24, to understand more about this threat.
IT Security Guru (ISG) – What is HTTP Request Smuggling?
Love – An exploit that abuses the fact the web server allows two separate methods when calculating body length, Transfer-Encoding and Content-Length. If both are sent in a single request, it could cause either the front-end or back-end server to interpret the request incorrectly, causing a desync in the back-end server. When done correctly, it would let an attacker smuggle a second HTTP request inside the first one, the response would then be served to the person issuing the next request to the application.
The most common techniques are built around specifying the length of the request body to a value smaller than the actual request body is. This then causes either the front- or back-end server to believe the request ends at a certain point, and the remaining part of the body containing the malicious request, gets smuggled.
The impact ranges from hijacking sessions, bypassing access control to Cross site scripting attacks.
ISG – What is HTTP/2 Downgrading?
Love – While HTTP/2 is widely used, there are still legacy back-end server that exclusively use HTTP/1 since it is still new. Since a HTTP/2 request compared to HTTP/1 is similar when it comes to structure (not the way they are sent) it is straightforward process to convert the request to the others syntax. One main and important difference is that HTTP/2 does not have to specify the request bodies length, since the request/response is sent as bytes.
The problems start when the front-end server starts accepting headers it should not accept, specifying the length of the request. For instance, sending a HTTP/2 request to the application with a body containing another request, but specifying the body length to “0”, could cause front-end server to see it as two separate requests when converting to HTTP/1.1.
In turn, this reintroduces request smuggling in HTTP/2 scenarios.
ISG – Why do organizations/security teams need to be aware of these threats? What can it lead to?
Love – The main reason is the impact of a successful request smuggling attack, as mentioned earlier. The ones listed before all have catastrophic implications for a web application.
Another reason is because of the complexity of the exploit itself; it might be overlooked when planning or skipped to focus on more common and easy to execute exploits (such as XSS or authorization issues).
ISG – Do you think this threat will become more prominent in 2024 and beyond?
Love – Hard for me to say. I personally think that if security engineers get more familiar with this complex exploit, potential attacks could get mitigated. Same goes for ethical hackers and penetration tester, testing or being better at testing smuggling attacks could lead to happier customer.
ISG – How can request smuggling be mitigated?
Love – For HTTP/1 based request smuggling, only allow one of the two headers for determining the length and make sure that both front- and back-end servers are configured to use the same. Block ambiguous request and make sure to always check the body of the request despite what the length specifies.
For request smuggling introduced by HTTP/2 make sure that end-to-end HTTP/2 communication is enabled. If a legacy server is being used and it is necessary to use downgrading, then block requests containing the HTTP/1 headers specifying the body’s size. Another mitigation is blocking other techniques used in request smuggling attacks, such as CRLF sequence injections.
