Denial of Service (DoS) attacks cause web servers to become unavailable because of the big amount of requests that max out the server resources. Attackers specifically craft these requests to take the server down. One type of DoS attack is the Slow HTTP POST attack.
Slow HTTP POST attack occurs when the attacker holds the connections open by sending edited HTTP POST request that contains a huge value in the Content-Length header. The server expects the request to reach the size in this header before closing the connection. However, the client (attacker) sends the message body at a slow speed which causes the connection to stay open for a longer time.
If the server keeps connections open for multiple requests, it eventually runs out of resources and starts declining new (legit) requests.
In one of the cases I worked on, Qualys marked a URL that is vulnerable to Slow HTTP POST attack. Here is the brief description of the vulnerability:
The web application is possibly vulnerable to a “slow HTTP POST” Denial of Service (DoS) attack. This is an application-level DoS that consumes server resources by maintaining open connections for an extended period of time by slowly sending traffic to the server. If the server maintains too many connections open at once, then it may not be able to respond to new, legitimate connections. Unlike bandwidth-consumption DoS attacks, the “slow” attack does not require a large amount of traffic to be sent to the server — only that the client is able to maintain open connections for several minutes at a time.
In our tests, we found out that Qualys is flagging the URL because the server keeps the connection open for 500 seconds while waiting for request to be completed.
Solution for Slow HTTP POST vulnerability Denial of Service (DoS) attack
Let’s talk about generic suggestions first. Qualys lists the following IIS parameters to change to prevent this vulnerability. It’s hard to determine what value to assign to these parameters. I would recommend playing around the values and keep testing the URL to see if the vulnerability is still flagged or not.
From the Qualys blog post:
- Limit request attributes is through the <RequestLimits> element, specifically the maxAllowedContentLength, maxQueryString, and maxUrl attributes
- Set <headerLimits> to configure the type and size of header your web server will accept
- Tune the connectionTimeout, headerWaitTimeout, and minBytesPerSecond attributes of the <limits> and <WebLimits> elements to minimize the impact of slow HTTP attacks
The suggestions that prevent a similar attack (Host Header attack) may help you fixing HTTP POST attack as well. Here are more details: Solution for Host Header Attack and Vulnerability
Solution crafted to a specific case
In our case, we knew that the vulnerability came out because the server kept the connection open for 500 seconds. The parameter that should prevent the connection to stay open during the slow response is minBytesPerSecond.
The default value is 240. I would recommend assigning a higher value to ensure IIS doesn’t wait too long before terminating the connection. It’s not guaranteed to terminate it before 500 seconds. It may take a few iterations of reconfiguration/retesting until we find the optimum value.
minBytesPerSecond
Specifies the minimum throughput rate, in bytes, that HTTP.sys enforces when it sends a response to the client. The minBytesPerSecond attribute prevents malicious or malfunctioning software clients from using resources by holding a connection open with minimal data. If the throughput rate is lower than the minBytesPerSecond setting, the connection is terminated.
Source
Here is a sample configuration to change minBytesPerSecond and other related parameters (from applicationHost.config)
<webLimits connectionTimeout="00:00:30" dynamicIdleThreshold="0" headerWaitTimeout="00:00:30" minBytesPerSecond="400" />You can set this value in IIS Manager as well:
Another tricky vulnerability is the disclosure of the private IP addresses in the Current-Location header. Check out this solution to prevent this vulnerability: Do not disclose private IP addresses and routing information to unauthorized parties
1 thought on “Prevent Slow HTTP POST vulnerability Denial of Service (DoS) attack”