前两篇讲述了长缓存投毒的原理和实现。用户只要在我们的wifi下随便看个网页,就能植入一堆超长潜伏期的后门脚本。
究其原因,还是因为登陆页面的安全性不够。明文传输的网页,总是能轻而易举的注入脚本代码,因此存在风险也就不足为奇。
所以在必要的场合使用HTTPS加密传输,就能完全避免这类安全隐患。这意味着我们的入侵脚本对HTTPS无能为力了吗?
如果从数据解密的角度来说,确实如此。
尽管流量完全在我们的掌控之中,然而用户的私钥却在自己的内存里。我们只能眼睁睁的看着一个被锁着的保险箱在移来移去,却不知道里面藏着什么。
当然,这也不代表完全不能获取HTTPS里的数据。如果我们给想入侵的网站伪造一个证书,于是就能。。。
这么伟大的想法也只有天朝GFW才会用,最终的结果就是在地址栏上一个醒目的红叉:无效的证书!给用户一个莫大的惊喜。
(Chrome下无效证书)
除此之外,再也没有解开HTTPS数据的办法。数据都没法解开,更不用说修改了。
到此,我们的HTTPS脚本投毒计划彻底泡汤了。
但!是!这并不意味我们不能得到用户的信息:我们虽然解不开HTTPS的数据,但可以让用户别进HTTPS的站点。——这句话很奇怪吗?
仔细回想一下 ,你上支付宝网站难道是在地址栏里一个字一个字的敲入htt