歐海文 付永亮 于 芋 胡馨月
1(北京電子科技學院 北京 100071) 2(西安電子科技大學 陜西 西安 710071)
一種改進的OAuth授權機制有效性分析
歐海文1,2付永亮2于 芋1胡馨月1
1(北京電子科技學院 北京 100071)2(西安電子科技大學 陜西 西安 710071)
國內微博、微信、百度等開放平臺的出現,使“第三方”認證授權登錄廣泛應用到各個領域,因此,OAuth(Open Authorization)協議作為開放平臺認證授權系統的標準協議而備受關注。眾多研究表明這些開放平臺中現今廣泛使用的OAuth2.0協議在具體的實現過程中,很容易遭受釣魚攻擊、中間人攻擊和CSRF攻擊。為了抵抗網絡中最常見的釣魚攻擊,研究提出通過防止攻擊者偽裝成授權服務器來改進OAuth2.0授權機制的解決方案,并證明了改進授權機制的安全有效性。為OAuth2.0協議的安全性改進提供了借鑒。
OAuth2.0 授權機制 有效性分析 釣魚攻擊
OAuth[1]協議作為國內外開放平臺的主流認證授權協議,其安全性備受國內外研究人員關注,也已經取得了一些研究成果:王煥孝等[2]對OAuth2.0協議規范進行形式化分析,得出通信三方在失去HTTPS保護時,協議存在不安全情況、并給出了攻擊路徑;Pai等[3]利用知識流分析方法在Alloy中建模分析,檢測到攻擊者可以通過代碼反編譯技術竊取存儲在桌面程序的第三方(client端)密鑰,進而利用此密鑰進行偽裝以盜取用戶敏感信息;魏成坤等[4]利用Scyther的對手模型和基于該模型的改進算法,對OAuth2.0協議安全性形式化分析,得出協議中存在的攻擊模式。
以上研究均表明OAuth2.0協議在具體實現過程中存在安全問題,其中,釣魚攻擊、MITM(中間人攻擊)和CSRF(跨站點請求偽造攻擊)是最常見的三種攻擊模式。也有幾種解決方案,比如:引進對客戶端或客戶端的重定向URI嚴格檢驗機制來避免MITM和針對CSRF引入狀態參數。但是,無論是OAuth1.0還是OAuth2.0都不能有效驗證授權服務器的真偽[5]。如果用戶在輸入憑證之前未驗證網站的真實性,那么,攻擊者可利用用戶的疏忽竊取用戶密碼。用戶面臨網絡釣魚攻擊的風險時,如果OAuth系統能夠通知用戶,并且使用戶能夠輕松識別網站的真偽,便可以有效抵制惡意客戶端(第三方應用)發起的網絡釣魚攻擊。不幸的是,這種解決問題的方法很難實現。因為,它要求用戶對HTTP/HTTP方面有足夠多的了解,況且要求用戶對授權頁面要時刻注意。Al-Sinani等[6]提出了一種基于瀏覽器擴展的方式來阻止客戶端直接重定向到授權頁面。然而,由于移動設備的特點,惡意客戶端可以不通過瀏覽器完成授權,所以該方案在移動設備上無法湊效。
為了解決“釣魚”問題,尤其是在瀏覽器和移動設備上的授權服務器的釣魚攻擊,本文提出了一種改進的OAuth2.0授權校驗方案,改進后的授權機制具備很強抵抗釣魚攻擊的功能。而且,改進后的OAuth2.0授權機制不要求用戶具備豐富的安全相關知識。
1.1 OAuth協議簡介
伴隨互聯網發展腳步,網絡技術也逐步邁向成熟。如今的互聯網更像一個大環境,內部之間的協作逐步密切,數據信息開放共享的需求也逐漸迫切,將不同的Web服務整合起來逐漸成為發展過程中的一個必然趨勢。OAuth協議的出現解決了Web服務整合過程中出現的用戶、第三方應用和服務提供方之間在認證授權方面出現的問題。它為用戶在客戶端應用上點擊“第三方”登錄時,能夠訪問存儲的受保護數據信息提供了認證標準,與其他授權協議的區別是:OAuth能在不觸及用戶身份等敏感信息(比如:User_ID和Password)的情況下,允許客戶端應用在授權范圍內訪問該用戶托管在服務器上的保護數據。
OAuth協議的最初版本是OAuth1.0,OAuth2.0是1.0版本的升級,但并不向下兼容,其標準在2012年10月份定稿完成。相比1.0版本的實踐式總結,OAuth2.0更像是一種框架式指引[7]。首先,OAuth2.0舍棄OAuth1.0中的加密算法,依賴HTTPS傳輸來保障安全性。其次,OAuth2.0協議摒棄了OAuth1.0版本中雙Secret(appSecret、tokenSecret)的驗證方式,在訪問受保護資源時,只需提供Access Token無需雙secret加密或者校驗即可完成訪問(類似cookies)。再次,OAuth2.0增加了多場景模式,更能滿足第三方開發者的需求。
1.2 OAuth2.0協議的幾個角色
OAuth2.0協議中的角色定義:
(1) 資源擁有者RO(Resource Owner) :能夠授權保護資源的訪問權限的實體,即:用戶。
(2) 客戶端(Client) :在獲得授權后,能代表用戶請求訪問受保護數據信息的第三方應用。可以是桌面應用、Web應用或者其設備中執行的程序。
(3) 授權服務器AS(Authorization Server):檢測用戶授權信息無誤后,發放訪問令牌給客戶端的服務器。
(4) 資源服務器RS(Resource Server):用戶托管受保護數據信息的服務器。能夠接受客戶端攜帶訪問令牌發起的資源訪問申請,并作出響應。
1.3 OAuth2.0協議工作流程
OAuth2.0流程可以分為以下3步:
(1) 獲取用戶授權;
(2) 發放訪問令牌;
(3) 訪問受保護資源。
OAuth2.0協議中也增加了刷新令牌的操作,文獻[8]給出了具體實現。OAuth2.0協議中的各角色之間的通信抽象流程,如圖1所示。
圖1 OAuth2.0協議抽象流程
(A) 用戶在客戶端應用上點擊“第三方”登錄后,客戶端開始發起授權請求。
(B) 用戶收到客戶端的授權請求后,決定“同意”授權或者“拒絕”響應。
(C) 當用戶授權客戶端響應后,其攜帶用戶的授權信息向AS發出申請訪問令牌(Access Token)的請求。
(D) AS對客戶端進行認證,認證通過后,發放Access Token。
(E) 當獲得Access Token以后,客戶端攜帶Access Token向RS發起受保資源的申請。
(F) RS認證Access Token確認通過后,向客戶端開放用戶許可范圍內的數據信息,整個授權流程至此結束。
1.4 授權許可類型
OAuth2.0中的授權許可(Authorization Grant)代表一種中間憑證,它代表了RO針對客戶端應用獲取目標資源的授權。OAuth2.0定義了如下4種Authorization Grant,體現了授權采用的方式以及Access Token的獲取機制。
(1) 授權碼授權( Authorization Code Grant)。該模式要求:在獲取用于向RS發起訪問受保護數據信息申請時攜帶的Access Token之前,需要先向AS獲得一個與用戶授權信息有關的授權碼。
(2) 隱式授權( Implicit Grant)。它代表一種“隱式”授權方式,即客戶端在取得RO授權的情況下直接獲取Access Token,而不是間接地利用獲取到的授權碼來取得Access Token。
(3) 資源所有者密碼憑證授權( Resource Owner Password Credentials Grant):采用RO的憑證(如:用戶名和密碼)直接作為獲取Access Token的授權方式。該方式要求用戶對客戶端足夠信任。
(4) 客戶端憑證授權( Client Credentials Grant):客戶端應用自身的憑證直接作為它用于獲取Access Token的授權類型。這種類型的授權方式適用于客戶端應用獲取屬于自己的資源,換句話說客戶端應用本身相當于資源的擁有者。
考慮到傳輸層的安全性不僅在抵抗釣魚攻擊,而且在其他安全領域均可保護傳輸數據的隱私,改進的OAuth2.0授權機制依托傳輸層傳輸。
2.1 定 義
描述改進后的OAuth2.0框架之前,我們首先解釋以下框架中額外引進的一些相關實體:
驗證網關(VGateway):是真正的密鑰協商服務器,用于發送驗證信息和接收驗證響應。通過一種通信方法(如SMS或電子郵件)驗證用戶身份,可以有效防止OAuth客戶端被攻擊者“釣魚”。它根據用戶的授權請求隨機生成唯一標識的驗證信息,并向實際持有移動設備或電子郵件地址的用戶發送信息,從而有效避免釣魚頁面竊取用戶名和密碼。在整個系統中起著重要作用。
(1) 信息網關(IGateway):發送驗證信息并接收響應信息的服務器。簡單起見,我們假定IGateway是內部控制、安全可信的。
(2) 驗證客戶端(VClient):實際上是指用戶的移動設備或電子郵箱,它可以從驗證網關接收驗證信息并對其進行響應。
接著,我們描述相關技術術語的若干定義:
(1) 證書(Credentials):它是由唯一數字標識和匹配共享密鑰組合的一對隨機碼。
(2) 令牌(Token):服務器發出的唯一標識符。 它是授權客戶端訪問RS上受保護資源的訪問憑證。
(3) 用戶憑據(User credentials):是用于服務器唯一地標識User并驗證User真實性的數據集。通常由用戶信息(用戶名或用戶代理)和一些安全算法驗證信息生成。
(4) 客戶端憑據(Client credentials):指的是client_key和client_secret。
(5) 臨時憑證(Temporary credentials):它引用請求令牌和密鑰。
(6) 令牌憑據(Token credentials):指的是訪問令牌和密鑰。
2.2 改進機制在原OAuth2.0協議上的改進
改進OAuth2.0協議與原OAuth2.0協議相比,包括:用戶憑證的體系結構和生成過程均不相同,兩處改進分別利用了三方協商和OTP(動態口令)。因此,用戶可以避免泄露存儲在RS上的密碼。OTP是加密系統中廣泛使用的加密機制。在OTP中,明文與一次性填充相配對,并且每個位與來自填充的相應位一起加密。 如果密鑰設計得好,將很難解密。
2.2.1 OAuth2.0授權的改進架構
項目的主程序在Android應用程序、iOS應用程序、Web服務器和后端API服務器(包括AS和RS)上運行。 為了簡單起見,將移動設備或網絡瀏覽器視為OAuth客戶端,用戶訪問云服務器上的資源必須對設備或瀏覽器授權。 然后,構建一個SMS網關作為驗證網關。該項目的設計圖如圖2所示。
圖2 系統架構圖
首先,用戶通過客戶端向RS提交數據信息訪問的申請。接著,RS收到請求后向AS發出對授權信息的驗證請求。然后,AS向驗證網關(SMSGateway)發起用戶身份的校驗請求。驗證網關通過發送驗證信息(驗證碼或驗證鏈接)來完成對用戶身份的識別,只有通過了對用戶身份的校驗后客戶端應用才能獲得用戶授權,進而能夠獲得用戶的數據信息。其中,SMSGateway驗證模塊是改進OAuth2.0授權機制新增模塊。
基于三方協商的思想,引入驗證系統作為可信第三方,用戶和AS可以在其中彼此驗證。驗證系統由三個重要部分組成:VGateway、IGateway(SMS或Email)和VClient,具體實現如圖3所示。
圖3 驗證系統
首先,收到驗證請求后,VGateway會生成驗證信息,并通知IGateway通過短信或電子郵件發送驗證信息。
其次,由于是基于識別性更高的短信號碼和電子郵件,用戶收到驗證短信或電子郵件后,可以從AS簡單確認。
最后,用戶完成信息驗證操作后,VGateway可以檢測用戶真實身份并生成用戶憑證以請求AS完成授權。
2.2.2 用戶憑證的生成
另一個重要的改進是:生成不可預測的驗證消息和用戶憑證的方式。在原OAuth2.0協議中,用戶憑證是指提前在服務提供商中注冊的User_ID和Password。改進后的OAuth2.0授權機制,使用OTP機制生成驗證信息和用戶憑證。
首先,VGateway確認在請求驗證信息時得到的唯一的User_ID和用戶手機號碼或電子郵件。然后,它生成包含一些不可預測值的驗證消息發送給用戶。用戶通過特殊指令(返回或提交該不可預測值)做出驗證信息響應。最后,VGateway會自動生成不可預知的密碼,此密碼不需要記。
主要步驟描述如下:
(1) 生成User_ID:User_ID=F1(用戶注冊信息)。其中,函數F1應當滿足以下條件:
① 將用戶注冊信息(如:用戶名、電話號碼、電子郵箱,等)映射到唯一的字符串。
② 已知User_ID的情況下,難以反推出用戶注冊信息。
(2) 生成User_PW:User_PW=F2(VR,User_ID)。其中,函數F2應當滿足:
① 生成一個能夠映射到VR和User_ID的唯一字符串;
② 已知User_PW的情況下,難以反推出VR。
F2有兩個參數:VR表示驗證響應消息,這是在收到驗證信息后用戶對VGateway的響應;User_ID是函數F1的作用結果。
(3) 向AS發送User_ID和User_PW。
(4) AS存儲用戶憑證。
2.3 改進OAuth2.0授權的詳細過程
與原OAuth2.0協議過程的區別是:改進后的OAuth2.0授權機制在三次交互的基礎上引入了額外的第三方密鑰協商和傳遞機制。協議流程如圖4所示。
具體步驟如下:
(1) OAuth客戶端通過自身憑證向AS請求臨時憑據。
(2) 接收到請求后,AS會檢查OAuth客戶端的請求是否合法。如果,驗證通過,則AS返回臨時憑據。否則,返回錯誤信息。
(3) 獲取臨時憑據后,OAuth客戶端攜帶臨時憑據向AS請求OAuth驗證程序(通常是PIN碼)。
(4) 在接收到請求后,AS檢查臨時憑證,并向用戶回復一個回調URI。
(5) 用戶輸入一些注冊信息(密碼和私密信息除外),并提交給回調URI。
(6) 在接收到可以唯一標識用戶的注冊信息后,AS請求VGateway向用戶的驗證客戶端(VClient)發送驗證信息。
(7) 驗證響應:用戶根據接收到的驗證信息來完成驗證操作(例如輸入驗證碼,點擊驗證鏈接等)。
(8) VGateway通過用戶對驗證信息的響應生成用戶憑據,并將其發送至AS。
(9) AS生成OAuth_Verifier并將其響應到OAuth客戶端。
(10) OAuth客戶端通過OAuth驗證程序向AS請求Token憑據。
(11) AS檢查OAuth驗證器,生成令牌憑據并將其發送到OAuth客戶端,OAuth客戶端獲取令牌憑據并存儲。
(12) 授權完成。
接下來我們對改進OAuth2.0授權機制提出的解決方案的有效性進行評估。在與原OAuth2.0協議的對比中,對改進授權機制針對網絡釣魚攻擊的安全特性做出描述。
3.1 抵抗釣魚攻擊的安全功能
在原OAuth2.0協議安全性基礎上,改進后的OAuth2.0授權機制增強了針對釣魚攻擊的安全特性。本文重點介紹抵抗釣魚攻擊的安全能力,而不是RFC 6819[9]中討論的其他安全問題。
3.1.1 驗證信息
驗證信息用于檢測和防止惡意客戶端應用的攻擊。例如,釣魚攻擊的典型情況是攻擊者欺騙用戶相信網絡“釣魚者”是客戶端或授權服務器。在原OAuth2.0協議中,信息顯示在授權頁面,但是,改進OAuth2.0授權機制通過VGateway發送驗證信息的功能,用戶可以更簡單地識別。如果,攻擊者偽造驗證消息,真實的VGateway將攔截驗證響應。同時,由于驗證信息中含有不可預測值,攻擊者不能通過枚舉的方式來獲得驗證消息。
3.1.2 驗證響應
驗證響應幫助AS防止用戶憑據遭受釣魚攻擊而被盜。驗證消息與驗證響應相一致,且每次都不同,因此,由VGateway生成的用戶憑據是動態的。與原OAuth2.0協議相比,OTP機制的引入使攻擊者進行釣魚攻擊的難度大大增加。
3.1.3 可信的三方協商
由用戶、VGateway和AS組成了相互信任的三方密鑰協商組。用戶在授權過程中不直接與AS交互,用戶憑證由用戶和VGateway中的驗證響應結果生成,并發送到AS。 如果任一方不被信賴,該過程將被終止。
3.2 抵抗網絡釣魚攻擊的措施
下面介紹了改進后的OAuth2.0授權機制針對網絡釣魚攻擊模式的改進,并證明了對策的有效性。
3.2.1 假冒AS
這是最常見且易于實施的網上誘騙,原OAuth2.0協議無法正確處理。惡意客戶端可能會誘騙用戶在偽造授權頁中輸入用戶憑據,從而竊取用戶密碼或其他私密信息。改進OAuth2.0授權機制的對策如下:
(1) 由三方協商組(VGateway、用戶和AS)生成密鑰(驗證信息、驗證響應和用戶憑證)的機制,使得授權的三個部分彼此可信。由于假冒的AS對VGateway而言不可信,所以攻擊會失敗。
(2) 由于OTP機制的存在使得盜取密鑰沒有任何意義,并且,重要的驗證消息在用戶和VGateway之間進行交互。
3.2.2 假冒VGateway
VGateway是文中改進OAuth2.0授權機制中介紹的一個新角色,其安全性也至關重要。如果假冒VGateway能夠湊效,那么攻擊者可以通過用戶或盜取用戶憑證來獲取驗證響應。
改進OAuth2.0授權機制的對策如下:
(1) 驗證消息的不可預測性使得枚舉很困難。錯誤的驗證信息導致錯誤的用戶憑證,AS無法驗證通過。
(2) 攻擊者不能夠反推出F2函數。
(3) AS拒絕接收來自不在白名單范圍內的VGateway請求。
3.2.3 釣取用戶注冊信息
原OAuth2.0授權方式中,攻擊者可以通過釣魚攻擊使用偽造的回調URI來釣取用戶的注冊信息(例如電話號碼和其他敏感信息),也可以從其他攻擊模型中獲得。
改進OAuth2.0授權機制的對策如下:
(1) 用戶提交給回調URI的注冊信息不應該是敏感信息,必須避免輸入密碼。
(2) 攻擊者不能反推出函數F1和F2。
3.2.4 釣取用戶憑證
惡意應用程序可能會通過在最終的用戶授權過程中濫用嵌入式瀏覽器,或者通過呈現自己的用戶界面,而不是受信任的瀏覽器系統呈現用戶授權界面,來嘗試盜取用戶憑證。一旦攻擊者獲得用戶憑證,就可以獲得資源所有者存儲的敏感資源。
改進OAuth2.0授權機制的對策如下:
(1) 對于AS或任何請求響應的真實性問題,使用傳輸層的安全特性來解決。
(2) 用戶憑證依靠VGateway中的OTP動態生成,并發送到AS。該過程發生在服務提供程序中,因此,攻擊者很難釣取到用戶憑據。
本文通過防止攻擊者偽裝成授權服務器來改進OAuth2.0授權機制以解決釣魚攻擊問題。改進后的授權機制引入OTP和三方協商的方式,使得攻擊者很難通過網絡瀏覽器或移動設備進行釣魚攻擊。而且,為避免原始密碼被盜,改進的OAuth2.0授權機制還引入了VGateway來安全生成用戶憑證。本文還對改進OAuth2.0授權機制的有效性進行了理論方面的評估。
在以后的工作中,我們可以嘗試借助模型檢測工具來對改進的OAuth2.0授權進行建模分析。另外,也可以嘗試針對OAuth2.0協議在實現過程中存在的其他類型攻擊研究改善方案,從而達到進一步完善OAuth2.0認證授權系統的目的。
[1] 劉大紅,劉明.第三方應用與開放平臺OAuth認證互連技術研究[J].電腦知識與技術,2012,8(22):5367-5369.
[2] 王煥孝,顧純祥,鄭永輝.開放授權協議OAuth2.0的安全性形式化分析[J].信息工程大學學報,2014,15(2):141-147.
[3] Pai S,Sharma Y,Kumar S,et al.Formal Verification of OAuth 2.0 Using Alloy Framework[C]//International Conference on Communication Systems and Network Technologies.IEEE,2011:655-659.
[4] 魏成坤,劉向東,石兆軍.OAuth2.0協議的安全性形式化分析[J].計算機工程與設計,2016,37(7):1746-1751.
[5] Hardt D.The OAuth 2.0 authorization framework[EB/OL].[2013-02].http://tools.ietf.org/html/draft-ietf-oauth-v2-31.
[6] Al-Sinani H S.Browser Extension-based Interoperation Between OAuth and Information Card-based Systems[D].Royal Holloway,University of London,2011.
[7] Bansal C,Bhargavan K,Maffeis S.Discovering Concrete Attacks on Website Authorization by Formal Analysis[C]//IEEE,Computer Security Foundations Symposium.IEEE Computer Society,2012:247-262.
[8] 時子慶,劉金蘭,譚曉華.基于OAuth2.0的認證授權技術[J].計算機系統應用,2012,21(3):260-264.
[9] Lodderstedt T.OAuth 2.0 Threat Model and Security Considerations[J/OL].2013.http://tools.ietf.org/html/rfc6819.
VALIDITYANALYSISOFANIMPROVEDOAUTHAUTHORIZATIONMECHANISM
Ou Haiwen1,2Fu Yongliang2Yu Yu1Hu Xinyue1
1(BeijingElectronicScienceandTechnologyInstitute,Beijing100071,China)2(XidianUniversity,Xi’an710071,Shaanxi,China)
Third party authentication and authorization login mode has been applied to MicroBlog, WeChat, Baidu and other open platform. As a result, this login mechanism is widely used in various fields of our country. Therefore, the OAuth protocol as a standard protocol of the open platform for authentication and authorization system is closely watched. Many researches show that the OAuth2.0 protocol, which is widely used in these open platforms, is vulnerable to phishing attacks, man-in-the-middle attacks and CSRF attacks during the implementation. In order to resist the most common phishing attacks in the network, this paper proposes a solution to improve the OAuth2.0 authorization mechanism by preventing the attacker from masquerading as an authorization server, and proving the security and effectiveness of the improved authorization mechanism. It provides a reference for the security improvement of OAuth2.0 protocol.
OAuth2.0 Authentication mechanism Validity analysis Phishing attack
2016-12-21。歐海文,教授,主研領域:密碼編碼與應用技術。付永亮,碩士生。于芋,碩士生。胡馨月,碩士生。
TP393.02
A
10.3969/j.issn.1000-386x.2017.12.037