Chinaunix首页 | 论坛 | 博客
  • 博客访问: 1172994
  • 博文数量: 272
  • 博客积分: 3899
  • 博客等级: 中校
  • 技术积分: 4734
  • 用 户 组: 普通用户
  • 注册时间: 2012-06-15 14:53
文章分类

全部博文(272)

文章存档

2012年(272)

分类: 网络与安全

2012-06-26 16:12:07

今天推荐阅读的


这篇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,让浏览器请求真实地址,同时插入一个脚本





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



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

之所以可以攻击成功是因为这段恶意脚本符合浏览器的同源策略(同域,同端口:https)

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

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


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

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

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

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


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


最后,由于现在流行炒作概念,个人还是不建议把PBP这种攻击方式进行正式定义, 还是暂且简写为PBP,口头念念熟先吧。
阅读(1195) | 评论(0) | 转发(0) |
0

上一篇:今日推荐阅读

下一篇:SSL 的那点事

给主人留下些什么吧!~~