Insecure Deployment: HTTP Request Smuggling vulnerability question
We had the Insecure Deployment: HTTP Request Smuggling vulnerability appear on a site recently. The site is HTTPS only. How can there be HTTP request smuggling occuring on a site that doesn't use HTTP?
On the report, this issue and every other discovered issue are off of https://the.site:443/
The fact that https is even referred to twice in the target url makes me wonder about the credibility of this finding.
The articles that I've read regarding this say to use certificates and SSL to mitigate.
Any insight into this issue would be great!
Without an exported scan with logs and traffic it is hard for us to make a determination and can only speculate and respond with what I know.
This vulnerability flags when it is suspected that in chain client server there are other appliances like proxy and that proxy and server are considering different headers (one content-length and other transfer encoding). These attacks were presented at black hat.
This check flags two variants :
- Medium severity bug - if an specially crafted request expected to cause a time out indeed times out but the subsequent request that is sent to generate a "501 Bad Method" response does not respond as expected. - hence not confirmed.
- High severity bug : If the follow up request comes back with 501 response we flag the confirmed HTTP smuggling vuln.
Please look into the traffic monitor, add Scan.CheckId in columns and filter on 11613 - you will be able to see all the attacks sent for this issue.
Here is an example from another scan where we've seen this issue:
First POST attack is sent with content-length 4 and transfer-encoding:chunked. Since front-end server e.g. proxy sees Content-Length, it forwards the partial request (until X) , while the back-end server sees transfer-encoding and expects more chuncks to arrive. This causes timeout.
Once we sense that , check sends subsequent attack where Content-Length is set to 8 , with payload starting with 0 which backend server reads as chunk size and terminates the request right there,
keeping "SPI" in queue. When the next request on the same tcp connection is sent (third normal post reqeust) it is appended to SPI. So it is expected that the http method would become "SPIPOST" which server would not understand and not allow and would respond with eithe 501 or 405 response.
Development is looking into this vuln to verify a 405 should actually be considered and also a potential bug in our check that flags confirmed version. The vuln is considering both 501 Bad method and 405 Method not allowed response. So, there might be an issue with consideration of the 405 response and they are currently reviewing this. As mentioned, if we had a scan with logs and traffic we can present this to them as further evidence.
This site is behind an F5, so it seems like that could be the cause of this issue.
Saying, for the sake of argument, that the issue is because of the F5 traversal, is there something that can be done/set/ changed/added on the site itself that will remediate the issue? The F5 is owned by other entities, and not able to be managed by the owners of the site.
In the 2020 Update 1 release, the SSR has continued to invest resources to ensure we can reduce the number of false positive issues and improve the ability for customers to audit issues. Customers can also expect to see changes in reported issues related to the following:
- Bug fix in HTTP Request Smuggling check reduces false positives related to finding with check ID 11621. The check will no longer be considering HTTP 405 as valid verification of the vulnerability.