在这个“点开我的链接你的账号就被黑了”的年代，如何给你的裸照加把锁？
|
按：本文来自乌云知识库@呆子不开口，原标题为《我的通行你的证》。本文太高能，但是小编觉得还是值得给好奇好学的我雷读者们看下的。看不懂代码没关系，但是至少在以下情况中你的账号被黑的时候，你知道为什么并且知道该找谁帮忙了。
这篇是我前几个月在CSDN开发者大会上讲的账号通行证安全相关的PPT《我的通行你的证》的文字整理版，稍微补充了点内容。因为懒一直没时间写，但年关将至，想到可以为老家的孩子们多挣点压岁钱…… 几个月前，我在测百度的一个账号体系的漏洞时，无意中进入了慈云寺桥一甜品店的女收银员的百度网盘，当时随便看了两眼，突然发现了她的一张裸照，吓得我赶紧关了页面。当时我就想，如果她是我最好的朋友的女朋友，她的裸照被坏人利用漏洞攻击而泄露了，那该多不好呀。 换位思考后，我闭着眼，对着裸照暗暗发誓，保护女网友，人人有责。 此文比较长，建议各位让女朋友不用再等了，让她穿上裤子先睡。 ｜主流盗号的八十一种姿势密码类漏洞 ——密码泄露、暴力破解、撞库、密码找回漏洞、社工库、钓鱼… 认证cookie被盗 ——xss攻击、网络泄露、中间人攻击 其他漏洞 ——二维码登录、单点登录、第三方登录、客户端web自动登录、绑定其他账号登录、oauth登陆漏洞… 今天不讲密码安全，今天主要讲讲互联网上常见的一些通行证相关的“其他漏洞” ｜先稍微讲讲认证cookie的安全目前各大互联网公司的网站大多使用cookie来实现对用户的认证。如果攻击者拿到了这个认证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 比较好的cookie方案 cookie的不可猜测性 httponly+HTTPS+Secure+HSTS 同IP不同port，尽量不要部署多个不同的web服务，因为cookie不区分端口 ｜通行证的“其他漏洞”常见的通行证相关功能 二维码登录 单点登录 第三方登录 app内嵌页登录 绑定其他账号 跨域传输认证信息 oauth登录 …… ｜ 二维码登录的安全风险1. 无行为确认 用户扫描二维码后，系统需提示用户检验二维码的行为。若无确认，用户扫描攻击者的登录二维码后，相当于给攻击者的票授权。 案例： 可以欺骗劫持进入来往用户的帐号—— WooYun: 可以欺骗劫持进入来往用户的帐号 2. CSRF漏洞伪造授权请求 给票据授权的请求如果是http的，并且可以被攻击者伪造。攻击者可以伪造请求让用户扫描二维码后执行，或让用户以其他形式对攻击者的票据进行授权。 一些二维码的授权请求按理说应该只在app端有效，但大多案例中，此请求在web站登陆状态下也是有效，增大了攻击面。 案例： 微博上点开我发的链接我就可登进你的淘宝支付宝和微博 ——WooYun: 微博上点开我发的链接我就可登进你的淘宝支付宝和微博可盗号可挂马（poc中附若干从洞） 聊着聊着我就上了你……的微信 ——WooYun: 聊着聊着我就上了你……的微信（两处都可以劫持微信登录的漏洞） 修复方案 用户扫描二维码后，系统需提示用户检验二维码的行为，告知风险，询问用户是否要执行操作 用户确认后的请求攻击者无法伪造，比如和用户身份相关的一个校验token 二维码的授权请求在web登陆状态下不可用，甚至可以使用非http协议，可以减少很多的攻击面 ｜绑定其他账号的安全风险绑定请求未做csrf防护，攻击者可以构造恶意请求让用户绑定了攻击者的账号。这样攻击者登录他自己的账号后就可以操作用户的资源。 案例：网易某处点开我的链接就会被盗号 by 子非海绵宝宝 另外绑定了越多第三方的账号，会让你的安全级别降低，因为你的所有账号同时不出事的可能性降低了 修复方案 通用的防CSRF的解决方案，referrer+token 当我在谈csrf或jsonp劫持的时候，曾遇到无数人告诉我referrer可以伪造。我只能说目前我还不知道在浏览器端伪造referrer的方法。如果你可以自己写个程序伪造referrer，那咱俩聊的不是一个事 ｜ 绑定第三方oauth账号登陆的安全风险1、从oauth服务商那获取到accesstoken后，在和本站账号绑定时，未校验state参数，导致绑定请求可以csrf。攻击者可以用csrf估计让你绑定他的账号 2、即使做了state参数的校验。绑定的初始请求，如点击绑定按钮发出的请求未做csrf防护 （编辑：云计算网_泰州站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
浙公网安备 33038102330476号