朱 珠，傅 晓，王志坚

(河海大学 计算机与信息学院，南京 211100)

0 引言

当下，Android系统已成为国内智能移动终端设备使用最多的操作系统：到2016年末为止，中国移动手机用户已突破13亿人[1]。仅在2016年一年，中国智能手机出货量即达到5.22亿部[2]，其中，使用Android操作系统的设备占中国全部智能设备比例为83.2%，处于绝对主流地位[3]。

由于众所周知的因素，国内Android用户无法通过Google Play市场获取应用程序，因此，第三方应用市场和应用程序开发者自行提供的下载地址成为Android应用程序分发、下载的重要渠道。由于第三方应用市场及应用程序开发者自身较低的安全意识，上述Android应用程序下载渠道也成为恶意攻击者的攻击目标，其中，下载劫持(Download Hijacking)是最常见的攻击手段之一。

下载劫持属于典型的中间人攻击(Man-In-The-Middle Attack)：攻击者在用户与目标服务器之间的链路上部署旁路设备(By-pass Equipment)用以监听用户下载报文；当捕获用户向特定服务器请求下载Android应用程序的报文时，旁路设备便冒充目标服务器向用户发送虚假应答，将用户请求重定向到攻击者指定的地址。中间人攻击是一种常见的网络攻击行为，使用范围广泛，极具破坏力，也以其他多种形式出现，从会话劫持、浏览器劫持到网站挂马(Drive-by download)。

在会话劫持中，攻击者拦截并接管用户和主机之间建立的合法会话，可以访问任何需要身份验证的资源[4]，此时攻击者已经得到了合法的会话ID，可以使用该合法会话ID直接登录，在会话ID没有被泄露的情况下，该攻击者便拥有了合法用户的身份。如今，会话劫持可以通过使用单点登录(Single Sign On)技术轻松检测到[5]。一旦会话被攻击者劫持，受害者可以立即发现并采取措施产生新的会话。

在浏览器劫持中，用户并不是感染常规的恶意软件，而是当连接到恶意或受到攻击的网站时，前端语言(如JavaScript)允许用户的浏览器执行恶意活动。实际上，攻击者通常是在浏览器的允许操作范围内进行活动的，系统默认其行为是合法的，因此，即使是最新的杀毒软件也无法察觉此劫持。目前这种劫持可以通过部署在用户网页浏览器的某种检测器来检测[6]，即根据浏览器行为的上下文关联性，通过对浏览器的正常模式和被劫持模式的状态训练，设计的一种能够发现并终止浏览器可疑行为的检测器。

网站挂马(Drive-by download)攻击比上述两种劫持更常见。当互联网用户访问恶意网页时，恶意网站服务器将包含木马的HTML文档传递给用户的计算机系统，恶意内容利用用户计算机系统上的漏洞，执行攻击者提供的恶意代码以及安装恶意软件。网站挂马的检测是一个热门的研究领域，包括利用数据挖掘技术对网页恶意内容进行恶意或良性分类。其中有一种异常检测，就是在加载网页时监视用户计算机系统的异常变化[7]。

Android应用程序包下载劫持则包含了以上所有劫持的特点。通常情况下，发布者(一般是第三方应用市场及应用程序开发者)使用超文本传输协议(Hyper Text Transfer Protocol, HTTP)发布Android应用程序安装包的统一资源定位符(University Resource Locator，URL)地址，用户通过浏览器或其他下载工具请求该地址上的资源。当用户浏览器发出的HTTP请求(可能是GET方法，也可能是POST方法)被攻击者部署的旁路设备发觉并拦截，便会收到一个旁路设备伪造的HTTP暂时性转移(302 Temporarily Moved)响应，将用户请求重定向到一个攻击者指定的地址，再次发出下载请求(通常指定恶意应用程序包)。该过程中，就应用层方面而言，存在HTTP会话被劫持；就下载方法方面而言，存在用户的浏览器被劫持；就结果方面而言，恶意应用程序被隐蔽强迫下载。所以可以说，Android应用程序包下载劫持是一种涉及了多种劫持的多功能劫持，跟之前所有的劫持攻击相比，更加复杂和难以检测。

上述方法可以将用户下载的安装包替换为任意数据，故存在一定的危害性，但是，由于发布者的资源并未真正被用户下载，发布者通过Web流量分析(Traffic Analytic)可以轻易地判断出自身是否受到下载劫持攻击：页面访问量(Page View，PV)相对于独立访问者(Unique Visitor，UV)的不正常降低，是受到下载劫持的显著特征之一。

为了与本文中将要研究的对象进行区分，将上述传统的下载劫持称为常规下载劫持(Regular Download Hijacking)；与常规下载劫持不同，隐蔽下载劫持(Stealth Download Hijacking)无法通过发布者自身进行的Web流量分析进行发现，除非用户发现受到劫持攻击并报告给发布者，否则该攻击行为对发布者完全隐蔽。

图1 下载劫持攻击中各报文时序关系

以往，认为隐蔽下载劫持技术属于高级网络武器(Advanced Cyber Weapon，ACW)的一部分，一般被高级持续性威胁(Advanced Persistent Threat, APT)应用于针对特定高价值目标的网络攻击中，普通用户难以接触到该类攻击，但是，在2017年年初，发现该技术被应用于针对普通电信用户的大规模下载劫持攻击。该事件与2017年4月Shadow Brokers窃取NSA下属Equation Group的网络武器库类似，标志着流入民间的ACW开始被应用于针对一般人群的大规模网络攻击，同时APT的行动模式也从早期的黑客行动主义逐渐染上鲜明的功利指向性色彩。

1 攻击行为的发现

2017年初，江苏省内某互联网服务提供商(Internet Service Provider, ISP)光纤宽带接入用户在上网时发现，从Android应用程序开发者网站以及第三方应用市场下载的.apk(Android Package)格式安装包被替换为360手机助手、PP助手、豌豆荚等与用户所下载应用无关的第三方应用安装包。用户向该ISP客服反映后，被告知出现此现象的原因是受到病毒和木马攻击，建议用户安装360杀毒软件。

在注意到这一问题之后，联系了部分被替换安装包的应用程序开发者，通过网站Web流量分析发现，相关省份与ISP的PV及UV均未出现异常降低的情况。这一表现明显与以往下载劫持攻击的模式不相匹配，因此尝试通过实验证明攻击行为的存在。

2 仿真实验评估

为了避免干扰，在全新的虚拟机VMware环境下，安装了 Windows 7 sp1旗舰版操作系统，其中浏览器选择的是Internet Explorer 11，通过江苏省某ISP光纤宽带以太网点对点协议(Point to Point Protocol over Ethernet，PPPoE)虚拟拨号接入互联网。根据用户反馈信息，使用浏览器直接下载www.91vst.com首页提供的CIBN微视听应用下载链接，该链接指向位于江苏省泰州市的内容分发网络(Content Delivery Network, CDN)节点，该节点地址为58.222.18.2。重复该操作3次。

下载开始后，浏览器收到的响应流来自于115.231.86.9或115.231.86.10，该地址位于浙江省义乌市，且内容并非CIBN微视听应用安装包，其内容依次是360手机助手、PP助手、豌豆荚。

图2 被替换的安装包

然后，在虚拟机操作系统中通过设置虚拟私有网络(Virtual Private Network，VPN)代理服务器下载该链接，上述现象没有发生，浏览器收到的响应流来自58.222.18.2，确为CIBN微视听应用。

通过上述比较实验，在排除病毒、木马等干扰因素之后，可以初步确定，在该ISP接入网络与该CDN节点之间存在下载劫持攻击。

3 网络报文分析

为了确定攻击者利用何种漏洞在发布者网站与用户之间实现了隐蔽下载劫持，在测试环境中安装Wireshark和WinPcap进行网络抓包分析。

用户点击下载链接之后，浏览器向服务器58.222.18.2发出HTTP请求报文，记为Request0，Request0的HTTP头部如下所示：

GET/vst/apk/updateDownload/Z2J9KVYTBJCFLYYQEWTX.apk HTTP/1.1〗r〗n

Accept: text/html, application/xhtml+xml, */*〗r〗n

Referer: http://www.91vst.com/〗r〗n

…

随后，浏览器收到来自服务器58.222.18.2的HTTP响应报文，记为Response1，Response1的HTTP头部如下所示：

HTTP/1.1 302 Moved Temporarily〗r〗n

Content-Type: text/html〗r〗n

Location: http://115.231.86.10:9780/L06/W_D_J.apk〗r〗n

…

可以看出，该报文为HTTP暂时性转移(302 Temporarily Moved)响应，内容是通知浏览器Request0所请求的资源已暂时转移，应重新请求http://115.231.86.10:9780/L06/W_D_J.apk上的资源。Response1的Time to live值为113，事先已经知道服务器58.222.18.2正常响应的Time to live为56，故可以判断Response1为攻击者部署的旁路设备伪造的HTTP响应。测试环境中，浏览器收到Response1之后，转而请求地址http://115.231.86.10:9780/L06/W_D_J.apk上的资源，向服务器115.231.86.10发出HTTP请求报文，记为Request1，Request1的HTTP头部如下所示：

GET /L06/W_D_J.apk HTTP/1.1〗r〗n

Accept: text/html, application/xhtml+xml, */*〗r〗n

Referer: http://www.91vst.com/〗r〗n

…

服务器115.231.86.10响应Request1之后，此时浏览器所下载的安装包已被替换为豌豆荚。

至此为止，攻击者的劫持手法与常规下载劫持完全一致：通过伪造来源地址，冒充发布者网站向用户浏览器返回伪造的HTTP暂时性转移报文，将浏览器请求重定向到服务器115.231.86.10，下载指定服务器路径上的安装包。问题在于，在这一过程中，用户并未下载服务器58.222.18.2上的资源，但是CDN节点，即服务器58.222.18.2的统计数据上，却显示了用户进行了一次正常下载。这意味着，若不在用户端进行抓包分析，发布者无法凭借在服务器端统计信息分析出自身是否受到了下载劫持攻击。这种攻击模式具有隐蔽下载劫持的鲜明特征，与以往所接触的下载劫持攻击具有显著的差异。

因此，将报文分析的范围从原先的HTTP报文，扩大到全部TCP/IP(Transmission Control Protocol/Internet Protocol)报文。

Request0的TCP/IP头部如下所示：

Internet Protocol Version 4, Src: 192.168.1.110, Dst: 58.222.18.2

Transmission Control Protocol, Src Port: 3771, Dst Port: 80, Seq: 1, Ack: 1, Len: 344

Response1的TCP/IP头部如下所示：

Internet Protocol Version 4, Src: 58.222.18.2, Dst: 192.168.1.110

Transmission Control Protocol, Src Port: 80, Dst Port: 3771, Seq: 1, Ack: 1, Len: 129

Request1的TCP/IP头部如下所示：

Internet Protocol Version 4, Src: 192.168.1.110, Dst: 58.222.18.2

Transmission Control Protocol, Src Port: 3772, Dst Port: 9780, Seq: 1, Ack: 1, Len: 306

可以看出，Request0、Response1、Request1的TCP/IP头部序列号(Sequence number, Seq)和确认号(Acknowledgment number, Ack)均为1，这意味着上述请求与响应报文在发送过程中都各自创建了一个新的TCP会话连接，而不是在同一个TCP会话连接中[8]；并且，服务器和客户端也都正确处理了对方的请求和响应，这是由HTTP的无状态性质所决定的[9]。

在HTTP中，所有客户端与服务器之间的请求与响应都是无状态、无连接的，这意味着服务器的每一次响应不需要与客户端的上一个请求在上下文上语义相关。HTTP的这一特性是为了在请求与响应过程中，服务器与客户端之间可以不保持活动连接，而是重新发起TCP会话连接，从而节省服务器资源。

以Request0为例，该请求报文TCP头部中Seq为1，段长度(segment Length, Len)为344，则在同一个TCP会话连接中，服务器响应报文Response1的TCP头部中，Seq应为1，与请求报文在同一序列中；Ack应为345，由请求报文的Seq加上Len得出。而实际上，Response1并未遵守这一规则，客户端浏览器依然认为Response1是服务器对Request0的应答响应。

通过搜索TCP/IP报文发现，在Request0和Response1报文之间，确实存在一个TCP/IP报文，其Seq为1，Ack为345。将该报文记为Response0，其TCP/IP头部如下所示：

Internet Protocol Version 4, Src: 58.222.18.2, Dst: 192.168.1.110

Transmission Control Protocol, Src Port: 80, Dst Port: 3771, Seq: 1, Ack: 345, Len: 0

从以上内容可以看出，Response0仅存在头部信息，其段长度为0，内容为空。

而在Respons1和Request1报文之间，也存在一个TCP/IP报文，与Response0具有相同的Seq和Ack值。将该报文记为Response2，其TCP/IP头部如下所示：

Internet Protocol Version 4, Src: 58.222.18.2, Dst: 192.168.1.110

Transmission Control Protocol, Src Port: 80, Dst Port: 3771, Seq: 1, Ack: 345, Len: 1412

由于Response2和Response0报文的TCP/IP头部具有相同的Seq和Ack，故在测试环境的TCP堆栈中，后到达的Response2被当作TCP序列错误(TCP Out-Of-Order)报文而舍弃。

图3 报文Response2的内容

分辨出报文Response0和Response2哪一个是真正的响应报文并不是很复杂。将Response2中正文内容的十六进制转换为文本形式，可以看到Response2包含了HTTP响应的首部，内容类型为Android包，长度为26 615 091字节。在时间轴上搜索了所有的包，发现了一系列跟随着Respnose2的HTTP 延续包。将它们合并起来，便得到了真正想要下载的Android包的一个副本。而Response0虽然与Response2有相同的Seq和Ack，但它的实体内容项却是空的。

通过分析Response2报文内容，发现该报文正是来自服务器58.222.18.2的CIBN微视听应用安装包。

4 攻击方法的分析

如上文所述，劫持的攻击机制已经很明确了。服务器58.222.18.2将数据串传输到HTTP响应中，把Request0所请求的Android包的完整副本发送给浏览器。由于MTU(最大传输单元)的限制，HTTP响应在通过网关时被分成多个包。而第一个包(即Response2)包含的首部信息对浏览器决定如何处理该报文有着至关重要的作用。检测到该信息，旁路设备便发送一个伪装的响应报文Response0欺骗浏览器丢弃真实的响应报文Response2，Response0便占用了Response2的Req和Ack。一旦Response2被浏览器丢弃，其所有跟进的延续包到达浏览器都会变成无效。

在一次正常下载过程中，用户浏览器发出下载请求Request0，发布者服务器对此请求进行响应，用户浏览器收到该响应Response2后，完成下载过程。

而在隐蔽下载劫持过程中，攻击者部署的旁路设备在监听到下载请求Request0之后，伪装成发布者服务器，发出虚假的响应Response0和Response1。

其中，Response0的Len为0，内容为空；其TCP/IP头部的Seq为1，Ack为Response0的Seq加上Len。Response0的目的在于，占用发布者服务器对Request0的真实响应报文Response2的Ack，使Response2在到达用户浏览器之后，因为Seq和Ack被Response0占用而被当作TCP序列错误报文舍弃。在这一过程中，由于服务器实际上正常响应了Request0，只是在Response2到达用户浏览器之后才被舍弃，故仍然统计为一次正常下载。

Response1是一个HTTP暂时性转移响应，目的则是将用户浏览器的请求Request0重定向到攻击者指定的URL，使浏览器重新发出请求Request1，转而下载攻击者指定URL上的安装包，从而完成整个下载劫持过程。

图4 隐蔽下载劫持攻击中各报文时序关系

攻击者能够成功实施隐蔽下载劫持的充分条件是，旁路设备伪造的响应报文Response0和Response1先于服务器真实响应报文Response2到达用户端：若Response2先于Response0到达，则后到达的Response0会被当作TCP序列错误而舍弃，用户开始正常下载未被劫持的资源。因此，攻击者部署的旁路设备与用户端之间的距离必定小于服务器到用户端的距离，这一点可以通过响应报文Response1的TTL(Time To Live)值进行证明：服务器正常响应报文的TTL为56，而伪造的响应报文为113。考虑到旁路设备有可能进行了TTL欺骗(TTL Spoofing)，113不是其真实值，TTL的高低不一定反映设备间的路由跳数或距离，因此难以通过TTL和Tracert命令确定旁路设备的地址(实际上，由于ISP在主干网上限制了ICMP协议端口，未能通过该方法确定TTL为113的设备地址)。

但是，可以确定的一点是，旁路设备的伪造响应报文总是在时序上早于真实响应报文。

5 漏洞的影响

如上文所述，攻击者利用了HTTP的无连接特性，通过伪造响应报文，在不中断服务器正常响应的情况下，率先占用真实的响应报文的TCP序列，使真实报文被浏览器端错误舍弃；同时，通过伪造重定向使浏览器转而请求攻击者指定的资源。

该漏洞存在于HTTP协议层，理论上影响所有基于该协议下载的资源。通过实验发现，攻击者仅劫持HTTP GET请求路径中包含“.apk”关键字的下载内容，这意味着攻击者最初的目标很可能是安装Android操作系统的智能设备，因为以该关键字为后缀名的文件均为Android应用程序安装包(Android Package Kit，MIME类型为application/vnd.android.package-archive)[10]，但是在测试中，Android、Windows以及Ubuntu、Debian等操作系统无一例外地受到影响，本文认为这是由于攻击者未能正确识别用户浏览器的User Agent值所导致的[11]，攻击者可能仅想劫持安装Android操作系统的智能设备的下载请求，但是由于技术缺陷未能实现HTTP请求头部中User-Agent字段的判断。

iOS和macOS等操作系统的用户不是该攻击者的目标，因为安装了这些操作系统的设备默认不允许从第三方发布者下载和安装应用程序安装包，而从Apple Store下载的安装包不受该漏洞影响。

在江苏省内，使用HTTP提供下载的Android应用程序安装包均受到了此漏洞的影响，包括开发者网站和第三方应用市场。部分具有应用内更新功能(又称Hot swapping，热更新[12])的Android应用程序也受到了该漏洞的影响，原因是在更新过程中使用了HTTP，被中间设备视同单独的一次HTTP下载请求而进行劫持。

至2016年末，江苏省内互联网宽带接入用户数为2 877.2万户[13]，其中该ISP光纤宽带接入用户数超过1 000万户[14]，据此估计，此次受该下载劫持攻击的用户数不少于1 000万户。按平均每个用户每天5次下载计算，攻击者单日劫持下载量即可突破5 000万次。按照50元/万次下载计算(安卓应用程序推广平均价格)，攻击者单日获利即可超过25万元。

6 特殊的攻击模式

在实验中，发现攻击者的一般攻击模式是，将用户下载的安装包随机替换为豌豆荚、360手机助手、PP助手等。这一模式似乎是由旁路设备根据115.231.86.9和115.231.86.10的负载均衡情况即时进行调整，然而，在这一模式之外，也发现了更为特殊的攻击模式：

苏宁易购网站及其应用程序安装包(m.suning.com)受到了此次下载劫持攻击的影响，与其他应用不同的是，苏宁易购安装包总是被攻击者替换为手机京东。该情况是在其他测试用例中从来没有发生过的。

有理由相信，攻击者具备了识别用户下载请求中的地址，并根据地址预设重定向目标的能力。据此判断，攻击者已具备能力对于不同网站、地址上的应用程序安装包，分别设定具体的劫持规则。这一模式的目的很可能是为了从被劫持应用开发者的竞争对手中获取商业报酬。

图5 受到劫持的苏宁易购安装包

7 漏洞的预防

如上文所述，攻击者通过部署旁路设备向用户发送虚假的响应报文Response0和Response1来实现隐蔽劫持。如果路由端或客户端能对上述两个响应报文进行过滤，便可预防攻击者利用该漏洞进行攻击。

经测试，部署防火墙和入侵检测系统(Intrusion Detection Systems, IDS)无法过滤Response0和Response1，因为这两个包并没有非法的信息结构。

响应报文Response0的目的在于占用真实的响应报文的Seq和Ack值，故攻击者未对其内容进行填充，其仅有头部信息，没有内容信息，段长度为0(Len=0)。将符合上述特征的报文进行过滤后，即可正常下载所请求的安装包，但是并非所有段长度为0的TCP包都是虚假报文。在建立一个TCP会话时，通信双方会发送三个报文段，这三个报文段中的Len均为0，但是其Ack和Seq的值都不会超过1。因此，设置这样一个规则来过滤Response0：如果某个TCP包的Len是0，Ack或Seq中的任何一个大于1，便认为该包无效。但是这个规则也会发生误判：当关闭一个TCP会话时，依旧需要发送一些报文段来进行会话释放，此时的Seq值无法满足不超过1。因此将此规则添加到防火墙或IDS中会使会话中的计算机无法及时断开连接直到超时，白白浪费了资源。

一旦Response0被过滤了，Response2就可以被用户浏览器接受，即可以对需要的应用程序包进行下载，但问题还没有完全解决：点击下载链接时，会有两个应用程序包被下载下来，其中一个是用户请求的应用程序，另一个是随机选择的115.231.86.9或115.231.86.10上的应用程序包。为了解决这个问题，需要对Response1进行过滤。

响应报文Response1是用于将用户请求重定向到攻击者指定的地址。在实验中，已知目标地址为115.231.86.9和115.231.86.10，故只需将头部包含上述两个地址的响应报文过滤掉，即可对Response1进行屏蔽。

在安装了Linux系统的终端或软路由中，可以通过配置iptables/netfilter对该漏洞进行预防。而在安装了其他操作系统的设备上，则需要通过安装第三方模块或应用程序来实现相同的效果。本文在一些基于Linux操作系统(如Debian，Ubuntu和CentOS)的设备上测试了上述两条规则，都有很好的运行效果。

为了有效预防Android应用下载劫持所引发的风险，可以从分布式检测、集中分析以及主动预防等方面从根源上阻止此类劫持攻击。

MITM设备可能部署于网络的任何一个节点，仅依靠部分用户自行检测难以有效地发现。由于下载劫持可被APK安装包的HTTP下载请求触发，故而可以在整个Internet中部署大量分布式节点，模拟用户行为发送下载请求，并对响应报文进行检查。如果响应报文符合下载劫持攻击的特征，则可认为该节点与服务器之间的链路存在MITM设备。节点将相关信息上传至数据中心进行下一步分析。

数据中心在搜集到一定数量的攻击信息后，通过数据挖掘和在线实时分析，统计受劫持用户范围、攻击者所在位置、线路、网络地址、受影响站点等，形成劫持特征库并实时向运营商、站点、用户、行政主管部门和执法单位公布。

受影响用户根据特征库主动将相关劫持站点加入黑名单，并更新防火墙策略过滤恶意报文；受影响站点根据特征库适时调整加密策略，避免使用HTTP明文进行安装包发布及应用内更新；运营商根据特征库及时开展内部审计工作，清查涉及流量劫持等灰色产业链的内部机构及人员。

除了上述技术手段，社会各界也应该意识到，打击下载劫持不仅仅要通过技术手段，更需要通过行政管理手段和法律手段。通过建立检测、分析、预防的全过程控制措施，将用户、运营商、站点、行政主管部门及执法单位紧密联系起来，广泛参与其中。只有使社会各界意识到下载劫持的危害性，才能够对相关灰色产业从业人员形成威慑，从而杜绝此类违法行为。

8 结语

本文通过案例分析，提出了一种针对Android应用程序安装包的隐蔽下载劫持攻击漏洞。对于该漏洞的形成原理、利用机制、攻击者模式、预防方法等问题，本文进行了分析与研究，期望能够给之后的国内外网络安全研究人员提供研究数据与参考资料。

该漏洞相较以往传统下载劫持漏洞，无法通过服务器端流量分析进行发现，具有较强的隐蔽性和危害性。利用该漏洞的攻击者具有利益指向性明确、手法隐蔽、背景深厚等特征，符合对于APT的一般性描述[15]，应及早引起运营商内控部门、通信主管部门以及网络执法部门的警惕。

[4] ORIYANO S P. CEH v9: Certified Ethical Hacker Version 9 Study Guide [M]. Hoboken, NJ: John Wiley and Sons, 2016: 331.

[5] ARMANDO A, CARBONE R, COMPAGNA L, et al. An authentication flaw in browser-based single sign-on protocols: impact and remediations [J]. Computers and Security, 2013, 33(4): 41-58.

[6] MNICA D, RIBEIRO C. An IDS for browser hijacking [EB/OL]. [2018- 01- 07]. http://www.thinkmind.org/download.php?articleid=securware_2015_6_10_30083.

[7] van LE L, WELCH I, GAO X, et al. Anatomy of drive-by download attack [C]// AISC ’13: Proceedings of the 11th Australasian Information Security Conference. Darlinghurst, Australia: Australian Computer Society, 2013, 138: 49-58.

[8] POSTEL J. RFC 793—transmission control protocol [S/OL]. [2018- 01- 07]. http://www.faqs.org/rfcs/rfc793.html.

[9] FIELDING R, GETTYS J, MOGUL J, et al. RFC 2616: hypertext transfer protocol [J]. Computer Science and Communications Dictionary, 1999, 7(9): 3969-3973.

[10] YANG A, STEELE S, FREED N. RFC 6532: Internationalized email headers [S/OL]. [2018- 01- 08]. https://datatracker.ietf.org/doc/rfc6532/?include_text=1.

[11] FIELDING E R, RESCHKE E J. RFC 7231: HyperText Transfer Protocol (HTTP/1.1): semantics and content [S/OL]. [2018- 01- 08]. https://tools.ietf.org/html/rfc7231.

[12] HENNESSY J L, PATTERSON D A. Computer Architecture: A Quantitative Approach [M]. San Francisco, CA: Morgan Kaufmann, 2003: 707.

[13] 江苏省通信管理局.江苏省信息通信业二〇一七年年度滚动发展计划[EB/OL]. [2018- 01- 18]. http://www.jsca.gov.cn:8080/pub/jstx/jstxglj/201711/t20171113_46662.html.(Jiangsu Communications Administration. Annual rolling development plan of information and communications industry in Jiangsu in 2017 [EB/OL]. [2018- 01- 18]. http://www.jsca.gov.cn:8080/pub/jstx/jstxglj/201711/t20171113_46662.html.)

[14] 朱秀霞.江苏电信光网用户数居全国各省之首[N].新华日报, 2015- 12- 15.(ZHU X X. Jiangsu Telecom optical network user number ranking first in the country’s provinces [N]. Xinhua News, 2015- 12- 15.)

[15] LACEY D. Advanced Persistent Threats: How to Manage the Risk to Your Business [M]. [S.l.]: Information Systems Audit and Control Association, 2013: 11-13.