Trying to achieve response Queue Poisoning, or receiving forbidden page response

[cocoh-23]

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