林滿佳，唐 屹

（廣州大學(xué)數(shù)學(xué)與信息科學(xué)學(xué)院，廣東廣州 510006）

OAuth授權(quán)流程的安全建模研究

林滿佳，唐 屹*

（廣州大學(xué)數(shù)學(xué)與信息科學(xué)學(xué)院，廣東廣州 510006）

文章實例分析基于國內(nèi)開放平臺的OAuth授權(quán)流程.結(jié)合協(xié)議標(biāo)準(zhǔn)與網(wǎng)絡(luò)蹤跡，使用Alloy語言對授權(quán)流程建模，分析其中的安全問題，利用Alloy分析器找到了可能導(dǎo)致中間人攻擊的漏洞，并實際驗證了這個漏洞.在此基礎(chǔ)上，比較分析了國內(nèi)其他一些開放平臺的類似問題，提出了解決問題的思路.

OAuth協(xié)議；開放平臺；Alloy語言；中間人攻擊

OAuth協(xié)議是一類授權(quán)協(xié)議，允許用戶利用其在第三方站點（IDP）的帳號和口令，訪問某個站點（RP）.這個協(xié)議常被用來構(gòu)造開放平臺，IDP扮演著用戶認(rèn)證服務(wù)器的角色，RP可以依據(jù)IDP的認(rèn)證信息而非用戶在IDP的帳號和口令，授權(quán)用戶訪問并定制訪問內(nèi)容，實現(xiàn)單點登錄.現(xiàn)有的OAuth版本為2.0，本文所稱的OAuth即為這個版本.

OAuth由于使用第三方帳號登錄，其安全問題一直為人們所關(guān)注.OAuth威脅模型定義了OAuth 2.0安全指南［1］，提供開發(fā)者可以遵循的涉及協(xié)議本身的威脅綜合模型及對策.一些形式化方法被用來確認(rèn)文獻(xiàn)［1］中涉及的安全威脅，例如，PAI等使用Alloy建模語言［2］，SLACK等利用Murphi驗證了OAuth2.0客戶端流［3］；CHARI等利用通用可組合安全框架，分析了OAuth2.0的服務(wù)器流［4］，但這些研究，缺乏對實現(xiàn)細(xì)節(jié)及應(yīng)用環(huán)境的綜合考慮.SUN等對現(xiàn)有的OAuth單點登錄實現(xiàn)進(jìn)行了一些實證分析［5］，但這些分析中所涉及的IDP不是國內(nèi)流行的IDP，而且也沒有提出具體的安全隱患解決方案.

本文以國內(nèi)的開放平臺為基礎(chǔ)，分析OAuth授權(quán)流程的安全性，筆者實證分析了騰訊QQ開放平臺的OAuth授權(quán)流程，采用Alloy語言進(jìn)行建模分析，對可能存在的安全脆弱性進(jìn)行了分析與驗證.在此基礎(chǔ)上，比較分析了國內(nèi)其他一些開放平臺的相關(guān)問題，提出了解決問題的一些思路.

1 OAuth授權(quán)流程及應(yīng)用實例

1.1 授權(quán)流程

OAuth授權(quán)過程包含4個角色：用戶U、瀏覽器B、站點RP以及第三方站點IDP，其授權(quán)流程可以分為2類：服務(wù)器端流程（圖1）和客戶端流程（圖2）.

圖1 服務(wù)器端Fig.1 Server-side

服務(wù)器流程需要RP服務(wù)器端的配合.用戶向RP發(fā)出IDP帳號登錄請求，RP在收到請求后做出響應(yīng)，將瀏覽器重定向到IDP進(jìn)行身份驗證.在IDP對用戶身份驗證成功后，會把一個包含有表示對RP授權(quán)的授權(quán)碼響應(yīng)發(fā)回給瀏覽器，這時，瀏覽器重定向到RP，RP使用授權(quán)碼與IDP進(jìn)行交互以獲取訪問令牌，并進(jìn)而訪問用戶的配置數(shù)據(jù).

圖2 客戶端Fig.2 Client-side

客戶端流程無需RP服務(wù)器端的參與，但需要客戶端腳本的支持.流程開始時，用戶選擇用IDP賬號登錄，并通過瀏覽器向IDP發(fā)出身份驗證請求.當(dāng)IDP對用戶身份驗證成功后，會發(fā)出一個帶有用戶配置數(shù)據(jù)的給RP授權(quán)的重定向響應(yīng)，但用戶配置數(shù)據(jù)并不直接轉(zhuǎn)到RP，需要瀏覽器從RP下載并運行腳本，提取用戶配置信息并提交給RP.

客戶端流程比服務(wù)器流程更加簡便，因為在IDP對用戶的身份驗證成功后，客戶端流程的RP獲得的是帶有用戶配置數(shù)據(jù)的響應(yīng)，而服務(wù)器流程的RP在收到授權(quán)響應(yīng)后還要進(jìn)一步與IDP進(jìn)行交互才能獲得用戶的配置數(shù)據(jù).但服務(wù)器流程相對安全，因為客戶端流程直接獲得的用戶配置信息會暴露在瀏覽器上并導(dǎo)致泄露.

1.2 騰訊OAuth授權(quán)流程

以用戶利用其QQ帳號登錄酷6網(wǎng)站來分析騰訊OAuth授權(quán)流程.

1.2.1 瀏覽器從酷6重定向到騰訊

當(dāng)用戶選擇利用騰訊QQ帳號登錄酷6站點后，便開始了騰訊OAuth授權(quán)流程，首先，瀏覽器響應(yīng)酷6的第三方登錄請求，把連接重定向到騰訊的頁面，其重定向的URL如下：

注意到重定向的URL包含一系列的參數(shù)：如酷6站點的ID（client＿id），授權(quán)成功后的回調(diào)地址（redirect＿uri）以及用戶請求訪問范圍（scope）等.

1.2.2 騰訊驗證用戶的身份

騰訊收到重定向過來的信息，首先會檢測相關(guān)的站點是否合法，然后展開對用戶身份進(jìn)行驗證.依據(jù)用戶是否已處于登錄狀態(tài)，彈出確認(rèn)頁或登錄頁.

1.2.3 酷6獲取授權(quán)碼

盡管獲取騰訊訪問令牌的方式有2種，但在筆者的實驗中僅出現(xiàn)服務(wù)器端的方式.騰訊的響應(yīng)將引導(dǎo)瀏覽器重定向到URL：

并附上授權(quán)碼code.之后酷6再使用授權(quán)碼向騰訊請求訪問令牌以獲取用戶的配置數(shù)據(jù).

2 基于Alloy的建模分析

Alloy是一種用于描述協(xié)議或軟件系統(tǒng)的屬性和行為的聲明性語言規(guī)范［6］.利用Alloy對OAuth協(xié)議進(jìn)行建模時，需要對授權(quán)過程中的每個實體建立一個簽名，對有限制條件的實體增加約束事實.這些實體可分為3類：①協(xié)議涉及的角色；②角色交互過程的參數(shù)；③協(xié)議進(jìn)行授權(quán)交互時的相關(guān)的網(wǎng)絡(luò)元素.

以對協(xié)議交互過程的參數(shù)簽名為例.在騰訊開放平臺授權(quán)流程中，需要傳遞一些參數(shù)，如標(biāo)識RP的client＿id，重定向的地址redirect＿uri，RP可訪問范圍scope，授權(quán)碼code等［7］.這些參數(shù)包含name屬性和value屬性，筆者定義1個包含名字和值屬性對的簽名attributeNameValuePair｛name：Token，value：Token｝，然后通過這個簽名派生出上述各參數(shù).

為描述授權(quán)過程，定義以下的主要謂詞.

（1）ClientRedirectsToTencent［］：描述瀏覽器由酷6重定向到騰訊的過程；

（2）UserLogin［］：描述用戶登錄騰訊站點獲得授權(quán)的過程，實際實現(xiàn)中，由2個二選一的謂詞TencentPromptsAuthorization和TencentPromptsAu-thorizationAfterLogin組成，分別表示未登錄與已登錄QQ的情形；

（3）ClientHasAccessToken［］：描述酷6站點獲得授權(quán)碼以及用戶配置數(shù)據(jù)的方式，即騰訊開放平臺所支持的兩種授權(quán)過程，由2個二選一的謂詞ClientGetsServerSideAccessToken和TencentSendsClientSideCode組合而成，分別表示服務(wù)器端模式和客戶端模式.

對于上述的每個謂詞，可以通過run命令檢測其是否存在對應(yīng)的實例.Alloy分析器是在有限范圍內(nèi)搜索滿足限制條件的實例，因此，在運行run命令的時候要指定簽名的個數(shù).例如，運行命令run ClientGetsServerSideAccessToken for 6 but 18 Token，11 Time，10 Event，表示在簽名Token的個數(shù)≤18，Time個數(shù)≤11，Event個數(shù)≤10，其它簽名個數(shù)≤6的范圍內(nèi)搜索滿足謂詞ClientGetsServer-SideAccessToken的實例，其中Token表示授權(quán)交互過程中所需傳遞參數(shù)的名字以及其對應(yīng)的值，Event表示HTTP請求／響應(yīng)，Time表示HTTP請求／響應(yīng)開始和結(jié)束的時間點，可以保證HTTP請求／響應(yīng)是順序進(jìn)行的［8］.

通過Alloy分析器搜索，可以找到滿足上述謂詞的實例，即能找到服務(wù)器端流程的實例，可以直觀地看出酷6站點獲取訪問令牌的過程.

3 騰訊OAuth授權(quán)流程存在的安全威脅

注意到在授權(quán)流程開始時，酷6返回給騰訊的響應(yīng)信息包括：client＿id、redirect＿uri、scope.這些由RP至瀏覽器的信息是通過HTTP傳輸而來并重定向，這使得攻擊者可以通過中間人攻擊，篡改所傳輸?shù)男畔?并不是所有參數(shù)的篡改都起作用.修改client＿id和redirect＿uri會導(dǎo)致騰訊返回錯誤的信息，因為client＿id已經(jīng)是在騰訊注冊過了，并且redirect＿uri是client＿id對應(yīng)主域名下的地址，所以，可以修改的是缺乏完整性保護(hù)的scope［9］.

3.1 Alloy描述攻擊行為

為了能夠描述上述中間人攻擊，定義簽名ProxiedHTTPTransaction，它繼承于簽名HTTPTransaction.ProxiedHTTPTransaction的主要行為就是截獲客戶端發(fā)給用戶的響應(yīng)，并對響應(yīng)進(jìn)行修改后發(fā)給用戶.

為了證明OAuth存在中間人攻擊，可以定義一個斷言（assert），代碼截圖見圖3.

圖3 斷言代碼Fig.3 Code of assert

其中，簽名ProxiedHTTPTransaction描述了中間人攻擊的行為，即攻擊者在不影響整個授權(quán)流程的情況下，修改重定向Location頭中的scope參數(shù)的值，其它參數(shù)的值保持不變，結(jié)果是客戶端的請求訪問范圍scope發(fā)生了變化.在該簽名前面加上關(guān)鍵詞no，表示該斷言基于騰訊OAuth授權(quán)建立的模型不存在上述的中間人攻擊.

最后，通過命令check NoMitmNetworkAttack-Possible for 6 but18 Token對這個斷言進(jìn)行檢測. Alloy分析器找到一個反例，說明這個斷言不成立，服務(wù)器授權(quán)流程存在中間人攻擊.

3.2 攻擊的驗證性實驗

為驗證可能的攻擊行為導(dǎo)致增加或減少客戶端請求授權(quán)項.筆者利用webscrab截獲從酷6發(fā)送到瀏覽器的登錄響應(yīng)，見圖4.

圖5利用webscarab修改授權(quán)信息，筆者修改響應(yīng)參數(shù)里面的授權(quán)項即scope，把它從get＿user＿info改為all，all表示申請騰訊QQ的所有權(quán)限，這就增加了授權(quán)項，修改前的授權(quán)頁面見圖6，修改后的授權(quán)頁面見圖7.

圖4 修改前的HTTP響應(yīng)Fig.4 An HTTP response beforemodification

圖5 修改后的HTTP響應(yīng)Fig.5 An HTTP response aftermodification

圖6 scope＝get＿user＿info的授權(quán)頁Fig.6 An authorization page with scope＝get＿user＿info

圖7 scope＝all的授權(quán)頁Fig.7 An authorization page with scope＝all

通過本實驗可知，使用中間人攻擊修改了授權(quán)請求中scope參數(shù)，使得站點向騰訊QQ申請的權(quán)限增加了讀取、發(fā)表騰訊微博信息的權(quán)限.用戶可能會因為站點所申請的權(quán)限過大過多，而拒絕授予該站點訪問自己在騰訊QQ中資源的權(quán)限，這就直接導(dǎo)致了授權(quán)的失敗.

3.3 分析與討論

社交網(wǎng)站由于擁有大量用戶的參與，可以用作IDP用戶認(rèn)證服務(wù)器，實際上，國內(nèi)的許多社交網(wǎng)站，都基于OAuth構(gòu)造開放平臺提供第三方的認(rèn)證服務(wù).

與騰訊QQ開發(fā)平臺類似，新浪微博將一個最完整的授權(quán)分為3個步驟：登錄－普通授權(quán)－高級授權(quán).當(dāng)用戶的新浪微博帳號處于登錄狀態(tài)時，頁面會自動跳轉(zhuǎn)到普通授權(quán)頁，高級授權(quán)不是必須，如果開發(fā)者不申請scope權(quán)限，系統(tǒng)會自動跳過此步驟，回調(diào)應(yīng)用.由于存在高級授權(quán)頁面，使得授權(quán)項的更改并不能順利進(jìn)行，因為用戶可以在授權(quán)確認(rèn)頁中，對不想授予第三方應(yīng)用的權(quán)限進(jìn)行取消.

通過對開心網(wǎng)開放平臺和人人網(wǎng)開放平臺的測試，表明這2個平臺并沒有出現(xiàn)復(fù)選框要求用戶進(jìn)行勾選的，可以在用戶不察覺的情況下修改授權(quán)項.

筆者注意到需要授權(quán)的網(wǎng)站RP通常通過HTTP協(xié)議向瀏覽器發(fā)出重定向響應(yīng)的，在這響應(yīng)中就包括了第三方應(yīng)用所需申請得到的權(quán)限，使得攻擊者可以修改scope參數(shù).解決的方案可以有①在RP和用戶瀏覽器之間建立HTTPS連接，這就要求RP提供HTTPS服務(wù)；②在RP與IDP的通信中增加驗證scope完整性的流程，這可以使用消息驗證碼來確保關(guān)鍵參數(shù)的完整性［10］.

4 結(jié)束語

本文以通過騰訊開放平臺訪問酷6網(wǎng)站為例，分析OAuth授權(quán)流程，尤其是服務(wù)器授權(quán)流程，并在此模型的基礎(chǔ)上進(jìn)行安全性分析.借助Alloy分析器，對授權(quán)流程可能存在的安全脆弱性進(jìn)行分析和實證檢驗，提出了解決方案.

［1］ RFC 6819-OAuth 2.0［S］.Threatmodel and security considerations tools.ietf.org／html／rfc6819.

［2］ PAIS，SHARMA Y，KUMAR S，etal.Formal verification of OAuth 2.0 using Alloy framework［C］∥In Proceedings of the International Conference on Communication Systems and Network Technologies（CSNT），2011：655-659.

［3］ SLACK Q，F(xiàn)ROSTIG R.OAuth 2.0 implicit grant flow analysis using Murphi［EB／OL］.［2011］http：／／www.stanford. edu／class／cs259／WWW11／，2011.

［4］ CHARIS，JUTLA C，ROY A.Universally composable security analysis of OAuth v2.0［C］∥Cryptology ePrint Archive，Report2011／526，2011.

［5］ SUN ST.Konstantin Beznosov：The devil is in the（implementation）details：An empirical analysis of OAuth SSO systems［C］∥ACM Conference on Computer and Communications Security，2012：378-390.

［6］ JACKSON D.Software abstractions：Logic，language and analysis［M］.Cambridge，Massachusetts London：MIT Press，2006.

［7］ WILSON C，BOE B，SALA A，etal.User interactions in social networks and their implications［C］∥Acm Eurosys，2009.

［8］ BANSAL C，BHARGAVAN K，MAFFEISS.Discovering concrete attack on website authorization by formal analysis［C］∥IEEE Comput Secur Found Sym，2012（25）：247-262.

［9］ MADEJSKIM，JOHNSON M，BELLOVIN SM.A study of privacy settings errors in an online social network［C］∥IEEE Internut Confer Pervas Comput Commun Workshop，2012（10）：340-345.

［10］HU P，YANG R，LIY，etal.Application impersonation：problems of vauth and APIdesign in online social network［C］∥Second Edi Acm Confer Onlin Soc Network，2014（14）：271-278.

On modeling the security of oauth-based authorization

LIN Man-jia，TANG Yi

（School of Mathematics and Information Sciences，Guangzhou University，Guangzhou 510006，China）

Wemodel and analyze the OAuth authorization process based on an open platform instance in China. The analysis is on the combination of protocol specification and real network traces with using the Alloy language.We focus on the addressed security problems.By using the Alloy analyzer，we find a vulnerability that could be exploited to aman-in-the-middle attack.We give a proof of concept exploitation in real applications. We further discuss some other open platformswith similar experiments and propose a solution to this problem.

OAuth protocol；open platform；Alloy language；man-in-the-middle attack

TP 311

A

【責(zé)任編輯：陳 鋼】

1671-4229（2015）03-0059-06

2015－03－20；

2015－04－15

林滿佳（1990－），男，碩士研究生.E-mail：747374803＠qq.com

*通信作者.E-mail：ytang＠gzhu.edu.cn