浅谈JavaScript DDOS 攻击原理与防御

前言

DDoS（又名"分布式拒绝服务"）攻击历史由来已久，但却被黑客广泛应用。我们可以这样定义典型的DDoS攻击：攻击者指使大量主机向服务器发送数据，直到超出处理能力进而无暇处理正常用户的合法请求，最终导致用户无法正常访问网站。

近年来，DDoS攻击手段已日趋多元化——攻击者通过各种奇技淫巧诱使不知情主机参加攻击。比如，[注1]历史上数据量最大（超过400Gbps）的DDoS攻击就是通过[注2]NTP反射完成的。时至今日，我们已经发现一个令人不安的趋势：攻击者通过恶意的JavaScript诱使不知情的网站用户参加DDoS攻击。NTP反射或[注3]DNS反射可造成的最大损失是由未经防护的服务器数量决定的。一般损失会随着给服务器打补丁而降低，最大的攻击力度也受限于这些服务器的出站能力。不过，JavaScript DDoS却能利用任何安装了网页浏览器的主机都参与攻击，换句话说，其潜在的攻击能力是无限大的。

这篇文章中，我们将从"攻"和"防"两方面与您一同梳理JavaScript DDoS：

1. 攻击：攻击者如何通过恶意地址、服务器劫持、中间人等手段来实施DDoS攻击。
2. 防御：网站如何使用HTTPS和SRI（Subresource Integrity）等手段来避免攻击。

JavaScript DDOS 攻击原理

绝大多数网站交互是由JavaScript实现的。网站的交互一般通过以下2种方法实现：

1. 直接在HTML中添加JavaScript；
2. 引用外部资源（<script src="##">）从而使浏览器获取src指向的代码并运行。

"异步加载内容"技术是使Web2.0时代爆发的关键因素之一。由于新内容的加载可以完全脱离传统的打开链接或加载页面的方式，网页交互形式也显得愈加丰富。但事有两面，JavaScript的HTTP(S)请求使网站交互更加有趣的同时，也使浏览器更容易变成攻击者的武器。

举个例子，下面的脚本可以不断向受害网站发送请求：

1 2 3 4 5 6 7 8

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)

这段恶意脚本会在网页上以每秒100次的频率不断的创建图片标签，这些图片地址都是指向到受害者的网站。因此，访问该页面的人都会在不知情的情况下参与这次攻击。由于访问者浏览器发送的消息是合法的HTTP请求，[注4]我们将其称为"应用层攻击"。不同于传统的NTP/DNS反射攻击（仅仅是堵塞数据传输通道），应用层攻击将使网站服务器在持续无意义的数据处理中耗尽资源并最终无力响应正常请求。

如前所述，如果攻击者建立一个包含恶意JS代码网页的站点，那么该站点的访问者将成为DDoS攻击的参与者。由此推导：该网页的访问量越大，DDoS的流量也越大。然而，由于一般情况下该网页的访问量有限，因此DDoS攻击破坏力也有限。那么，要想实施一次真正"给力"的DDoS攻击，还需要动动脑筋。

利用第三方JavaScript文件

众所周知，很多网站都会使用通用的JavaScript库。也有相当多网站为了节省带宽或提高体验，直接引用网络中的第三方的JavaScript库。据统计，[注5]2014年世界上约30%的网站使用jQuery（一种非常流行的JavaScript库）。其他被广泛使用的JS包括但不限于Facebook SDK和Google Analytics。

如果一个网站包含指向第三方JS文件的脚本标签，那么所有访问者将下载并执行这段脚本。可以想象，如果攻击者能够攻破含有主流JS文件的服务器，并添加一段DDoS代码，所有网站访问者将成为DDoS的攻击者之一。

2014年9月，[注6]RiskIQ曾报道"引用外部jQuery的网站可被黑客利用"，而攻击者可以用恶意代码替代正常代码。由此可见，攻击者给数以万计的网站插入恶意JS代码将不再只是一个理论说法。

什么是SRI？

第三方资源被利用已是司空见惯的问题了。如果脚本已经被黑客篡改，在HTTP中没有任何机制可使网站屏蔽其运行。为了解决这个问题，W3C提出了一个新概念——SRI（Subresource Integrity）。SRI允许网站告知浏览器，仅在脚本完全符合预期时才运行它。

引用外部链接的代码如下：

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

在引入SRI概念之前，无论文件内容是什么，浏览器都将下载并运行该.js文件。如果有人将文件篡改为恶意代码，浏览器依然会毫不犹豫的运行脚本。引入SRI的概念后，你可以这样告诉浏览器：仅运行符合你预期的脚本。哈希加密可以方便地唯一辨识一段数据，因此我们可以通过哈希加密方法实现SRI——文件以其独一无二的哈希值作为指纹。你可以将脚本的可靠版本的哈希值记录在"integrity"属性中。下载该脚本后，浏览器将立即计算该脚本的哈希值并与脚本"integrity"属性标签中的哈希值作比较。如果二者不吻合，那么可以确定脚本已被篡改过，则浏览器就不会运行它。

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

如上引入SRI标签可以保护网站访问者不受被篡改的第三方JS主机影响。计算哈希值是一个简单、一次性的工作。[注7]而且甚至已有专门的网站可以为您计算哈希值。更新：为确保浏览器正确执行同源策略及防止跨站脚本攻击（XSS），脚本的crossorigin属性和CORS（Cross-Origin Resource Sharing）头文件一般都会做SRI。目前SRI还未被浏览器广泛支持，但Chrome和Firefox都已将其列入开发计划中。由于服务器攻击很容易被发现并修复，因此攻击者已经转而使用其他方法插入恶意JS代码。最新的方法就是：[注8]中间人攻击。

中间人攻击

从web服务器出发，一个网站要遍历网络，经过若干跳才能到达你的浏览器。这个过程中任何一跳的主机都有可能被各种方法修改数据，比如篡改HTML或JavaScript的内容。如果在网络通信过程中，主机执行恶意行为，比如在网页中插入恶意JS代码，我们就将其称为"中间人攻击"。在信息传输过程中，修改网站内容是ISP（网络服务提供商）和WiFi服务商惯用的盈利手段。

例如：一些酒店网络、移动网络就会插入广告或其他跟踪cookie到用户浏览的网站中。合法的业务一般不会给网站插入恶意攻击代码，但是这并不代表因特网上的其他人没有能力这样做。如果攻击者能获得类似ISP的网络位置特权，比如网络互联和交换节点，攻击者就可以给经过的网站插入JS。而如果这段JS中含有DDoS脚本，所有网站访问者将成为DDoS参与者。这会发生在任何穿过"流氓网络"的网站身上。

更糟糕的是，如果访问第三方JavaScript文件的路径也经过了攻击者网络，那么参与攻击的浏览器数量将急剧增加。

加密是能够完全防止类似代码注入的技术之一。使用HTTPS，浏览器与web服务器间之间的所有通信将被加密并授权，防止中间人修改代码。如果你的网站完全使用HTTPS，不仅能够防止ISP和WiFi服务商插入广告或追踪cookie，而且关键能够防止你的网站被JavaScript攻击所利用。

JavaScript DDOS攻击已成为日趋严重的互联网安全问题之一。黑客随时可能发起JavaScript DDoS攻击，欢迎各位厂商/白帽子多多发文交流：）

英文原文出自：https://blog.cloudflare.com/an-introduction-to-javascript-based-ddos/

参考资料

[注1]https://blog.cloudflare.com/technical-details-behind-a-400gbps-ntp-amplification-ddos-attack/
[注2]https://blog.cloudflare.com/understanding-and-mitigating-ntp-based-ddos-attacks/
[注3]https://blog.cloudflare.com/deep-inside-a-dns-amplification-ddos-attack/
[注4]https://blog.cloudflare.com/saturday-night-fever-layer-7-attacks-against/
[注5]http://blog.jquery.com/2014/01/13/the-state-of-jquery-2014/
[注6]http://www.riskiq.com/blog/business#/post/jquerycom-malware-attack-puts-privileged-enterprise-it-accounts-at-risk
[注7]https://srihash.org/
[注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