OAuth授權流程的安全建模研究

林滿佳，唐 屹

（廣州大學數學與信息科學學院，廣東廣州 510006）

OAuth授權流程的安全建模研究

林滿佳，唐 屹*

（廣州大學數學與信息科學學院，廣東廣州 510006）

文章實例分析基于國內開放平臺的OAuth授權流程.結合協議標準與網絡蹤跡，使用Alloy語言對授權流程建模，分析其中的安全問題，利用Alloy分析器找到了可能導致中間人攻擊的漏洞，并實際驗證了這個漏洞.在此基礎上，比較分析了國內其他一些開放平臺的類似問題，提出了解決問題的思路.

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

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

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

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

1 OAuth授權流程及應用實例

1.1 授權流程

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

圖1 服務器端Fig.1 Server-side

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

圖2 客戶端Fig.2 Client-side

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

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

1.2 騰訊OAuth授權流程

以用戶利用其QQ帳號登錄酷6網站來分析騰訊OAuth授權流程.

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

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

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

1.2.2 騰訊驗證用戶的身份

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

1.2.3 酷6獲取授權碼

盡管獲取騰訊訪問令牌的方式有2種，但在筆者的實驗中僅出現服務器端的方式.騰訊的響應將引導瀏覽器重定向到URL：

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

2 基于Alloy的建模分析

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

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

為描述授權過程，定義以下的主要謂詞.

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

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

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

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

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

3 騰訊OAuth授權流程存在的安全威脅

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

3.1 Alloy描述攻擊行為

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

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

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

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

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

3.2 攻擊的驗證性實驗

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

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

圖4 修改前的HTTP響應Fig.4 An HTTP response beforemodification

圖5 修改后的HTTP響應Fig.5 An HTTP response aftermodification

圖6 scope＝get＿user＿info的授權頁Fig.6 An authorization page with scope＝get＿user＿info

圖7 scope＝all的授權頁Fig.7 An authorization page with scope＝all

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

3.3 分析與討論

社交網站由于擁有大量用戶的參與，可以用作IDP用戶認證服務器，實際上，國內的許多社交網站，都基于OAuth構造開放平臺提供第三方的認證服務.

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

通過對開心網開放平臺和人人網開放平臺的測試，表明這2個平臺并沒有出現復選框要求用戶進行勾選的，可以在用戶不察覺的情況下修改授權項.

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

4 結束語

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

［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，FROSTIG 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

【責任編輯：陳 鋼】

1671-4229（2015）03-0059-06

2015－03－20；

2015－04－15

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

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