在这个“点开我的链接你的账号就被黑了”的年代，如何给你的裸照加把锁？

新浪微博等某些服务商的oauth授权有如下特点，如果当前登陆的微博曾经授权过该应用，那么就会自动绑定成功。所以我们可以找一个新浪微博登陆的csrf漏洞，让用户自动登陆攻击者的微博（新浪有此类漏洞，这里就不详细写出）。然后再让用户访问绑定请求，这样就完成了对攻击者微博的绑定。攻击者使用微博登陆就可以进入用户的账号

案例：点我的链接我就可能会进入你的果壳账号

关于oauth的更多安全总结，可以参考文章：OAuth 2.0安全案例回顾

认证cookie本应该只出现在http请求中，并且在浏览器端的存储中加了httponly属性，是不会被xss攻击盗取的。但某些功能架构中，认证cookie的不规范传输和使用可能会导致认证cookie泄露

页面或接口数据输出了当前用户的认证信息，可能被当前页面的XSS攻击利用 

ssrf接口传输cookie给第三方

案例：

通过一糯米XSS可绕chrome并可用两种方式拿到httponly的BDUSS（大部分非IE用户点击后百度云盘资料会被泄露）

微博上你点我的链接我就可xss你并可拿到httponly的cookie及其他危害

单点登陆的简单原理

需求：如果用户已经登陆B站，则自动登陆A站实现：用户访问A站，A站把用户跳转到B站，B站验证用户已登陆，给用户一张票，用户拿着票去找A站，A拿着票去B那，验证成功后放用户进去

下文中将大量出现如下示例站点

A:http://www.t99y.comB: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信息

互联网上常见的几个单点登陆场景，通行证或第三方站给的登陆凭的证使用的方式各有不同，分别该怎么偷。

场景1、直接使用票据来做验证

http://t99y.com/a.php?ticket=XXXXXXXXXXXXXXXX

服务端使用此ticket去sso验证此用户身份，然后在本域种认证cookie

偷的思路：

让我们构造的页面获取到凭证后请求我们控制的服务器上的资源，这样referrer里就有ticket信息了

偷的几种方式：

找能发自定义src的图片的页面去sso取票，带着ticket信息的页面会发起图片请求，图片服务是我们自己的，我们可以读到请求中的referrer，referrer中会包含ticket信息

找能发自定义src的iframe的页面，iframe请求中的referre有ticket

找一个有js跳转漏洞的页面去取票，跳转目的地址是我们的服务，js的跳转是带上referrer的，读取此请求的referrer，里面包含ticket

如果img和iframe的src值只允许白名单域的url，那就再找一个白名单域的302跳转漏洞来绕过白名单，302跳转可以传递上个请求的referrer

Xss获取地址栏信息

示意图如下，如下是我画的一个chrome浏览器，地址栏里ticket参数会被包含到下面的一些元素的请求的referrer中

参考案例： WooYun: 微博上你点我发的链接我就可以登上你的微博（web版和app端均可两个漏洞一并提交）

场景2、中间页接收ticket完成认证，然后用js跳转到我们的目标页

http://t99y.com/login.php?ticket=XXXXXXXXXXXXXXXX&url=http://t99y.com/a.php此时会种上认证cookie

然后页面会使用js跳转到 http://t99y.com/a.phplocation.href=“http://t99y.com/a.php”;

例子：某绑定了微博账号后可以自动登陆的网站

偷的几种方式

找一个有302跳转漏洞的页面如b.php，发起单点登陆请求，然后带着ticket信息的b.php会跳转到我们的服务上。因为js的跳转会带referrer，然后再通过302跳转把referrer传给我们能控制的页面

Xss获取当前页面referrer

场景3、中间页接收ticket完成认证，然后用302跳转到我们的目标页

如下的多个302跳转：

http://passport.wangzhan.com/login.php?url=http://www.t99y.com/a.phphttp://t99y.com/login.php?ticket=XXXXXXXXXXXXXXXX&url=http://t99y.com/a.phphttp://t99y.com/a.php

偷的方式：

Xss创建iframe，种超长cookie，让含ticket的302拒绝服务，然后使用iframe.contentWindow.location.href读取最后的iframe的当前地址

拒绝服务还有个好处，防止某些ticket有防重放的防护

案例：网易用户登陆状态下点我的链接我就可进入其邮箱、云笔记等服务

如上方法不适用于IE的一些版本，因为IE在打不开页面的时候加载的是自己本地的页面，导致错误页和我们的xss页面不同源

修复方案

由认证中心来跨域为子站设置认证cookie

单点自动登陆需要防护csrf，让用户不能伪造登陆请求

当我们在一个app内打开其公司产品的一些链接，会被加上认证信息去让用户自动登陆。

微博客户端、QQ客户端、微信客户端都曾有或现在正有此问题，一般会加上参数sid、gsid、key

案例：WooYun: 聊着聊着我就上了你……的微信（两处都可以劫持微信登录的漏洞） ">聊着聊着我就上了你……的微信

案例：手机版QQ空间身份因素可被盗用

案例：之前的一个手机qq的漏洞，找一qq域下论坛发一张图，然后把此页发给手机qq上好友，他点击就会被盗号

偷的几种方式

见单点登录场景一的几种方式

用户甚至会通过app的分享功能把认证信息分享到邮件或朋友圈

修复方案

不要直接把认证凭证添加到webview的URL来完成认证

使用COOKIE，POST都可以

跨域从通行证获取登陆ticket

形式为类似 http://www.wangzhan.com/sso/getst.php?callback=jsonp

然后通行证会返回个jsonp格式的数据，里面包含认证信息

案例：微博上你点我发的链接我就可以登上你的微博

偷的几种方式

存在jsonp劫持漏洞 

Referrer限制不严格，可以通过字符串匹配绕过。或者支持空referrer，可以用一些技巧发出空referer请求来绕过

Xss漏洞，去跨域请求此接口得到数据

修复方案

架构上就不该使用此种方案

app和web的接口不要混用，要保证接口的干净单一。我遇到过一些案例，web和app为了互相兼容，而降低了本身的安全策略，或使用了不合理的架构

如上都是漏洞信息，但有时候还有些架构上的小问题可能会导致出现漏洞，或者让攻击者的漏洞利用更方便。

常见的sso的一些安全风险如下：

各个站的票据通用，很多直接用的就是认证cookie 

认证Cookie设置保护不够，httponly、secure…

sso给子站授权的票据可重放

sso给子站授权的票据有效期特别长

认证信息传输未使用https

sso未加入IP或UA等风控策略 

攻击者偷到票据后可轻易使用并无报警 

票据的交互流程保护不严，容易被漏洞偷。（好的流程应该是由sso来跨域颁发）

修改密码后认证cookie未失效 

用户退出登录后认证cookie未失效 

自动登录，绑定，退出等敏感功能，无csrf防护

绑定了第三方账号，降低自己的安全等级 

App和web接口混用，导致安全级别降低

案例：你windows上开着QQ点了我的链接我就进了你的qq邮箱财付通等（任意腾讯xss拿qq的clientkey）

这个案例里除了xss漏洞，有两个安全设计上的问题，就是上面提到的：

认证Cookie保护不够

自动登录，绑定，退出等敏感功能，无csrf防护

网络是我家，安全靠大家。保护女网友，帮她加把锁。

（编辑：云计算网_泰州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!