谈谈流量劫持的危害
2014-06-10 09:55:33   来源：互联网   评论：0 点击：

流量劫持技术详解介绍了常见的流量劫持途径。然而无论用何种方式获得流量，只有加以利用才能发挥作用。

不同的劫持方式，获得的流量也有所差异。DNS 劫持，只能截获通过域名发起的流量，直接使用 IP 地址的通信则不受影响；CDN 入侵，只有浏览网页或下载时才有风险，其他场合则毫无问题；而网关被劫持，用户所有流量都难逃魔掌。

在本文中，我们通过技术原理，讲解如下问题：

• 为什么喜欢劫持网页？

• 只浏览不登陆就没事吗？

• 自动填写表单有风险吗？

• 离开劫持环境还受影响吗？

• 使用 HTTPS 能否避免劫持？

• 流量劫持能否控制我电脑？

为什么喜欢劫持网页？

理论上说，劫持到用户的流量数据，也就获得相应程序的网络通信。但在现实中，数据并不代表真实内容。一些重要的网络程序，都是私有的二进制协议，以及各种加密方式。想通过流量来还原出用户的聊天信息、支付密码，几乎是不可能的。即使花费各种手段，破解出某个程序的通信协议，然而一旦程序升级改变了协议格式，或许就前功尽弃了。因此，很难找到种一劳永逸的客户端劫持方案。

然而，并非所有程序都是客户端的。一种新兴的应用模式 —— WebApp，发展是如此之快，以至于超越客户端之势。在如今这个讲究跨平台、体验好，并有云端支持的年代，WebApp 越来越火热。各种应用纷纷移植成网页版，一些甚至替代了客户端。同时，也造就了流量劫持前所未有的势头。

WebApp，其本质仍是普通的网页而已。尽管网页技术在近些年里有了很大的发展，各种新功能一再增加，但其底层协议始终没有太大的改进 —— HTTP，一种使用了 20 多年古老协议。

在 HTTP 里，一切都是明文传输的，流量在途中可随心所欲的被控制。传统程序事先已下至本地，运行时只有通信流量；而在线使用的 WebApp，流量里既有通信数据，又有程序的界面和代码，劫持简直轻而易举。

上一篇也提到，如果在户外没有 3G 信号的地方钓鱼，无法将获得的流量转发到外网。然而，使用网页这一切就迎刃而解。我们完全可以在自己的设备上搭建一个站点，留住用户发起离线攻击。对于那些连上 WiFi 能自动弹网页的设备，那就更容易入侵了。

因此，劫持网页流量成了各路黑客们的钟爱，一种可在任意网页发起 XSS 的入侵方式。

下面，开始我们的攻防之旅。

只浏览不登陆就没事吗？

每当砖家出来提醒时，总免不了这么一句：公共场合尽量不登录账号。于是，大家就认为只看网页不登陆就平安无事了。

如果是公共的电脑，那也就无所谓；否则，自己的一些账号可能就倒霉了。

在自己的设备上，大家都会记住各种账号的登录状态，反正只有自己用，也没什么大不了的。然而，在被劫持的网络里，一切皆有可能发生。即使浏览再平常不过的网页，或许一个悄无声息的间谍脚本已暗藏其中，正偷偷访问你那登录着的网页，操控起你的账号了。

听起来似乎很玄乎吧，砖家似乎也没说已登录的账号会怎么样。难道随便一个网页，就能让各种账号被控制吗？

大家都知道，HTTP 是无状态的，不像传统协议有个『会话』之类的概念。各种账号的登录状态，只能依靠浏览器的 Cookie 来实现。因此，只要有了的 Cookie 也就获得了用户账号的使用权。

和传统 XSS 攻击不同，流量劫持可以得到任何通信数据，当然也包括那些受 HttpOnly 保护的 Cookie。攻击脚本只需对某个站点发起请求，黑客即可在中途劫持到传输的 Cookie 数据。如果同时发起众多站点，就能覆盖相当一部分目标了。

这种请求未必要真正访问一次页面，仅仅将 URL 作为图片加载，将目标站点的 Cookie 送出即可。

黑客得到 Cookie，即可在自己浏览器里还原出登录状态。尽管你确实没有登录操作，但那些已登录的却能出卖你。

防范措施：访问一些重要的网站，尽量不要记住登录状态，以免 Cookie 被泄露。不过，只要网站绑定了 Cookie 和 IP 段，这招的危害程度就大幅降低了，仅凭 HttpOnly 还是很不靠谱的。

自动填写表单有风险吗？

使用上面的方法获得 Cookie，即使能控制账号，但其密码仍无法得知，随时都有可能失去控制权。

不过，一些用户有让浏览器自动保存密码的习惯。通过这点，我们是否能套出记住的密码来呢？

分析下浏览器是如何自动填写页面表单的。其实很简单，浏览器发现页面 URL 和表单名匹配记录里的，就自动填上了。

要是在流量可控的网络里，剥离页面所有内容只剩表单，又会如何？

保存着的密码仍能自动填上，并且可被脚本访问到！

如果我们在用户访问的页面里，创建大量的隐藏框架页，即可尝试获取各种网站保存着的账号了。（如今 Chrome 框架页已经不会自动填写了。具体实现和浏览器有关）。

然而，即使框架页不自动填写，但主页面总得保留该功能吧。如果发现用户某个打开着的网页很久没有交互了，可悄悄跳转到如上那样的纯表单页，无论能否获取数据，都将继续跳转，一个接一个的尝试。。。直到用户切回窗口，再恢复到原先那个页面。

由于泄露的是明文的账号和密码，即使数量不多，也能通过社工获取到用户的更多信息，最终导致更严重的泄露。

防范措施：所以无论是 Cookie 记住登录，还是浏览器自动填表，重要的账号都应慎用。

 

浏览器的自动填表也应增加些安全策略，例如必须有用户的交互才开始填写，规定的时间里只能填有限次。

离开劫持环境还受影响吗？

或许你在想，网络再怎么不安全，离开之后就应该没事了吧。

有时在公共场合赶上免费的 WiFi，打开网页看一会新闻，是常有的事。这么短的时间里能有多大的事。不过在入侵脚本面前，一小会和长久并没太大区别。机会只要出现了，无论多么短暂都能渗透。

如果只看重眼前利益，这种短暂的入侵并没多少利用价值；但若放远目光，能让攻击在今后发起，那就不再局限于时间和空间了。因此，我们需要一个时光机，让入侵脚本穿越到用户未来的时空运行。

若用传统 XSS 的思维，这几乎无法实现。但在流量劫持面前，一切皆有可能 —— 因为我们能控制任意流量！

HTTP 缓存投毒

上一篇文章提到，但凡有缓存的地方都是大有可为的。显然，对于有着复杂的 HTTP 缓存系统来说，存在缺陷是在所难免了。这种简单的纯文本协议，几乎没有一种签名机制，来验证内容的真实性。即使页面被篡改了，浏览器也完全无法得知，甚至连同注入的脚本也一块缓存起来。

于是，我们可以将『缓存投毒』的概念，引入 HTTP 协议里。但凡具备可执行的资源，都可以通过预加载带毒的版本，将其提前缓存起来。

为了将缓存的有效期发挥到极致，我们事先在各大网站上，找出一些过期时间长、很久没有修改的资源，评估其未来变化不大的可能。

当用户打开任意一个 HTTP 网页时，注入的 XSS 代码开始预加载这些资源。由于一切流量都在控制之中，我们可以完全不走代理，而是返回自己的攻击脚本。

用户浏览器收到回复后，就将其一一缓存起来了。我们可以事先收集大量的资源地址，让用户在线的时间里，尽可能多的缓存受到感染。

未来，用户访问引用了这些资源的网站时，入侵脚本将穿越时空，从沉睡中唤醒。

只要用户不清空缓存，这些被感染的脚本始终附着在浏览器缓存里，直到用户强制刷新页面时或许才能解脱。更多细节可参考这里。

离线储存投毒

不过，有些网站使用的都是很短的缓存，上述的入侵方式似乎就无能为力了。不过，HTML5 时代带来了一项新的缓存技术 —— 离线储存。由于它没有过期时间，因此适用于任意网页的投毒！

类似的，当用户触发了我们的注入脚本之后，我们创建一个隐形的框架页，加载被感染的网页。同样，通过流量劫持，我们返回一个简单的页面，里面包含一个带有 manifest 属性的 HTML 文档，以及后期运行的脚本。

由于通过隐藏框架访问了这个页面，用户并不知情，但尽职的浏览器却将其缓存起来。

未来，用户打开被感染的网页时，浏览器直接从离线储存里取出，其中布置的脚本因此触发。

由于是个空白页面，因此需要填充上真实的网站内容。最简单的方法，就是嵌套一个原页面的框架，并在 URL 里加上随机数，确保是最新的在线内容。

因为嵌套的是同域框架，最终仍能被入侵脚本所控制。

不过，离线存储投毒的后期影响会小一些。未来用户在安全的网络里打开页面时，虽然能立即显示之前缓存的页面，但同时也会尝试访问 .appcache 文件。由于这个文件大多都不存在，因此浏览器很可能删除掉离线数据，导致之后的访问不再使用离线储存。

因此理论上说只有一次的触发机会，但它没有过期时间，适用于任意 HTTP 页面投毒。

防范措施：在不安全的场合，尽量使用『隐身模式』浏览网页。例如 Chrome 里按 Ctrl+Shift+N 就能调出，可将自己处于隔离的沙盒里。