I have a pretty good understanding of HTTP Request Smuggling vulnerabilities but one thing I still need some clarification on is if they are domain/subdomain wide or directory wide?

Here's what I mean: If HTTP Request Smuggling vulnerabilities arise because of a configuration difference between a front-end server and any back-end servers, does that mean that you should only test for the vulnerability on a single POST parameter in an entire domain/subdomain?

Let's say you have example.com and they have 2 subdomains (a.example.com & b.example.com). Let's also say that example.com and its 2 subdomains have 2 directories (on each) which you can make a POST request to.

With all of that said, when testing for HTTP Request Smuggling, is it reasonable to test for Request Smuggling on each POSTable request, on each directory. Or is it only worth checking on one POSTable directory per subdomain.

My current assumption is that, if Request Smuggling is inherently server wide, you wouldn't need to test each individual POST request as they would all go through the same back end processes too. But I'd like to be testing properly so anyone's thoughts are appreciated.

1 Answer 1


The attack is not on the location (that would be the directory, the location part of the url), it's not either on the domain (that would be attacks on Host: header, or on absolute url containing host added in the location part of the first line -- things which does exists Practical Host header attacks).

Request smuggling is an attack on the protocol level, so really before any notion of location or host. The attacked part is the HTTP parser of the server. If your server has a protocol level parsing flaw all of the virtualhosts and directories managed by the server could have a problem.

To check the server there is in fact 2 cases:

  • 1/ the server is the final backend
  • 2/ the server is in the middle (a load balancer, TLS terminator, proxy, etc.)

For the first case, if you have a parser flaw the attacker will usually use it to make the server respond to a 'classical request', not something forbidden. As the real target is the server of the second case, the proxy.

For a server used as an intermediary (case 2), if there is a flaw all potential hosts could be targeted.

Let's see one example of smuggling attack, protection bypass. On the proxy you prevent any call to '/admin/' except for some IPs.

The attacker send 1 valid request, and a second request for /admin is hidden in the body. The proxy transmits and see only 1 request with a body. On the backend, because you interpret the request in another way, you see 2 requests, one valid query, and a second one for /admin, and you assume it's a valid query, because it was the job of the proxy to block invalid access to /admin. You send 2 responses. And that's it. Well infact it's a little more complex, to get the '/admin' response you'll need to send 2 valid requests to the proxy, and one hidden in the middle as the 1st request body. You'll get 3 responses from the backend and the proxy will send back the 2 firsts responses, the second one being the response for /admin.

Another example is cache poisoning, if the proxy cache the responses, you have the response of the hidden request replacing the response for the real 2nd request.

Another example is response mangling, once you have introduced a mix between requests and responses in the proxy, everybody get's the response from someone else request, in the worst case this is until you restart the proxy.

So... it's not about testing that you have an issue in one url, if you have an issue on the server... you have an issue.

There's one special case which is only related to one domain. It's when your application, on a specific domain, have an application flaw that introduce HTTP injection. Like a CRLF injection. Let's say you want to generate a redirection with a Location: header, the user has control on arguments used in that header and you do not filter the \r\n (CR and LF) in that content. Then your application, on the specific domains used by that application, may introduce HTTP responses injections. So this special case is HTTP injections introduced by application code.

But the other attacks are independent of the applications, and can only be fixed by using fixed servers, or using some proxy with a robust HTTP parser that would block strange queries before reaching the backend (haproxy is usually pretty good at that for example).

  • Thank you for the indepth answer. I understand the premise of HTTP Request Smuggling and so my question was more related to how you would go about testing it. If you would test every POSTable request on a given domain or if you would only need to test one POSTable request per domain because they all hit the same Load Balancer/proxy/back end.
    – ex7lted
    Aug 29, 2022 at 13:45
  • 1
    If you just want to be sure your HTTP server has no issues use one domain and one path. If you want to test security bypasses on the proxy that's different; try hosts variations, etc.
    – regilero
    Aug 29, 2022 at 14:37
  • How would you go about testing for HTTP Request Smuggling?
    – ex7lted
    Aug 29, 2022 at 16:05
  • 1
    That"s the hard part :-) but you can try some dedicated tools in Burp for example. for me I like manual http pipelines with printf and netcat.
    – regilero
    Aug 30, 2022 at 15:28

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .