Understanding DDoS Attacks via Malicious JavaScript and Mitigation with HTTPS and Subresource Integrity
The article explains how malicious JavaScript can be used to launch DDoS attacks through image flooding, server hijacking, and man‑in‑the‑middle injection, and describes mitigation techniques such as HTTPS, Subresource Integrity, and other security measures.
DDoS attacks are among the oldest and most common attacks on websites. Nick Sullivan, a system engineer at CloudFlare, recently wrote about how attackers exploit malicious sites, server hijacking, and man‑in‑the‑middle attacks to launch DDoS, and how HTTPS and the upcoming Subresource Integrity (SRI) can protect sites.
Modern websites rely heavily on JavaScript. Sites add JavaScript directly in HTML or load it from remote locations with <script src=""> tags. JavaScript can issue HTTP(S) requests for asynchronous content, but it can also turn the browser into a weapon. For example, the following code can generate a flood of requests to a target site:
function imgflood() {
var TARGET = 'victim-website.com'
var URI = '/index.php?'
var pic = new Image()
var rand = Math.floor(Math.random() * 1000)
pic.src = 'http://' + TARGET + URI + rand + '=val'
}
setInterval(imgflood, 10)The script creates ten image elements each second, each pointing to the victim site with a random query parameter. If a user visits a page containing this malicious code, the browser will unknowingly participate in a DDoS attack against the victim.
Many sites use common third‑party JavaScript libraries such as jQuery, Facebook SDK, or Google Analytics. To save bandwidth and improve performance they load these libraries from third‑party hosts. If an attacker compromises a host that serves such a library and injects DDoS code, every visitor to the site will execute the malicious script, a form of server hijacking.
This attack succeeds because HTTP lacks a mechanism to forbid tampered scripts. To address this, the W3C has proposed Subresource Integrity, which allows a site to specify a cryptographic hash of the expected script. The browser computes the hash of the downloaded script and compares it with the provided value; a mismatch prevents execution.
Example of an SRI‑enabled script tag:
<script src="https://code.jquery.com/jquery-1.10.2.min.js" integrity="sha256-C6CB9UYIS9UJeqinPHWTHVqh/E1uhG5Twh+Y5qFQmYg=" crossorigin="anonymous"></script>The integrity attribute contains the hash, and the crossorigin attribute enables the check. Most browsers currently do not support SRI, though Chrome and Firefox are adding support.
Man‑in‑the‑middle attacks represent a newer way for attackers to inject malicious JavaScript into a site as traffic passes through intermediate nodes.
Encryption can completely block such code injection. Using HTTPS ensures that all communication between browser and web server is encrypted and authenticated, preventing third parties from modifying pages in transit. Deploying HTTPS‑only sites and proper certificate management effectively mitigates MITM attacks.
Nick notes that SRI and HTTPS complement each other and should be used together for stronger protection, and that employing dedicated DDoS mitigation products is also an option.
Thanks to Wei Xing for reviewing the article.
Source: InfoQ
Architect
Professional architect sharing high‑quality architecture insights. Topics include high‑availability, high‑performance, high‑stability architectures, big data, machine learning, Java, system and distributed architecture, AI, and practical large‑scale architecture case studies. Open to ideas‑driven architects who enjoy sharing and learning.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.