10
| 本文作者： 小芹菜 | 2016-02-05 11:46 |
按：本文來自烏云知識庫@呆子不開口，原標(biāo)題為《我的通行你的證》。本文太高能，但是小編覺得還是值得給好奇好學(xué)的我雷讀者們看下的?？床欢a沒關(guān)系，但是至少在以下情況中你的賬號被黑的時候，你知道為什么并且知道該找誰幫忙了。
這篇是我前幾個月在CSDN開發(fā)者大會上講的賬號通行證安全相關(guān)的PPT《我的通行你的證》的文字整理版，稍微補(bǔ)充了點內(nèi)容。因為懶一直沒時間寫，但年關(guān)將至，想到可以為老家的孩子們多掙點壓歲錢……
幾個月前，我在測百度的一個賬號體系的漏洞時，無意中進(jìn)入了慈云寺橋一甜品店的女收銀員的百度網(wǎng)盤，當(dāng)時隨便看了兩眼，突然發(fā)現(xiàn)了她的一張裸照，嚇得我趕緊關(guān)了頁面。當(dāng)時我就想，如果她是我最好的朋友的女朋友，她的裸照被壞人利用漏洞攻擊而泄露了，那該多不好呀。
換位思考后，我閉著眼，對著裸照暗暗發(fā)誓，保護(hù)女網(wǎng)友，人人有責(zé)。
此文比較長，建議各位讓女朋友不用再等了，讓她穿上褲子先睡。
密碼類漏洞
——密碼泄露、暴力破解、撞庫、密碼找回漏洞、社工庫、釣魚…
認(rèn)證cookie被盜
——xss攻擊、網(wǎng)絡(luò)泄露、中間人攻擊
其他漏洞
——二維碼登錄、單點登錄、第三方登錄、客戶端web自動登錄、綁定其他賬號登錄、oauth登陸漏洞…
今天不講密碼安全，今天主要講講互聯(lián)網(wǎng)上常見的一些通行證相關(guān)的“其他漏洞”
目前各大互聯(lián)網(wǎng)公司的網(wǎng)站大多使用cookie來實現(xiàn)對用戶的認(rèn)證。如果攻擊者拿到了這個認(rèn)證cookie，就可以登錄用戶的賬號了。
cookie安全注意點
Httponly：防止cookie被xss偷
https：防止cookie在網(wǎng)絡(luò)中被偷
Secure：阻止cookie在非https下傳輸，很多全站https時會漏掉
Path :區(qū)分cookie的標(biāo)識，安全上作用不大，和瀏覽器同源沖突
Httponly：防止cookie被xss偷 xss攻擊可以獲得用戶的cookie。但如果cookie加上了httponly屬性，js就無法讀取，可以保護(hù)我們的cookie不在xss攻擊中被偷走 但很多安全從業(yè)人員覺得cookie加上httponly了，xss就不算什么漏洞了。這當(dāng)然是無厘頭的，xss是標(biāo)準(zhǔn)的html/js代碼注入漏洞，它不僅僅只是可以偷cookie，還可以做很多，下面會有很多例子…
https：防止cookie在網(wǎng)絡(luò)中被偷 目前主流網(wǎng)站的認(rèn)證cookie在互聯(lián)網(wǎng)中都是無保護(hù)進(jìn)行傳輸?shù)?，可能會在網(wǎng)絡(luò)中被嗅探或其他方式泄露。所以建議安全級別高的網(wǎng)站使用全站https，并且不支持http的訪問，而且還要使用HSTS，強(qiáng)制把http的請求轉(zhuǎn)成https請求
Secure：阻止cookie在非https下傳輸，很多全站https時會漏掉 即使有時候你做了全站https，但你的cookie沒有加上Secure屬性的話。網(wǎng)絡(luò)中間人可以在第三方頁面中強(qiáng)制你使用http訪問做了全站https的domain，此時你的cookie同樣會在不安全網(wǎng)絡(luò)中傳輸。如果加了secure屬性，則此cookie只在https的請求中傳輸
Path :區(qū)分cookie的標(biāo)識，安全上作用不大，和瀏覽器同源沖突 cookie還有一個path屬性，這是一個區(qū)分cookie的標(biāo)識，安全上作用不大，和瀏覽器同源策略沖突。因為，路徑A下的xss雖然讀不到路徑B下的cookie，但路徑A下的xss完全可以注入代碼進(jìn)入路徑B的頁面，然后再去讀路徑B下的cookie
比較好的cookie方案
cookie的不可猜測性
httponly+HTTPS+Secure+HSTS
同IP不同port，盡量不要部署多個不同的web服務(wù)，因為cookie不區(qū)分端口
常見的通行證相關(guān)功能
二維碼登錄
單點登錄
第三方登錄
app內(nèi)嵌頁登錄
綁定其他賬號
跨域傳輸認(rèn)證信息
oauth登錄
……
1. 無行為確認(rèn)
用戶掃描二維碼后，系統(tǒng)需提示用戶檢驗二維碼的行為。若無確認(rèn)，用戶掃描攻擊者的登錄二維碼后，相當(dāng)于給攻擊者的票授權(quán)。
案例： 可以欺騙劫持進(jìn)入來往用戶的帳號—— WooYun: 可以欺騙劫持進(jìn)入來往用戶的帳號
2. CSRF漏洞偽造授權(quán)請求
給票據(jù)授權(quán)的請求如果是http的，并且可以被攻擊者偽造。攻擊者可以偽造請求讓用戶掃描二維碼后執(zhí)行，或讓用戶以其他形式對攻擊者的票據(jù)進(jìn)行授權(quán)。
一些二維碼的授權(quán)請求按理說應(yīng)該只在app端有效，但大多案例中，此請求在web站登陸狀態(tài)下也是有效，增大了攻擊面。
案例：
微博上點開我發(fā)的鏈接我就可登進(jìn)你的淘寶支付寶和微博 ——WooYun: 微博上點開我發(fā)的鏈接我就可登進(jìn)你的淘寶支付寶和微博可盜號可掛馬（poc中附若干從洞）
聊著聊著我就上了你……的微信 ——WooYun: 聊著聊著我就上了你……的微信（兩處都可以劫持微信登錄的漏洞）
修復(fù)方案
用戶掃描二維碼后，系統(tǒng)需提示用戶檢驗二維碼的行為，告知風(fēng)險，詢問用戶是否要執(zhí)行操作
用戶確認(rèn)后的請求攻擊者無法偽造，比如和用戶身份相關(guān)的一個校驗token
二維碼的授權(quán)請求在web登陸狀態(tài)下不可用，甚至可以使用非http協(xié)議，可以減少很多的攻擊面
綁定請求未做csrf防護(hù)，攻擊者可以構(gòu)造惡意請求讓用戶綁定了攻擊者的賬號。這樣攻擊者登錄他自己的賬號后就可以操作用戶的資源。
案例：網(wǎng)易某處點開我的鏈接就會被盜號 by 子非海綿寶寶
另外綁定了越多第三方的賬號，會讓你的安全級別降低，因為你的所有賬號同時不出事的可能性降低了
修復(fù)方案
通用的防CSRF的解決方案，referrer+token
當(dāng)我在談csrf或jsonp劫持的時候，曾遇到無數(shù)人告訴我referrer可以偽造。我只能說目前我還不知道在瀏覽器端偽造referrer的方法。如果你可以自己寫個程序偽造referrer，那咱倆聊的不是一個事
1、從oauth服務(wù)商那獲取到accesstoken后，在和本站賬號綁定時，未校驗state參數(shù)，導(dǎo)致綁定請求可以csrf。攻擊者可以用csrf估計讓你綁定他的賬號
2、即使做了state參數(shù)的校驗。綁定的初始請求，如點擊綁定按鈕發(fā)出的請求未做csrf防護(hù)
新浪微博等某些服務(wù)商的oauth授權(quán)有如下特點，如果當(dāng)前登陸的微博曾經(jīng)授權(quán)過該應(yīng)用，那么就會自動綁定成功。所以我們可以找一個新浪微博登陸的csrf漏洞，讓用戶自動登陸攻擊者的微博（新浪有此類漏洞，這里就不詳細(xì)寫出）。然后再讓用戶訪問綁定請求，這樣就完成了對攻擊者微博的綁定。攻擊者使用微博登陸就可以進(jìn)入用戶的賬號
關(guān)于oauth的更多安全總結(jié)，可以參考文章：OAuth 2.0安全案例回顧
認(rèn)證cookie本應(yīng)該只出現(xiàn)在http請求中，并且在瀏覽器端的存儲中加了httponly屬性，是不會被xss攻擊盜取的。但某些功能架構(gòu)中，認(rèn)證cookie的不規(guī)范傳輸和使用可能會導(dǎo)致認(rèn)證cookie泄露
頁面或接口數(shù)據(jù)輸出了當(dāng)前用戶的認(rèn)證信息，可能被當(dāng)前頁面的XSS攻擊利用
ssrf接口傳輸cookie給第三方
案例：
通過一糯米XSS可繞chrome并可用兩種方式拿到httponly的BDUSS（大部分非IE用戶點擊后百度云盤資料會被泄露）
單點登陸的簡單原理
需求：如果用戶已經(jīng)登陸B(tài)站，則自動登陸A站
實現(xiàn)：用戶訪問A站，A站把用戶跳轉(zhuǎn)到B站，B站驗證用戶已登陸，給用戶一張票，用戶拿著票去找A站，A拿著票去B那，驗證成功后放用戶進(jìn)去
下文中將大量出現(xiàn)如下示例站點
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跳轉(zhuǎn)到
http://www.t99y.com/a.php?ticket=******
然后a.php用ticket參數(shù)去B站驗證用戶合法后，再給用戶種認(rèn)證cookie
偷認(rèn)證信息的大概流程如下，后面會細(xì)講?？傊舻哪康木褪牵玫接脩舻膖icket信息
互聯(lián)網(wǎng)上常見的幾個單點登陸場景，通行證或第三方站給的登陸憑的證使用的方式各有不同，分別該怎么偷。
場景1、直接使用票據(jù)來做驗證
http://t99y.com/a.php?ticket=XXXXXXXXXXXXXXXX
服務(wù)端使用此ticket去sso驗證此用戶身份，然后在本域種認(rèn)證cookie
偷的思路：
讓我們構(gòu)造的頁面獲取到憑證后請求我們控制的服務(wù)器上的資源，這樣referrer里就有ticket信息了
偷的幾種方式：
找能發(fā)自定義src的圖片的頁面去sso取票，帶著ticket信息的頁面會發(fā)起圖片請求，圖片服務(wù)是我們自己的，我們可以讀到請求中的referrer，referrer中會包含ticket信息
找能發(fā)自定義src的iframe的頁面，iframe請求中的referre有ticket
找一個有js跳轉(zhuǎn)漏洞的頁面去取票，跳轉(zhuǎn)目的地址是我們的服務(wù)，js的跳轉(zhuǎn)是帶上referrer的，讀取此請求的referrer，里面包含ticket
如果img和iframe的src值只允許白名單域的url，那就再找一個白名單域的302跳轉(zhuǎn)漏洞來繞過白名單，302跳轉(zhuǎn)可以傳遞上個請求的referrer
Xss獲取地址欄信息
示意圖如下，如下是我畫的一個chrome瀏覽器，地址欄里ticket參數(shù)會被包含到下面的一些元素的請求的referrer中
場景2、中間頁接收ticket完成認(rèn)證，然后用js跳轉(zhuǎn)到我們的目標(biāo)頁
http://t99y.com/login.php?ticket=XXXXXXXXXXXXXXXX&url=http://t99y.com/a.php此時會種上認(rèn)證cookie
然后頁面會使用js跳轉(zhuǎn)到 http://t99y.com/a.php
location.href=“http://t99y.com/a.php”;
例子：某綁定了微博賬號后可以自動登陸的網(wǎng)站
偷的幾種方式
找一個有302跳轉(zhuǎn)漏洞的頁面如b.php，發(fā)起單點登陸請求，然后帶著ticket信息的b.php會跳轉(zhuǎn)到我們的服務(wù)上。因為js的跳轉(zhuǎn)會帶referrer，然后再通過302跳轉(zhuǎn)把referrer傳給我們能控制的頁面
Xss獲取當(dāng)前頁面referrer
場景3、中間頁接收ticket完成認(rèn)證，然后用302跳轉(zhuǎn)到我們的目標(biāo)頁
如下的多個302跳轉(zhuǎn)：
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創(chuàng)建iframe，種超長cookie，讓含ticket的302拒絕服務(wù)，然后使用iframe.contentWindow.location.href讀取最后的iframe的當(dāng)前地址
拒絕服務(wù)還有個好處，防止某些ticket有防重放的防護(hù)
如上方法不適用于IE的一些版本，因為IE在打不開頁面的時候加載的是自己本地的頁面，導(dǎo)致錯誤頁和我們的xss頁面不同源
修復(fù)方案
由認(rèn)證中心來跨域為子站設(shè)置認(rèn)證cookie
單點自動登陸需要防護(hù)csrf，讓用戶不能偽造登陸請求
當(dāng)我們在一個app內(nèi)打開其公司產(chǎn)品的一些鏈接，會被加上認(rèn)證信息去讓用戶自動登陸。
微博客戶端、QQ客戶端、微信客戶端都曾有或現(xiàn)在正有此問題，一般會加上參數(shù)sid、gsid、key
案例：WooYun: 聊著聊著我就上了你……的微信（兩處都可以劫持微信登錄的漏洞） ">聊著聊著我就上了你……的微信
案例：之前的一個手機(jī)qq的漏洞，找一qq域下論壇發(fā)一張圖，然后把此頁發(fā)給手機(jī)qq上好友，他點擊就會被盜號
偷的幾種方式
見單點登錄場景一的幾種方式
用戶甚至?xí)ㄟ^app的分享功能把認(rèn)證信息分享到郵件或朋友圈
修復(fù)方案
不要直接把認(rèn)證憑證添加到webview的URL來完成認(rèn)證
使用COOKIE，POST都可以
跨域從通行證獲取登陸ticket
形式為類似 http://www.wangzhan.com/sso/getst.php?callback=jsonp
然后通行證會返回個jsonp格式的數(shù)據(jù)，里面包含認(rèn)證信息
偷的幾種方式
存在jsonp劫持漏洞
Referrer限制不嚴(yán)格，可以通過字符串匹配繞過?；蛘咧С挚誶eferrer，可以用一些技巧發(fā)出空referer請求來繞過
Xss漏洞，去跨域請求此接口得到數(shù)據(jù)
修復(fù)方案
架構(gòu)上就不該使用此種方案
app和web的接口不要混用，要保證接口的干凈單一。我遇到過一些案例，web和app為了互相兼容，而降低了本身的安全策略，或使用了不合理的架構(gòu)
如上都是漏洞信息，但有時候還有些架構(gòu)上的小問題可能會導(dǎo)致出現(xiàn)漏洞，或者讓攻擊者的漏洞利用更方便。
常見的sso的一些安全風(fēng)險如下：
各個站的票據(jù)通用，很多直接用的就是認(rèn)證cookie
認(rèn)證Cookie設(shè)置保護(hù)不夠，httponly、secure…
sso給子站授權(quán)的票據(jù)可重放
sso給子站授權(quán)的票據(jù)有效期特別長
認(rèn)證信息傳輸未使用https
sso未加入IP或UA等風(fēng)控策略
攻擊者偷到票據(jù)后可輕易使用并無報警
票據(jù)的交互流程保護(hù)不嚴(yán)，容易被漏洞偷。（好的流程應(yīng)該是由sso來跨域頒發(fā)）
修改密碼后認(rèn)證cookie未失效
用戶退出登錄后認(rèn)證cookie未失效
自動登錄，綁定，退出等敏感功能，無csrf防護(hù)
綁定了第三方賬號，降低自己的安全等級
App和web接口混用，導(dǎo)致安全級別降低
案例：你windows上開著QQ點了我的鏈接我就進(jìn)了你的qq郵箱財付通等（任意騰訊xss拿qq的clientkey）
這個案例里除了xss漏洞，有兩個安全設(shè)計上的問題，就是上面提到的：
認(rèn)證Cookie保護(hù)不夠
自動登錄，綁定，退出等敏感功能，無csrf防護(hù)
網(wǎng)絡(luò)是我家，安全靠大家。保護(hù)女網(wǎng)友，幫她加把鎖。
雷峰網(wǎng)原創(chuàng)文章，未經(jīng)授權(quán)禁止轉(zhuǎn)載。詳情見轉(zhuǎn)載須知。
