流量劫持系列8_SSLStrip终极版_location瞒天过海

前言

之前介绍了 HTTPS 前端劫持的方案，虽然很有趣，然而现实却并不理想。其唯一、也是最大的缺陷，就是无法阻止脚本跳转。若是没有这个缺陷，那就非常完美了 —— 当然也就没有必要写这篇文章了。

说到底，还是因为无法重写 location 这个对象 —— 它是脚本跳转的唯一渠道。尽管也流传一些 Hack 能勉强实现，但终究是不靠谱的。

事实上，在最近封稿的 HTML5 标准里，已非常明确了 location 的地位 —— Unforgeable。

这是个不幸的消息。不过也是件好事，让我们彻底打消各种偏门邪道的念头，寻求一条全新的出路。

替换明文 URL

上回也提到，可以参考 SSLStrip 那样，把脚本里的 HTTPS URL 全都替换成 HTTP 版本，即可满足部分场合。

当然，缺陷也是显而易见的。只要 URL 不是以明文出现 —— 例如通过字符串拼接而成，那就完全无法识别了，最终还是无法避免跳转到 HTTPS 页面上。

这种情况并不少见，所以我们需要更先进的解决方案。

替换 location

尽管我们无法重写 location，但要山寨一个和 location 功能一样的玩意，还是非常容易的。我们只需定义几个 getter 和 setter，即可模拟出一个功能完全相同的 location2。但如何将原先的 location 映射过来呢？

这时，后端的作用就发挥出来了。类似替换 HTTPS URL，这次我们只关注脚本里的 location 字符，把它们都改成 location2 —— 于是所有和地址栏相关的读写，都将落到我们的代理上面。之后能做什么，不用说大家也都明白吧。

代理所有的 setter：如果跳转到 HTTPS 就将其拦下，然后降级到 HTTP 版本上。
代理所有的 getter：如果当前处于降级的页面，我们将返回的路径都还原 HTTPS 字符，即可骗过协议判断脚本，让那些自检功能彻底失效！

相比之前的 URL 替换，这个方案完美太多 —— URL 是动态创建的非常普遍，但 location 不是明文出现的，及其罕见。

除非脚本是加密过的，否则即使用 Uglify 那样的压缩工具，也不会把全局变量给混淆。至于人为刻意去转义它，更是无稽之谈了。

<span class="hljs-keyword">if</span> (<span class="hljs-built_in">window</span>[<span class="hljs-string">'loc\ation'</span>].protocol != <span class="hljs-string">'https:'</span>) {
	<span class="hljs-comment">// ...</span>
}`</pre>
到此，我们的目标已经明确了：

前端：实现一个 location 代理。
后端：将脚本里出现的 location 替换成代理变量名。

处理外链脚本

虽然替换页面脚本的内容并不困难，但对于外链脚本，那就不容乐观了。

现实中，不少页面外链了 HTTPS 绝对路径 的脚本。这时，我们的中间人就无能为力了。为了避免这种情况，我们仍需替换页面里的 HTTPS URL，让中间人能掌控更多的资源。

要替换 URL 倒也不难，一个简单的正则就能实现 —— 但既然使用正则，我们面对的只能是字符串了。

然而事实上，收到的都是最原始的二进制数据，甚至未必都是 UTF-8 的。在上一篇文章里，我们为了简单，直接使用二进制的方式注入。但在如今，这个方法显然不可行了。

使用二进制，不仅难以控制，而且很不严谨。我们很难得知匹配到的是独立的字符，还是一个宽字符的部分字节。因此，我们还是得用传统可靠的方式来处理字符串。

处理字集编码

我们得借助字集转换库，例如大名鼎鼎的 iconv，来协助完成这件事：
首先将二进制数据转换成 UTF-8 字符串
有了标准的字符串，我们的正则即可顺利执行了
将处理完的字符串，重新换回先前的编码
尽管这一来一回得折腾两次，性能又得耗费不少，但这仍是必须的。

事实上，这个过程也不是想象的那么顺利。有相当多的服务器，并没有在返回的 Content-Type 里指定编码字集，于是我们只能尝试从页面的 <meta> 中获取。

但这个标签兼容诸多规范，例如过去的：
```
`<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=GBK">`
```
以及如今流行的：
```
`<meta charset="GBK" />
```