歐海文 付永亮 于 芋 胡馨月

1(北京電子科技學(xué)院 北京 100071) 2(西安電子科技大學(xué) 陜西 西安 710071)

一種改進(jìn)的OAuth授權(quán)機(jī)制有效性分析

歐海文1,2付永亮2于 芋1胡馨月1

1(北京電子科技學(xué)院 北京 100071)2(西安電子科技大學(xué) 陜西 西安 710071)

國(guó)內(nèi)微博、微信、百度等開放平臺(tái)的出現(xiàn)，使“第三方”認(rèn)證授權(quán)登錄廣泛應(yīng)用到各個(gè)領(lǐng)域，因此，OAuth(Open Authorization)協(xié)議作為開放平臺(tái)認(rèn)證授權(quán)系統(tǒng)的標(biāo)準(zhǔn)協(xié)議而備受關(guān)注。眾多研究表明這些開放平臺(tái)中現(xiàn)今廣泛使用的OAuth2.0協(xié)議在具體的實(shí)現(xiàn)過程中，很容易遭受釣魚攻擊、中間人攻擊和CSRF攻擊。為了抵抗網(wǎng)絡(luò)中最常見的釣魚攻擊，研究提出通過防止攻擊者偽裝成授權(quán)服務(wù)器來改進(jìn)OAuth2.0授權(quán)機(jī)制的解決方案，并證明了改進(jìn)授權(quán)機(jī)制的安全有效性。為OAuth2.0協(xié)議的安全性改進(jìn)提供了借鑒。

OAuth2.0 授權(quán)機(jī)制 有效性分析 釣魚攻擊

0 引 言

OAuth[1]協(xié)議作為國(guó)內(nèi)外開放平臺(tái)的主流認(rèn)證授權(quán)協(xié)議，其安全性備受國(guó)內(nèi)外研究人員關(guān)注，也已經(jīng)取得了一些研究成果：王煥孝等[2]對(duì)OAuth2.0協(xié)議規(guī)范進(jìn)行形式化分析，得出通信三方在失去HTTPS保護(hù)時(shí)，協(xié)議存在不安全情況、并給出了攻擊路徑；Pai等[3]利用知識(shí)流分析方法在Alloy中建模分析，檢測(cè)到攻擊者可以通過代碼反編譯技術(shù)竊取存儲(chǔ)在桌面程序的第三方(client端)密鑰，進(jìn)而利用此密鑰進(jìn)行偽裝以盜取用戶敏感信息；魏成坤等[4]利用Scyther的對(duì)手模型和基于該模型的改進(jìn)算法，對(duì)OAuth2.0協(xié)議安全性形式化分析，得出協(xié)議中存在的攻擊模式。

以上研究均表明OAuth2.0協(xié)議在具體實(shí)現(xiàn)過程中存在安全問題，其中，釣魚攻擊、MITM(中間人攻擊)和CSRF(跨站點(diǎn)請(qǐng)求偽造攻擊)是最常見的三種攻擊模式。也有幾種解決方案，比如：引進(jìn)對(duì)客戶端或客戶端的重定向URI嚴(yán)格檢驗(yàn)機(jī)制來避免MITM和針對(duì)CSRF引入狀態(tài)參數(shù)。但是，無論是OAuth1.0還是OAuth2.0都不能有效驗(yàn)證授權(quán)服務(wù)器的真?zhèn)蝃5]。如果用戶在輸入憑證之前未驗(yàn)證網(wǎng)站的真實(shí)性，那么，攻擊者可利用用戶的疏忽竊取用戶密碼。用戶面臨網(wǎng)絡(luò)釣魚攻擊的風(fēng)險(xiǎn)時(shí)，如果OAuth系統(tǒng)能夠通知用戶，并且使用戶能夠輕松識(shí)別網(wǎng)站的真?zhèn)?，便可以有效抵制惡意客戶?第三方應(yīng)用)發(fā)起的網(wǎng)絡(luò)釣魚攻擊。不幸的是，這種解決問題的方法很難實(shí)現(xiàn)。因?yàn)?，它要求用戶?duì)HTTP/HTTP方面有足夠多的了解，況且要求用戶對(duì)授權(quán)頁面要時(shí)刻注意。Al-Sinani等[6]提出了一種基于瀏覽器擴(kuò)展的方式來阻止客戶端直接重定向到授權(quán)頁面。然而，由于移動(dòng)設(shè)備的特點(diǎn)，惡意客戶端可以不通過瀏覽器完成授權(quán)，所以該方案在移動(dòng)設(shè)備上無法湊效。

為了解決“釣魚”問題，尤其是在瀏覽器和移動(dòng)設(shè)備上的授權(quán)服務(wù)器的釣魚攻擊，本文提出了一種改進(jìn)的OAuth2.0授權(quán)校驗(yàn)方案，改進(jìn)后的授權(quán)機(jī)制具備很強(qiáng)抵抗釣魚攻擊的功能。而且，改進(jìn)后的OAuth2.0授權(quán)機(jī)制不要求用戶具備豐富的安全相關(guān)知識(shí)。

1 背 景

1.1 OAuth協(xié)議簡(jiǎn)介

伴隨互聯(lián)網(wǎng)發(fā)展腳步，網(wǎng)絡(luò)技術(shù)也逐步邁向成熟。如今的互聯(lián)網(wǎng)更像一個(gè)大環(huán)境，內(nèi)部之間的協(xié)作逐步密切，數(shù)據(jù)信息開放共享的需求也逐漸迫切，將不同的Web服務(wù)整合起來逐漸成為發(fā)展過程中的一個(gè)必然趨勢(shì)。OAuth協(xié)議的出現(xiàn)解決了Web服務(wù)整合過程中出現(xiàn)的用戶、第三方應(yīng)用和服務(wù)提供方之間在認(rèn)證授權(quán)方面出現(xiàn)的問題。它為用戶在客戶端應(yīng)用上點(diǎn)擊“第三方”登錄時(shí)，能夠訪問存儲(chǔ)的受保護(hù)數(shù)據(jù)信息提供了認(rèn)證標(biāo)準(zhǔn)，與其他授權(quán)協(xié)議的區(qū)別是：OAuth能在不觸及用戶身份等敏感信息(比如：User_ID和Password)的情況下，允許客戶端應(yīng)用在授權(quán)范圍內(nèi)訪問該用戶托管在服務(wù)器上的保護(hù)數(shù)據(jù)。

OAuth協(xié)議的最初版本是OAuth1.0，OAuth2.0是1.0版本的升級(jí)，但并不向下兼容，其標(biāo)準(zhǔn)在2012年10月份定稿完成。相比1.0版本的實(shí)踐式總結(jié)，OAuth2.0更像是一種框架式指引[7]。首先，OAuth2.0舍棄OAuth1.0中的加密算法，依賴HTTPS傳輸來保障安全性。其次，OAuth2.0協(xié)議摒棄了OAuth1.0版本中雙Secret(appSecret、tokenSecret)的驗(yàn)證方式，在訪問受保護(hù)資源時(shí)，只需提供Access Token無需雙secret加密或者校驗(yàn)即可完成訪問(類似cookies)。再次,OAuth2.0增加了多場(chǎng)景模式，更能滿足第三方開發(fā)者的需求。

1.2 OAuth2.0協(xié)議的幾個(gè)角色

OAuth2.0協(xié)議中的角色定義：

(1) 資源擁有者RO(Resource Owner) ：能夠授權(quán)保護(hù)資源的訪問權(quán)限的實(shí)體，即：用戶。

(2) 客戶端(Client) ：在獲得授權(quán)后，能代表用戶請(qǐng)求訪問受保護(hù)數(shù)據(jù)信息的第三方應(yīng)用?？梢允亲烂鎽?yīng)用、Web應(yīng)用或者其設(shè)備中執(zhí)行的程序。

(3) 授權(quán)服務(wù)器AS(Authorization Server)：檢測(cè)用戶授權(quán)信息無誤后，發(fā)放訪問令牌給客戶端的服務(wù)器。

(4) 資源服務(wù)器RS(Resource Server)：用戶托管受保護(hù)數(shù)據(jù)信息的服務(wù)器。能夠接受客戶端攜帶訪問令牌發(fā)起的資源訪問申請(qǐng)，并作出響應(yīng)。

1.3 OAuth2.0協(xié)議工作流程

OAuth2.0流程可以分為以下3步：

(1) 獲取用戶授權(quán)；

(2) 發(fā)放訪問令牌；

(3) 訪問受保護(hù)資源。

OAuth2.0協(xié)議中也增加了刷新令牌的操作，文獻(xiàn)[8]給出了具體實(shí)現(xiàn)。OAuth2.0協(xié)議中的各角色之間的通信抽象流程，如圖1所示。

圖1 OAuth2.0協(xié)議抽象流程

(A) 用戶在客戶端應(yīng)用上點(diǎn)擊“第三方”登錄后，客戶端開始發(fā)起授權(quán)請(qǐng)求。

(B) 用戶收到客戶端的授權(quán)請(qǐng)求后，決定“同意”授權(quán)或者“拒絕”響應(yīng)。

(C) 當(dāng)用戶授權(quán)客戶端響應(yīng)后，其攜帶用戶的授權(quán)信息向AS發(fā)出申請(qǐng)?jiān)L問令牌(Access Token)的請(qǐng)求。

(D) AS對(duì)客戶端進(jìn)行認(rèn)證，認(rèn)證通過后，發(fā)放Access Token。

(E) 當(dāng)獲得Access Token以后，客戶端攜帶Access Token向RS發(fā)起受保資源的申請(qǐng)。

(F) RS認(rèn)證Access Token確認(rèn)通過后，向客戶端開放用戶許可范圍內(nèi)的數(shù)據(jù)信息，整個(gè)授權(quán)流程至此結(jié)束。

1.4 授權(quán)許可類型

OAuth2.0中的授權(quán)許可(Authorization Grant)代表一種中間憑證，它代表了RO針對(duì)客戶端應(yīng)用獲取目標(biāo)資源的授權(quán)。OAuth2.0定義了如下4種Authorization Grant，體現(xiàn)了授權(quán)采用的方式以及Access Token的獲取機(jī)制。

(1) 授權(quán)碼授權(quán)( Authorization Code Grant)。該模式要求：在獲取用于向RS發(fā)起訪問受保護(hù)數(shù)據(jù)信息申請(qǐng)時(shí)攜帶的Access Token之前，需要先向AS獲得一個(gè)與用戶授權(quán)信息有關(guān)的授權(quán)碼。

(2) 隱式授權(quán)( Implicit Grant)。它代表一種“隱式”授權(quán)方式，即客戶端在取得RO授權(quán)的情況下直接獲取Access Token，而不是間接地利用獲取到的授權(quán)碼來取得Access Token。

(3) 資源所有者密碼憑證授權(quán)( Resource Owner Password Credentials Grant)：采用RO的憑證(如：用戶名和密碼)直接作為獲取Access Token的授權(quán)方式。該方式要求用戶對(duì)客戶端足夠信任。

(4) 客戶端憑證授權(quán)( Client Credentials Grant)：客戶端應(yīng)用自身的憑證直接作為它用于獲取Access Token的授權(quán)類型。這種類型的授權(quán)方式適用于客戶端應(yīng)用獲取屬于自己的資源，換句話說客戶端應(yīng)用本身相當(dāng)于資源的擁有者。

2 改進(jìn)OAuth2.0授權(quán)機(jī)制的描述

考慮到傳輸層的安全性不僅在抵抗釣魚攻擊，而且在其他安全領(lǐng)域均可保護(hù)傳輸數(shù)據(jù)的隱私，改進(jìn)的OAuth2.0授權(quán)機(jī)制依托傳輸層傳輸。

2.1 定 義

描述改進(jìn)后的OAuth2.0框架之前，我們首先解釋以下框架中額外引進(jìn)的一些相關(guān)實(shí)體：

驗(yàn)證網(wǎng)關(guān)(VGateway)：是真正的密鑰協(xié)商服務(wù)器，用于發(fā)送驗(yàn)證信息和接收驗(yàn)證響應(yīng)。通過一種通信方法(如SMS或電子郵件)驗(yàn)證用戶身份，可以有效防止OAuth客戶端被攻擊者“釣魚”。它根據(jù)用戶的授權(quán)請(qǐng)求隨機(jī)生成唯一標(biāo)識(shí)的驗(yàn)證信息，并向?qū)嶋H持有移動(dòng)設(shè)備或電子郵件地址的用戶發(fā)送信息，從而有效避免釣魚頁面竊取用戶名和密碼。在整個(gè)系統(tǒng)中起著重要作用。

(1) 信息網(wǎng)關(guān)(IGateway):發(fā)送驗(yàn)證信息并接收響應(yīng)信息的服務(wù)器。簡(jiǎn)單起見，我們假定IGateway是內(nèi)部控制、安全可信的。

(2) 驗(yàn)證客戶端(VClient):實(shí)際上是指用戶的移動(dòng)設(shè)備或電子郵箱，它可以從驗(yàn)證網(wǎng)關(guān)接收驗(yàn)證信息并對(duì)其進(jìn)行響應(yīng)。

接著，我們描述相關(guān)技術(shù)術(shù)語的若干定義：

(1) 證書(Credentials):它是由唯一數(shù)字標(biāo)識(shí)和匹配共享密鑰組合的一對(duì)隨機(jī)碼。

(2) 令牌(Token):服務(wù)器發(fā)出的唯一標(biāo)識(shí)符。 它是授權(quán)客戶端訪問RS上受保護(hù)資源的訪問憑證。

(3) 用戶憑據(jù)(User credentials):是用于服務(wù)器唯一地標(biāo)識(shí)User并驗(yàn)證User真實(shí)性的數(shù)據(jù)集。通常由用戶信息(用戶名或用戶代理)和一些安全算法驗(yàn)證信息生成。

(4) 客戶端憑據(jù)(Client credentials):指的是client_key和client_secret。

(5) 臨時(shí)憑證(Temporary credentials):它引用請(qǐng)求令牌和密鑰。

(6) 令牌憑據(jù)(Token credentials):指的是訪問令牌和密鑰。

2.2 改進(jìn)機(jī)制在原OAuth2.0協(xié)議上的改進(jìn)

改進(jìn)OAuth2.0協(xié)議與原OAuth2.0協(xié)議相比，包括：用戶憑證的體系結(jié)構(gòu)和生成過程均不相同，兩處改進(jìn)分別利用了三方協(xié)商和OTP(動(dòng)態(tài)口令)。因此，用戶可以避免泄露存儲(chǔ)在RS上的密碼。OTP是加密系統(tǒng)中廣泛使用的加密機(jī)制。在OTP中，明文與一次性填充相配對(duì)，并且每個(gè)位與來自填充的相應(yīng)位一起加密。 如果密鑰設(shè)計(jì)得好，將很難解密。

2.2.1 OAuth2.0授權(quán)的改進(jìn)架構(gòu)

項(xiàng)目的主程序在Android應(yīng)用程序、iOS應(yīng)用程序、Web服務(wù)器和后端API服務(wù)器(包括AS和RS)上運(yùn)行。 為了簡(jiǎn)單起見，將移動(dòng)設(shè)備或網(wǎng)絡(luò)瀏覽器視為OAuth客戶端，用戶訪問云服務(wù)器上的資源必須對(duì)設(shè)備或?yàn)g覽器授權(quán)。 然后，構(gòu)建一個(gè)SMS網(wǎng)關(guān)作為驗(yàn)證網(wǎng)關(guān)。該項(xiàng)目的設(shè)計(jì)圖如圖2所示。

圖2 系統(tǒng)架構(gòu)圖

首先，用戶通過客戶端向RS提交數(shù)據(jù)信息訪問的申請(qǐng)。接著，RS收到請(qǐng)求后向AS發(fā)出對(duì)授權(quán)信息的驗(yàn)證請(qǐng)求。然后，AS向驗(yàn)證網(wǎng)關(guān)(SMSGateway)發(fā)起用戶身份的校驗(yàn)請(qǐng)求。驗(yàn)證網(wǎng)關(guān)通過發(fā)送驗(yàn)證信息(驗(yàn)證碼或驗(yàn)證鏈接)來完成對(duì)用戶身份的識(shí)別，只有通過了對(duì)用戶身份的校驗(yàn)后客戶端應(yīng)用才能獲得用戶授權(quán)，進(jìn)而能夠獲得用戶的數(shù)據(jù)信息。其中，SMSGateway驗(yàn)證模塊是改進(jìn)OAuth2.0授權(quán)機(jī)制新增模塊。

基于三方協(xié)商的思想，引入驗(yàn)證系統(tǒng)作為可信第三方，用戶和AS可以在其中彼此驗(yàn)證。驗(yàn)證系統(tǒng)由三個(gè)重要部分組成：VGateway、IGateway(SMS或Email)和VClient，具體實(shí)現(xiàn)如圖3所示。

圖3 驗(yàn)證系統(tǒng)

首先，收到驗(yàn)證請(qǐng)求后，VGateway會(huì)生成驗(yàn)證信息，并通知IGateway通過短信或電子郵件發(fā)送驗(yàn)證信息。

其次，由于是基于識(shí)別性更高的短信號(hào)碼和電子郵件，用戶收到驗(yàn)證短信或電子郵件后，可以從AS簡(jiǎn)單確認(rèn)。

最后，用戶完成信息驗(yàn)證操作后，VGateway可以檢測(cè)用戶真實(shí)身份并生成用戶憑證以請(qǐng)求AS完成授權(quán)。

2.2.2 用戶憑證的生成

另一個(gè)重要的改進(jìn)是：生成不可預(yù)測(cè)的驗(yàn)證消息和用戶憑證的方式。在原OAuth2.0協(xié)議中，用戶憑證是指提前在服務(wù)提供商中注冊(cè)的User_ID和Password。改進(jìn)后的OAuth2.0授權(quán)機(jī)制，使用OTP機(jī)制生成驗(yàn)證信息和用戶憑證。

首先，VGateway確認(rèn)在請(qǐng)求驗(yàn)證信息時(shí)得到的唯一的User_ID和用戶手機(jī)號(hào)碼或電子郵件。然后，它生成包含一些不可預(yù)測(cè)值的驗(yàn)證消息發(fā)送給用戶。用戶通過特殊指令(返回或提交該不可預(yù)測(cè)值)做出驗(yàn)證信息響應(yīng)。最后，VGateway會(huì)自動(dòng)生成不可預(yù)知的密碼，此密碼不需要記。

主要步驟描述如下：

(1) 生成User_ID：User_ID=F1(用戶注冊(cè)信息)。其中，函數(shù)F1應(yīng)當(dāng)滿足以下條件：

① 將用戶注冊(cè)信息(如：用戶名、電話號(hào)碼、電子郵箱，等)映射到唯一的字符串。

② 已知User_ID的情況下，難以反推出用戶注冊(cè)信息。

(2) 生成User_PW：User_PW=F2(VR,User_ID)。其中，函數(shù)F2應(yīng)當(dāng)滿足：

① 生成一個(gè)能夠映射到VR和User_ID的唯一字符串；

② 已知User_PW的情況下，難以反推出VR。

F2有兩個(gè)參數(shù)：VR表示驗(yàn)證響應(yīng)消息，這是在收到驗(yàn)證信息后用戶對(duì)VGateway的響應(yīng)；User_ID是函數(shù)F1的作用結(jié)果。

(3) 向AS發(fā)送User_ID和User_PW。

(4) AS存儲(chǔ)用戶憑證。

2.3 改進(jìn)OAuth2.0授權(quán)的詳細(xì)過程

與原OAuth2.0協(xié)議過程的區(qū)別是：改進(jìn)后的OAuth2.0授權(quán)機(jī)制在三次交互的基礎(chǔ)上引入了額外的第三方密鑰協(xié)商和傳遞機(jī)制。協(xié)議流程如圖4所示。

具體步驟如下：

(1) OAuth客戶端通過自身憑證向AS請(qǐng)求臨時(shí)憑據(jù)。

(2) 接收到請(qǐng)求后，AS會(huì)檢查OAuth客戶端的請(qǐng)求是否合法。如果，驗(yàn)證通過，則AS返回臨時(shí)憑據(jù)。否則，返回錯(cuò)誤信息。

(3) 獲取臨時(shí)憑據(jù)后，OAuth客戶端攜帶臨時(shí)憑據(jù)向AS請(qǐng)求OAuth驗(yàn)證程序(通常是PIN碼)。

(4) 在接收到請(qǐng)求后，AS檢查臨時(shí)憑證，并向用戶回復(fù)一個(gè)回調(diào)URI。

(5) 用戶輸入一些注冊(cè)信息(密碼和私密信息除外)，并提交給回調(diào)URI。

(6) 在接收到可以唯一標(biāo)識(shí)用戶的注冊(cè)信息后，AS請(qǐng)求VGateway向用戶的驗(yàn)證客戶端(VClient)發(fā)送驗(yàn)證信息。

(7) 驗(yàn)證響應(yīng)：用戶根據(jù)接收到的驗(yàn)證信息來完成驗(yàn)證操作(例如輸入驗(yàn)證碼，點(diǎn)擊驗(yàn)證鏈接等)。

(8) VGateway通過用戶對(duì)驗(yàn)證信息的響應(yīng)生成用戶憑據(jù)，并將其發(fā)送至AS。

(9) AS生成OAuth_Verifier并將其響應(yīng)到OAuth客戶端。

(10) OAuth客戶端通過OAuth驗(yàn)證程序向AS請(qǐng)求Token憑據(jù)。

(11) AS檢查OAuth驗(yàn)證器，生成令牌憑據(jù)并將其發(fā)送到OAuth客戶端，OAuth客戶端獲取令牌憑據(jù)并存儲(chǔ)。

(12) 授權(quán)完成。

3 改進(jìn)OAuth2.0授權(quán)有效性評(píng)估

接下來我們對(duì)改進(jìn)OAuth2.0授權(quán)機(jī)制提出的解決方案的有效性進(jìn)行評(píng)估。在與原OAuth2.0協(xié)議的對(duì)比中，對(duì)改進(jìn)授權(quán)機(jī)制針對(duì)網(wǎng)絡(luò)釣魚攻擊的安全特性做出描述。

3.1 抵抗釣魚攻擊的安全功能

在原OAuth2.0協(xié)議安全性基礎(chǔ)上，改進(jìn)后的OAuth2.0授權(quán)機(jī)制增強(qiáng)了針對(duì)釣魚攻擊的安全特性。本文重點(diǎn)介紹抵抗釣魚攻擊的安全能力，而不是RFC 6819[9]中討論的其他安全問題。

3.1.1 驗(yàn)證信息

驗(yàn)證信息用于檢測(cè)和防止惡意客戶端應(yīng)用的攻擊。例如，釣魚攻擊的典型情況是攻擊者欺騙用戶相信網(wǎng)絡(luò)“釣魚者”是客戶端或授權(quán)服務(wù)器。在原OAuth2.0協(xié)議中，信息顯示在授權(quán)頁面，但是，改進(jìn)OAuth2.0授權(quán)機(jī)制通過VGateway發(fā)送驗(yàn)證信息的功能，用戶可以更簡(jiǎn)單地識(shí)別。如果，攻擊者偽造驗(yàn)證消息，真實(shí)的VGateway將攔截驗(yàn)證響應(yīng)。同時(shí)，由于驗(yàn)證信息中含有不可預(yù)測(cè)值，攻擊者不能通過枚舉的方式來獲得驗(yàn)證消息。

3.1.2 驗(yàn)證響應(yīng)

驗(yàn)證響應(yīng)幫助AS防止用戶憑據(jù)遭受釣魚攻擊而被盜。驗(yàn)證消息與驗(yàn)證響應(yīng)相一致，且每次都不同，因此，由VGateway生成的用戶憑據(jù)是動(dòng)態(tài)的。與原OAuth2.0協(xié)議相比，OTP機(jī)制的引入使攻擊者進(jìn)行釣魚攻擊的難度大大增加。

3.1.3 可信的三方協(xié)商

由用戶、VGateway和AS組成了相互信任的三方密鑰協(xié)商組。用戶在授權(quán)過程中不直接與AS交互，用戶憑證由用戶和VGateway中的驗(yàn)證響應(yīng)結(jié)果生成，并發(fā)送到AS。 如果任一方不被信賴，該過程將被終止。

3.2 抵抗網(wǎng)絡(luò)釣魚攻擊的措施

下面介紹了改進(jìn)后的OAuth2.0授權(quán)機(jī)制針對(duì)網(wǎng)絡(luò)釣魚攻擊模式的改進(jìn)，并證明了對(duì)策的有效性。

3.2.1 假冒AS

這是最常見且易于實(shí)施的網(wǎng)上誘騙，原OAuth2.0協(xié)議無法正確處理。惡意客戶端可能會(huì)誘騙用戶在偽造授權(quán)頁中輸入用戶憑據(jù)，從而竊取用戶密碼或其他私密信息。改進(jìn)OAuth2.0授權(quán)機(jī)制的對(duì)策如下：

(1) 由三方協(xié)商組(VGateway、用戶和AS)生成密鑰(驗(yàn)證信息、驗(yàn)證響應(yīng)和用戶憑證)的機(jī)制，使得授權(quán)的三個(gè)部分彼此可信。由于假冒的AS對(duì)VGateway而言不可信，所以攻擊會(huì)失敗。

(2) 由于OTP機(jī)制的存在使得盜取密鑰沒有任何意義，并且，重要的驗(yàn)證消息在用戶和VGateway之間進(jìn)行交互。

3.2.2 假冒VGateway

VGateway是文中改進(jìn)OAuth2.0授權(quán)機(jī)制中介紹的一個(gè)新角色，其安全性也至關(guān)重要。如果假冒VGateway能夠湊效，那么攻擊者可以通過用戶或盜取用戶憑證來獲取驗(yàn)證響應(yīng)。

改進(jìn)OAuth2.0授權(quán)機(jī)制的對(duì)策如下：

(1) 驗(yàn)證消息的不可預(yù)測(cè)性使得枚舉很困難。錯(cuò)誤的驗(yàn)證信息導(dǎo)致錯(cuò)誤的用戶憑證，AS無法驗(yàn)證通過。

(2) 攻擊者不能夠反推出F2函數(shù)。

(3) AS拒絕接收來自不在白名單范圍內(nèi)的VGateway請(qǐng)求。

3.2.3 釣取用戶注冊(cè)信息

原OAuth2.0授權(quán)方式中，攻擊者可以通過釣魚攻擊使用偽造的回調(diào)URI來釣取用戶的注冊(cè)信息(例如電話號(hào)碼和其他敏感信息)，也可以從其他攻擊模型中獲得。

改進(jìn)OAuth2.0授權(quán)機(jī)制的對(duì)策如下：

(1) 用戶提交給回調(diào)URI的注冊(cè)信息不應(yīng)該是敏感信息，必須避免輸入密碼。

(2) 攻擊者不能反推出函數(shù)F1和F2。

3.2.4 釣取用戶憑證

惡意應(yīng)用程序可能會(huì)通過在最終的用戶授權(quán)過程中濫用嵌入式瀏覽器，或者通過呈現(xiàn)自己的用戶界面，而不是受信任的瀏覽器系統(tǒng)呈現(xiàn)用戶授權(quán)界面，來嘗試盜取用戶憑證。一旦攻擊者獲得用戶憑證，就可以獲得資源所有者存儲(chǔ)的敏感資源。

改進(jìn)OAuth2.0授權(quán)機(jī)制的對(duì)策如下：

(1) 對(duì)于AS或任何請(qǐng)求響應(yīng)的真實(shí)性問題，使用傳輸層的安全特性來解決。

(2) 用戶憑證依靠VGateway中的OTP動(dòng)態(tài)生成，并發(fā)送到AS。該過程發(fā)生在服務(wù)提供程序中，因此，攻擊者很難釣取到用戶憑據(jù)。

4 結(jié) 語

本文通過防止攻擊者偽裝成授權(quán)服務(wù)器來改進(jìn)OAuth2.0授權(quán)機(jī)制以解決釣魚攻擊問題。改進(jìn)后的授權(quán)機(jī)制引入OTP和三方協(xié)商的方式，使得攻擊者很難通過網(wǎng)絡(luò)瀏覽器或移動(dòng)設(shè)備進(jìn)行釣魚攻擊。而且，為避免原始密碼被盜，改進(jìn)的OAuth2.0授權(quán)機(jī)制還引入了VGateway來安全生成用戶憑證。本文還對(duì)改進(jìn)OAuth2.0授權(quán)機(jī)制的有效性進(jìn)行了理論方面的評(píng)估。

在以后的工作中，我們可以嘗試借助模型檢測(cè)工具來對(duì)改進(jìn)的OAuth2.0授權(quán)進(jìn)行建模分析。另外，也可以嘗試針對(duì)OAuth2.0協(xié)議在實(shí)現(xiàn)過程中存在的其他類型攻擊研究改善方案，從而達(dá)到進(jìn)一步完善OAuth2.0認(rèn)證授權(quán)系統(tǒng)的目的。

[1] 劉大紅,劉明.第三方應(yīng)用與開放平臺(tái)OAuth認(rèn)證互連技術(shù)研究[J].電腦知識(shí)與技術(shù),2012,8(22):5367-5369.

[2] 王煥孝,顧純祥,鄭永輝.開放授權(quán)協(xié)議OAuth2.0的安全性形式化分析[J].信息工程大學(xué)學(xué)報(bào),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協(xié)議的安全性形式化分析[J].計(jì)算機(jī)工程與設(shè)計(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] 時(shí)子慶,劉金蘭,譚曉華.基于OAuth2.0的認(rèn)證授權(quán)技術(shù)[J].計(jì)算機(jī)系統(tǒng)應(yīng)用,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。歐海文，教授，主研領(lǐng)域：密碼編碼與應(yīng)用技術(shù)。付永亮，碩士生。于芋，碩士生。胡馨月，碩士生。

TP393.02

A

10.3969/j.issn.1000-386x.2017.12.037