* Rebuilt URL to: https://testdomain.com/ * Trying 172.22.1.1... * TCP_NODELAY set * SOCKS5 communication to testdomain.com:443 * SOCKS5 request granted. * Connected to 172.22.1.1 (172.22.1.1) port 8080 (#0) ... * Curl_http_done: called premature == 0 * Connection #0 to host testdomain.com left intact
If a message is received with both a Transfer-Encoding and a Content-Length header field, the Transfer-Encoding overrides the Content-Length. Such a message might indicate an attempt to perform request smuggling (Section 9.5) or response splitting (Section 9.4) and ought to be handled as an error. A sender MUST remove the received Content-Length field prior to forwarding such a message downstream.
If a Transfer-Encoding header field is present in a response and the chunked transfer coding is not the final encoding, the message body length is determined by reading the connection until it is closed by the server. If a Transfer-Encoding header field is present in a request and the chunked transfer coding is not the final encoding, the message body length cannot be determined reliably; the server MUST respond with the 400 (Bad Request) status code and then close the connection.
在看了星球守护者 的漏洞复现后我发现，用 slowhttptest 验证 Slow HTTP Dos 真实存在，需要注意：
1 2 3 4
1. slow HTTP test status on Xth second: X 数字较小，即较早就开始拒绝服务 2. service available: NO 3. Test ended on X+1th second 4. Exit status: Connection refused 这两点比较重要，真的拒绝服务了直接下一秒就停止测试了
不得不说
其实 Dos 类的漏洞你很不好说，因为访问量过大必然服务器承受不住，这个只能做缓解（流量分析、请求时限、扩容等等） 所以漏扫出来是否存在这个漏洞或者 slowhttptest 的service available: NO，有可能是看片面了（某些请求在开始或者后来被识别后被拒绝、中断，或者网页响应时间是否有某个范围内的增量变化等，尤其是这个增量变化，我曾经发现因为一个资产页面正常请求的数量会变化，时延直接从几百ms级变成几s级的）
