Suppose an attacker finds that a certain web page retrieval or transaction is taking a long time, like a few seconds. This finding indicates that somewhere in the server infrastructure (web server, application server, database server), you have a vulnerability. The reason: a lot of time and resource is being spent on creating that response. To overload the server, the attacker can keep kicking the link or refreshing the page to generate lots of loads. In a manual mode, this will not last long as her arm will feel sore in a few minutes. But, here is the serious problem: it is very easy to free your arm by automating the same action in the browser.
All one needs is to bring up a browser, like Google Chrome (or any of the ones in the above graphic), open its developer console, and copy and paste the following code snippet:
1
2
3
4
5
6
7
8
9
10
| var total = 0;function launch() { total ++; success: function() { total --; launch(); } });} |
Then, the attacker can just type “launch()” and hit enter. The browser will sit in a loop and tirelessly send your request to the server, wait for the response and then send the request again… and again, and again…
If your browser happens to support multiple ajax requests, which is often the case, you can kick off multiple requests:
If your browser happens to support multiple ajax requests, which is often the case, you can kick off multiple requests:
1
2
3
4
5
6
7
8
9
10
| var total = 0;function launch() { total ++; success: function() { total --; if (total < 10) { launch(); } } });} |
and then the attacker can launch concurrent attacks with the following line in the command line of the developer console:
1
| for (i=0; i<10; i++) { launch(); } |
To increase the load even further, the attacker can start multiple browsers to overload the server. Of course, if she invites her friends to join her in the “fun”, the attack will be amplified by how many friends she can convince.
For a web site which has a page that consistently takes a long time for the initial response to come (initial response is defined as the first packet in the server response), it will not take more than a small team to cause a big impact on the server side.
If that’s still not enough, the attacker can rent some cloud servers to further amplify the attack load. Since the server rental is as cheap as $1c per hour, it’s fairly cheap for a determined attacker to launch a remarkable attack.
I hope I have convinced you that it is fairly easy and cheap to launch a devastating attack. Now we turn our attention to the defense. First we note that this kind of attack is hard to detect since the HTTP request will appear very realistic. Unlike some bots that send HTTP requests with simplistic HTTP headers, the HTTP headers sent here are constructed by the browser itself which has gone through the test of time, it’s hard to use a signature based rule to filter out these kind of requests. Blocking IP can be one possible remedy but it runs the risk of blocking legitimate users who share the same public IP as the attacker (think of a university campus). Worse, this kind of attack is not like a flooding attack (HTTP GET flood on the main page), it is sometimes hard even to find who is attacking.
The best defenses is actually a preventative approach. It is highly recommended that you have a good performance testing program in place for the web site so that each web page is optimized or, at a minimum, you are able to record the performance of each slow page, which, as a result, will help timely detection when attacks on the slow pages occurs.
NetGend LoadStar is the most flexible and yet scalable web performance test platforms available on the market. Please drop us a line (info@netgend.com) if you are interested in learning more about protecting yourself through proactive performance testing and/or performance scanning.
