By chance, I saw an article on the foreign security website CloudFlare that introduced an online attack based on JavaScript, to the effect that a special JS script was added to the web page, so that everyone who visited the web page frequently visited a certain destination website address, and a large number of visits were formed as a DDOS attack, also known as a flood denial of service attack.
![](https://img.laitimes.com/img/__Qf2AjLwojIjJCLyojI0JCLiMGc902byZ2PwIDZiRDN2QDO2EDZhJmNiNGM0QDMkNzNwYGMhN2M2QzLcBza5QTcsJja2FXLp1ibj1ycvR3Lc5Wanlmcv9CXt92YucWbp9WYpRXdvRnL2A3Lc9CX6MHc0RHaiojIsJye.jpg)
This simple web server, simulating the target of the attack, is now ready.
Next, writing the attack script, the JS code embedded in the web page, is the core part:
The meaning of this code, the principle of attack is: every 10 milliseconds, with a random parameter to access the 127.0.0.1/index.html.
In order to prevent the script from being recognized, the JS code can be obfuscated and encrypted, such as using JShaman to encrypt the above JS code:
In this way, the JS code becomes a ciphertext state, and others cannot analyze the code and cannot know the attack logic.
Then there is the use: when the web page is opened, the attack occurs immediately:
As you can see from the above figure, a large number of access requests are immediately monitored in the background.
Looking at the native network connection status, you can see a large number of access connections:
Access by a single person, that is, generates so many connections. If the code is embedded on a page with a lot of traffic, it must be quite powerful?
A better effect is to access web pages on the server that interact with the background and consume the CPU or disk performance of the system, and eventually make it impossible for the web server to process connection requests properly. This is also a common principle of denial of service attacks.
Note: This article is experimental in nature, used for technical research, testing DDOS attacks based on JavaScript scripts, all of which are tested locally on their own machines.
The simple test ends here, and from the experimental point of view, although it does not produce harm, it is proved that the way is effective, at least in theory.
So, how to protect against such a possible attack?
On the attack side, it is necessary to prevent the page from being implanted with illegal scripts.
In the case of the attacked side, website security protection should also be done, such as background logic to limit the frequency of access of the same visitor, and the page design and verification access mechanism that interacts with the server are verified.