Programmatic GET Requests with JavaScript: Simple Way to Hack Your Site

To many websites around, their primary goal is to attract as many visitors as possible. As you know, popular sites get high levels of traffic on a daily basis, but definitively, this popularity comes at a price. They’re the target of many attackers. This is not shocking news at all for big sites that (hopefully) have a decent security strategy and conscious system administrators.

However, let’s describe a more frequent scenario, shared by thousands of websites: a database backend that supports a bunch of dynamic pages, with a rather limited number of visits. Certainly, a website is trying hard to get more visitors by offering better content along with a consistent visual presentation, and suddenly ... their strategy works! Apparently, the site is attracting many users, so the Web server starts attending thousand of requests, multiple database connections are simultaneously established, and massive queries are executed. The final result is, in most cases, the complete hang of the whole system.

Sad but true, this is a typical attack popularly known as Denial of Service. Massive http requests are recreated programmatically and performed against the selected server.

Certainly, a good traffic analysis program might help to reduce the possibilities of an attack, thus the solution looks fairly easy. To be fair, we might say that the same easiness involved in solving partially this critical condition, is applied to write web-based programs that make automated http requests.

If we step back for a moment to the part where I explained the basics of the XMLHttpRequest object, it should be clear that there are concrete cases of people using its functionality with malicious purposes, such as denial of service attacks, or programmatic web form emulation.

Now that you’ve got a clear idea about the possible ways that some attacks are carried out in real situations, I’ll show an example written in JavaScript. It makes automated GET requests to a given URL, which might be potentially used either as a test script to verify performance and security issues within a web program, or for badly-intended purposes. Again, I strongly recommend using the code only for testing.