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).