今天推荐阅读的
Pretty-Bad-Proxy: An Overlooked Adversary in Browsers’ HTTPS Deployments

这篇paper应该是微软研究院的几个中国人搞出来的。

我们知道在不使用中间人攻击的情况下（伪造证书），HTTPS还是比较安全的。（sslv3 防范了中间人攻击）

但是，恶意代理即使无法直接读到HTTPS加密过后的明文，攻击者还是可以结合一些客户端攻击的技巧，达到他的目的。 这就是 PBP

PBP 的paper中提到了4种攻击技巧，都非常的有意思。

我就其中第一种，做了个小测试



环境：使用Paros 模拟evil proxy
浏览器：IE8

Step1：浏览器访问：https://mybank.icbc.com.cn/icbc/perbank/index.jsp

Step2：Paros篡改返回包，返回502错误（其他错误号应该也可以），并插入一个iframe，让浏览器请求真实地址，同时插入一个脚本

<iframe src="https://mybank.icbc.com.cn/icbc/newperbank/logonIdsearch125.jsp" id=ifr></iframe>
<script>
setTimeout( function(){ alert(document.getElementById('ifr').contentWindow.document.body.innerHTML);
}, 5000);
</script>


Step3：通过接下来的请求，可以看到成功读出了iframe的内容



解释：
注意以上攻击过程，并没有用到https的中间人攻击（除开paros的模拟代理过程），所以在真实环境中浏览器不会出任何证书改变的提示

之所以可以攻击成功是因为这段恶意脚本符合浏览器的同源策略（同域，同端口：https）

所以能够读取同域下iframe内的内容。

不光是读取该iframe的内容，还能够向该域进行提交。


风险：
上面这个只是POC，但是在真实的攻击环境中，可以读取CSRF Token，尝试在该域下实施XSS，可以尝试截获用户名和密码。有的https下的cookie没有加secure属性，也会让http下的脚本能够读取到该cookie。

这些都是非常实在的风险。

paper中提到的四种攻击方式都非常的典型，非常有意思，其中更是包含一些绕过浏览器安全提示窗口和图标的方法。

目前使用代理的地方还是非常多的，比如手机浏览器，比如学校，一些内网，还有为了绕过GFW而产生出的一些网页代理等。


防御方案：
浏览器的改进可能在一定程度遏制这个问题。


最后，由于现在流行炒作概念，个人还是不建议把PBP这种攻击方式进行正式定义， 还是暂且简写为PBP，口头念念熟先吧。