Hey, great lab. Thanks for taking the time to make it. In my case, the IP you reference in the proxy configuration (httpd.conf) is not correct, and when I request /categories I receive a 503 Bad Gateway. I made a slight change which worked and I recommend it so it does not depend on the IP. You can change the IP for the name you use for the backend server, in the Dockerfile. Then, the httpd.conf file looks like this:
Hey @dhmosfunk. I have been trying several thing with the vulnerability, and I am seeing the following points:
If well we are being able to see that an internal endpoint was hit, this is happening because we are being able to generate an OOB interaction (an A query for the burp collaborator domain). I believe the ideal scenario would be, as in classical request smuggling, to be able to actually get the response for example of a /admin page (by being able to smuggle a request that is appended to the next request that is done, and actually getting the response for /admin). When i send the following payload for example: GET /categories/1%20HTTP/1.1%0d%0aHost:%20localhost%0d%0aConnection:%20keep-alive%0d%0a%0d%0aGET%20/index.php%20HTTP/1.1%0d%0aHost:%20localhost%0d%0aContent-Length:%20200%0d%0a%0d%0a HTTP/1.1 with the smuggled request with a Content-Length of 200, and I send a follow up request, I am not receiving a 403 on my clients, despite the fact I see on the backend logs, that a request for /index.php was made, and received a 403 response code. This behaviour indicates that the follow up request is not being concatenated as part of the body of the smuggled request (/index.php). Do you believe this depends on specific configuration?
The second point is similar and its about being able to smuggle an entire request in order to trigger response queue poisoning. I will try MaxKeepAliveRequest 1 and get back to you