2014-05-02:细节已通知厂商并且等待厂商处理中
2014-05-05:厂商已经确认,细节仅向厂商公开
2014-05-15:细节向核心白帽子及相关领域专家公开
2014-05-25:细节向普通白帽子公开
2014-06-04:细节向实习白帽子公开
2014-06-16:细节向公众公开
当你浏览器登录支付宝的情况下,你敢用手机支付宝客户端扫其他网站的二维码吗?
详细说明:技术细节:
支付宝二维码页面:https://auth.alipay.com/login/homeB.htm?redirectType=parent
该页面请求之后会返回securityId(如web|authcenter_querypwd_login|2fb227a3-e5c0-469e-b27f-471b584cf070),barcode(如https://qr.alipay.com/plpyjknzdbjrluty4b)
securityId主要是来给前端轮询二维码扫描状态的;而barcode是二维码中的字符串,给手机客户端扫描用的。
轮询接口:https://securitycore.alipay.com/barcode/barcodeProcessStatus.json?securityId=web|authcenter_querypwd_login|2fb227a3-e5c0-469e-b27f-471b584cf070&_callback=light.request._callbacks.callback2
二维码的状态信息有waiting(等待扫描)、scan(已扫描)、confirm(手机扫描之后点击确定登录)还有timeout(超时失效)。
二维码扫描之后确认登录请求:https://mobile.alipay.com/scanResult.htm postdata:securityId=web|authcenter_querypwd_login|2fb227a3-e5c0-469e-b27f-471b584cf070
正常的流程是:
1.用户浏览器访问扫码登录页面,页面生成二维码并一直在轮询二维码状态;
2.用户用支付宝客户端扫描二维码,二维码状态变成scan,等待用户确认登录;
3.用户在手机上确认登录;
4.二维码状态变成confirm,浏览器实现以扫描手机的支付宝用户登录支付宝。
但是在第三步,即确认登录请求接口却有一个csrf!
POC流程:
1.攻击者访问扫码登录页面,自己写个浏览器插件实时提取出里面的securityId和barcode,并更新securityId状态到本地,若timeout则刷新二维码;
2.攻击者从本地将barcode当字符串生成自己的二维码图片放在自己的网站上,js一直轮询本地的securityId状态;
3.受害者浏览器登录支付宝的前提下,访问攻击者页面,用手机支付宝客户端扫描上面的二维码;
4.js轮询到securityId变成scan,在一个隐藏iframe里提交form表单来做确认登录请求;
5.攻击者访问的扫码登录页面实现登录受害者的支付宝账号。
情景模拟:
当你浏览器登录支付宝的情况下,如下:
你看到了一个第三方站点的二维码如下:
如果网站上有一些欺骗性的语言,如支付宝客户端扫描得红包,抑或你刚用支付宝买完东西,提示你扫码可以返现之类的社会工程学来诱使你用支付宝客户端扫描二维码。
其实,攻击者那边可能有一个页面一直在等待着你上钩:
一旦你扫描了,然后攻击者的浏览器里就登录了你的支付宝,如下:
小缺陷:
1.受害者扫描之后会发现手机上的确认登录页面,但是此时攻击者已经达到了想要的目的;
2.受害者浏览器支付宝的登录用户和手机上的必须一致,一般人都只有一个支付宝账号。
确认登录接口做下csrf防范吧。
版权声明:转载请注明来源 i8u@乌云 漏洞回应 厂商回应:危害等级:中
漏洞Rank:8
确认时间:2014-05-05 10:51
厂商回复:感谢i8u对支付宝安全的关注,CSRF问题已确认正在修复中。
最新状态:暂无