On the principle and defense of JavaScript DDOS attack

Objective

DDoS (aka "distributed denial of service") attacks have a long history, but are widely used by hackers. We can define a typical DDoS attack: An attacker directs a large number of hosts to send data to the server until it exceeds the processing power to handle legitimate requests from the normal user, eventually causing the user to fail to access the Web site normally.

In recent years, DDoS attacks have become increasingly diversified-attackers have been luring unsuspecting hosts through various artifice to participate in the attack. For example, [Note 1] a DDoS attack with the largest amount of data in history (more than 400Gbps) is done through [2]NTP reflection]. To this day, we have found a disturbing trend: attackers lured unsuspecting website users into DDoS attacks through malicious JavaScript. The maximum loss caused by NTP reflection or [note 3]dns reflection can be determined by the number of unprotected servers. The general loss is reduced with patching to the server, and the maximum attack strength is limited by the outbound capabilities of these servers. However, JavaScript DDoS can take advantage of any Web browser-installed host to participate in the attack, in other words, its potential attack capacity is infinite.

In this article, we'll be combing JavaScript DDoS with you from both "attack" and "defense":

1. Attack: How an attacker can implement a DDoS attack by means of a malicious address, a server hijacking, an intermediary, and so on.
2. Defense: How websites use HTTPS and Sri (Subresource Integrity) to avoid attacks.

JavaScript DDOS Attack principle

The vast majority of Web site interactions are implemented by JavaScript. Web site interactions are generally implemented in the following 2 ways:

1. Add JavaScript directly to the HTML;
2. Reference external resources (<script src= "# #" >) so that the browser gets the code that the SRC points to and runs it.

The "Asynchronous loading of content" technology is one of the key factors that make the Web2.0 era explode. As new content can be loaded completely out of the traditional way of opening links or loading pages, the form of interactive Web pages is becoming richer. But there are two sides to it, and JavaScript's HTTP (S) request makes web site interaction more interesting while making it easier for the browser to become an attacker's weapon.

For example, the following script can constantly send a request to the victim Web site:

functionimgflood() {   varTARGET =‘victim-website.com‘  varURI =‘/index.php?‘  varpic =newImage()  varrand = Math.floor(Math.random() * 1000)  pic.src =‘http://‘+TARGET+URI+rand+‘=val‘}setInterval(imgflood, 10)

This malicious script will create a picture label on the Web page at a frequency of 100 times per second, and these image addresses are directed to the victim's website. As a result, anyone who accesses the page will unknowingly participate in the attack. Because the message sent by the visitor's browser is a legitimate HTTP request, [Note 4] we refer to it as an "application-level attack." Unlike traditional Ntp/dns-reflex attacks (which only clog data-transfer channels), application-level attacks will cause the Web server to deplete resources and ultimately be unable to respond to normal requests in persistent, meaningless data processing.

As mentioned earlier, if an attacker builds a site that contains a malicious JS code page, visitors to that site will become participants in the DDoS attack. It is deduced that the greater the number of visits to the Web page, the greater the DDoS traffic. However, because of the limited number of visits to the Web page in general, the destructive power of DDoS attacks is limited. Then, to implement a truly "power" DDoS attack, you need to use your brains.

Leverage third-party JavaScript files

As we all know, many websites use a common JavaScript library. There are also quite a few websites that directly refer to third-party JavaScript libraries in the network in order to conserve bandwidth or improve the experience. According to statistics, [note 5]2014, about 30% of the world's websites use jquery (a very popular JavaScript library). Other widely used JS includes, but is not limited to, the Facebook SDK and Google Analytics.

If a Web site contains a script tag that points to a third-party JS file, all visitors will download and execute the script. As you can imagine, if an attacker is able to hack a server containing a mainstream JS file and add a piece of DDoS code, all site visitors will become one of the DDoS attackers.

In September 2014, [note 6]riskiq has reported that "websites that cite external jquery can be exploited by hackers" and that attackers can replace normal code with malicious code.) Thus, it is no longer a theoretical argument for attackers to inject malicious JS code into tens of thousands of websites.

What is Sri?

The use of third-party resources has become a commonplace issue. If the script has been tampered with by hackers, there is no mechanism in HTTP to make the site block it from running. To solve this problem, a new concept--sri (Subresource Integrity) was proposed. Sri allows the Web site to tell the browser to run it only if the script is fully expected.

The code that references the external link is as follows:

<script src="https://code.jquery.com/jquery-1.10.2.min.js">

Before introducing the Sri concept, the browser will download and run the. js file regardless of the content of the file. If someone tampered with the file as malicious code, the browser would still run the script without hesitation. After introducing the concept of SRI, you can tell the browser that only the script that matches your expectations is running. Hash encryption makes it easy to uniquely identify a piece of data, so we can implement the sri--file with its unique hash value as a fingerprint using the hash encryption method. You can record the hash value of a reliable version of the script in the "integrity" attribute. After the script is downloaded, the browser calculates the hash value of the script immediately and compares it to the hash value in the script "integrity" property label. If the two do not match, then you can be sure that the script has been tampered with, then the browser will not run it.

<script src="https://code.jquery.com/jquery-1.10.2.min.js"integrity="sha256-C6CB9UYIS9UJeqinPHWTHVqh/E1uhG5Twh+Y5qFQmYg="crossorigin="anonymous">

The introduction of the Sri Tag will protect site visitors from tampering with third-party JS hosts. Calculating the hash value is a simple, one-time job. [Note 7] and even a dedicated website can calculate the hash value for you. Update: To ensure that the browser performs the same origin policy correctly and prevents cross-site scripting attacks (XSS), the Crossorigin property of the script and the Cors (cross-origin Resource sharing) header file will generally be Sri. Sri has not yet been widely supported by browsers, but Chrome and Firefox have included them in the development plan. Because server attacks are easily discovered and repaired, attackers have instead used other methods to insert malicious JS code. The latest approach is: [note 8] man-in-the-middle attack.

Middleman attack

From the Web server, a Web site to traverse the network, after a number of hops to reach your browser. Any host that jumps in the process may be able to modify the data in various ways, such as tampering with HTML or JavaScript content. If the host performs malicious behavior during network communication, such as inserting malicious JS code into a Web page, we call it a "man-in-the-middle attack." In the process of information transmission, the modification of the content of the site is the ISP (Network service provider) and WiFi provider's usual profit means.

For example, some hotel networks, mobile networks will insert ads or other tracking cookies into the websites that users visit. Legitimate business typically does not inject malicious code into the site, but it does not mean that others on the Internet are not able to do so. If an attacker can obtain network location privileges like ISPs, such as network interconnection and switching nodes, an attacker could inject JS into a Web site. If this JS contains DDoS scripts, all site visitors will become DDoS participants. This can happen on any website that crosses the rogue network.

Worse, if the path to the third-party JavaScript file is also passed through the attacker's network, the number of browsers participating in the attack will increase sharply.

Encryption is one of the techniques that can completely prevent similar code injection. With HTTPS, all communication between the browser and the Web server is encrypted and authorized to prevent the middleman from modifying the code. If your site is fully HTTPS, it will not only prevent ISPs and WiFi providers from inserting ads or tracking cookies, but it will also be critical to prevent your site from being exploited by JavaScript attacks.

JavaScript DDoS attacks have become one of the increasingly serious problems of internet security. Hackers can launch JavaScript DDoS attacks at any time, welcome manufacturers/white hat a lot of communication:)

English Original: https://blog.cloudflare.com/an-introduction-to-javascript-based-ddos/

Resources

[Note 1]https://blog.cloudflare.com/technical-details-behind-a-400gbps-ntp-amplification-ddos-attack/
[Note 2]https://blog.cloudflare.com/understanding-and-mitigating-ntp-based-ddos-attacks/
[Note 3]https://blog.cloudflare.com/deep-inside-a-dns-amplification-ddos-attack/
[Note 4]https://blog.cloudflare.com/saturday-night-fever-layer-7-attacks-against/
[Note 5]http://blog.jquery.com/2014/01/13/the-state-of-jquery-2014/
[Note 6]http://www.riskiq.com/blog/business#/post/jquerycom-malware-attack-puts-privileged-enterprise-it-accounts-at-risk
[Note 7]https://srihash.org/
[Note 8]https://blog.cloudflare.com/introducing-strict-ssl-protecting-against-a-man-in-the-middle-attack-on-origin-traffic/

From:sobug HTTPS://SOBUG.COM/ARTICLE/DETAIL/22

On the principle and defense of JavaScript DDOS attack