陳藝琳,左黎明,郝 恬,羅嬌燕

(華東交通大學 理學院,江西 南昌 330013)

0 引 言

隨著互聯(lián)網(wǎng)技術的發(fā)展,各類應用程序?qū)τ脩羯矸菡J證的要求也越來越高。用戶身份認證技術是網(wǎng)絡信息安全體系中至關重要的一環(huán),“以認證為核心”的零信任架構成為SaaS等網(wǎng)絡服務與物聯(lián)網(wǎng)安全[1]的必要技術。使用token作為身份認證技術在API接口中最為常見,基于此出現(xiàn)了一系列網(wǎng)絡通信協(xié)議,其中OAuth2.0協(xié)議因其協(xié)議簡單清晰而被廣泛應用。然而,由于開發(fā)者在部署協(xié)議的過程中為了最小代價整合資源,并沒有嚴格遵守協(xié)議規(guī)定,這就造成了一系列針對OAuth2.0協(xié)議的攻擊。如淘網(wǎng)址認證登錄漏洞(烏云編號wooyun-2012-011104)[2]、由于OAuth 2.0無綁定token問題導致某APP可任意進入他人賬號[3](烏云編號:wooyun-2013-017306)、2021年最新微軟和GitHub OAuth實施漏洞導致重定向攻擊[4]等。不法分子通過身份認證漏洞竊取公民隱私,威脅公民個人信息安全。隨著開發(fā)者安全意識的提高,客戶端應用程序?qū)?shù)據(jù)傳輸協(xié)議進行了更加嚴格的規(guī)定。但是在傳統(tǒng)的用戶名密碼登錄模式中,一旦用戶的用戶名和密碼遭到泄露,攻擊者仍然可以偽造用戶身份進行數(shù)據(jù)訪問。即使沒有密碼,攻擊者仍然可以通過密碼爆破、字典撞庫等方式竊取用戶身份,侵犯公民數(shù)據(jù)隱私[5]。

針對OAuth2.0協(xié)議產(chǎn)生的安全問題,國內(nèi)外學者曾進行過多方面的研究。2014年,S.Pai和Y.Sharma[6]等人針對應用了OAuth2.0協(xié)議的Alloy框架進行了分析,并驗證其中存在的安全漏洞。CJ Mitchell[7]分析研究了中國基于SSO(Single Sign On)單點登錄的OAuth2.0協(xié)議,總結出可能存在CSRF漏洞和用戶身份綁定缺陷邏輯漏洞。2019年,劉奇旭[8]研究了面向OAuth2.0授權服務API的賬號劫持攻擊威脅檢測,設計并實現(xiàn)了面向OAuth2.0授權服務API的賬號劫持攻擊威脅檢測框架OScan。2021年,陳佳[9]研究了電力系統(tǒng)下微服務架構的安全性,設計了一種基于JWT規(guī)范的令牌認證方案,授權機制基于OAuth2.0授權協(xié)議擴展實現(xiàn)。

針對OAuth2.0協(xié)議的一些安全問題,該文提出了一種基于國密SM2和OAuth2.0強身份認證方案,將認證參數(shù)通過數(shù)字簽名進行保護,實現(xiàn)了對用戶身份的安全認證與安全控制訪問。有效保證了數(shù)據(jù)完整性、數(shù)據(jù)機密性、不可抵賴性、消息新鮮性與來源可靠性。

1 OAuth2.0協(xié)議及其攻擊

1.1 OAuth2.0協(xié)議

OAuth2.0是一個開放的標準,通常擁有四個角色參與認證流程:資源所有者、資源服務器、客戶端、授權服務器[10]。其中,資源擁有者為給予受保護資源訪問權限的主機或者用戶;授權服務器為在對資源擁有者進行身份認證并獲得授權后,為客戶端提供訪問令牌;客戶端為通常指代理用戶發(fā)起受保護資源請求的客戶端應用程序;資源服務器為存儲受保護資源,接受授權服務器提供的訪問令牌的服務器。

在客戶端、資源管理器、授權管理器、三方不互信的情況下,OAuth2.0協(xié)議允許資源所有者通過授權服務器授權第三方應用程序訪問存儲在資源服務器上的受保護的信息,而不需要共享密碼。常見的授權服務器有國外的Facebook、Google,國內(nèi)的騰訊、新浪等。OAuth2.0一般情況下有四種模式,即:授權碼模式、簡化授權模式、密碼模式、客戶端憑證模式。OAuth2.0協(xié)議中四個角色的交互流程如圖1所示。

圖1 OAuth2.0協(xié)議交互流程

其中,授權碼模式一般用于帶有Server端的應用程序。其認證流程如下:

(1)客戶端通過用戶代理去授權服務器進行授權,攜帶客戶端標識及重定向URI,response_type值為code;

(2)資源擁有者進行授權;

(3)接收到資源擁有者的確認授權后,授權服務器攜帶授權碼請求客戶端的重定向URI,客戶端提取授權碼,再次向授權服務器請求access_token;

(4)授權服務器返回給客戶端access_token;

(5)客戶端攜帶access_token訪問資源服務器;

(6)資源服務器向授權服務器驗證access_token,并向用戶代理響應請求。

1.2 針對基于OAuth2.0認證方案的攻擊

OAuth2.0協(xié)議在部署時,為了讓平臺方以最小的代價整合所有資源,協(xié)議對許多方面并不做強制要求,這就導致一些平臺的開發(fā)者在開發(fā)過程中由于安全意識薄弱,并沒有正確地應用OAuth2.0協(xié)議,造成了許多安全問題[11]。OAuth2.0協(xié)議中,各個角色所承擔的功能不同,于是可以劃分出以下幾種攻擊方式。該文就其中一些典型漏洞做出解釋。

(1)針對客戶端的攻擊。

針對客戶端的CSRF(Cross-Site Request Forgery)[12]攻擊流程如圖2所示。攻擊者偽造合法請求,誘導完成了身份授權的受害用戶觸發(fā)該請求,從而達到竊取令牌的目的。漏洞的原因是客戶端應用程序錯誤使用或未使用state參數(shù),該參數(shù)值是一個隨機字符串,用于維持請求和回調(diào)之間的狀態(tài)。攻擊完成的前提是受害者在客戶端應用程序完成授權。由于請求都來自客戶端應用程序而非資源擁有者,而且授權碼是資源擁有者與客戶端的唯一標識,授權服務器并不知道授權碼來自哪個資源擁有者。

圖2 針對OAuth2.0協(xié)議客戶端的CSRF攻擊流程

(2)針對授權服務器的攻擊。

redirect_uri被篡改為惡意鏈接重定向地址redirect_uri,是指授權服務器將授權通過后的響應發(fā)送到的重定向URI。若客戶端在注冊時使用了不嚴格的重定向地址,或者授權服務器未對重定向地址進行嚴格校驗,就會導致重定向地址被篡改為另外的回調(diào)URL,甚至在對重定向地址進行了校驗的情況下頁可以被繞過。利用這種URL跳轉(zhuǎn)或XSS漏洞,可以獲取到相關授權token,危害到目標用戶的賬號權限。下面進行詳細說明。

若客戶端在注冊時使用了不嚴格的重定向地址,就可能造成授權服務器在校驗時因校驗不完整的而繞過。若授權服務器只對重定向地址的根域做了匹配,即只要請求的URI中包含注冊的URI就認為是合法請求,那么授權碼和state就會因重定向地址篡改而被發(fā)送至攻擊者構造的惡意地址;獲取到授權碼之后,攻擊者便可以使用受害者的授權碼和state偽造身份向客戶端發(fā)起正?；卣{(diào)請求,客戶端校驗后向授權服務器發(fā)送令牌申請,完成后攻擊者便可訪問受害者的資源。

1.3 國密SM2數(shù)字簽名

國密SM2算法是國家密碼局于2010年頒布的橢圓曲線公鑰密碼算法,在政府、銀行和關鍵基礎措施系統(tǒng)中得到廣泛應用,目前國家對國密算法使用已經(jīng)有強制性要求[13]。使用SM2算法進行數(shù)字簽名主要有三個步驟:密鑰生成、簽名生成和驗證簽名。國內(nèi)已有眾多將SM2簽名算法或其改進算法應用于各類認證方案中的實例[14]。

參數(shù)說明和密鑰生成見文獻[15],簽名生成和驗證過程如下:

(1)簽名生成。

國密SM2數(shù)字簽名生成算法流程如圖3所示。用戶A具有長度為entlenA比特的可辨別標識IDA,記ENTLA是由整數(shù)entlenA轉(zhuǎn)換而成的兩個字節(jié),雜湊值ZA=H256(ENTLA‖IDA‖a‖b‖xG‖yG‖xA‖yA)。

圖3 SM2數(shù)字簽名算法流程

(2)簽名驗證。

國密SM2數(shù)字簽名算法的驗證流程如圖4所示。設接收到的消息M'及其數(shù)字簽名(r',s'),接收用戶用圖4所示流程驗證數(shù)字簽名的合法性。

圖4 SM2簽名驗證算法流程

2 強安全方案設計及其關鍵實現(xiàn)

2.1 強安全方案設計

身份認證一般有三種場景[16],基于桌面應用的客戶端模式(C/S)[17]、基于移動端app(APP/S)客戶端模式[18]和基于瀏覽器的客戶端模式(B/S)[19]。三種場景下均采用國密SM2算法進行數(shù)字簽名。三端交互的具體流程如圖5所示,其中C為客戶端,S1為授權服務器,S2為資源服務器。

圖5 C/S、B/S、APP/S下的身份認證流程

(1)C→S1。

首先客戶端發(fā)送訪問申請,若未授權,則授權服務器返回授權頁面。

(2)C→S1。

用戶確認授權,簽名內(nèi)容

sig1=uid‖client_id‖redirect_uri‖datestate ‖response_type。

(3)S1→C。

授權服務器驗證簽名,并返回授權碼信息簽名,簽名內(nèi)容

sig2=code‖uid‖client_id‖state‖date‖redirect_uri。

(4)C→S2。

客戶端請求token,簽名內(nèi)容

sig3=code‖uid‖client_id‖state‖date‖grant_type‖ redirect_uri。

(5)S1→C。

授權服務器驗證簽名,并返回access_token,簽名內(nèi)容

sig4=state‖access_token‖uid‖client_id‖date‖token_type。

(6)C→S2。

客戶端使用access_token請求資源服務器。

(7)S2→S1。

資源服務器將access_token發(fā)送至授權服務器進行驗證。

(8)S1→S2。

授權服務器返回驗證結果。

(9)S2→C。

若驗證成功,則資源服務器返回客戶端請求的受保護資源。

2.2 授權碼模式及其實現(xiàn)

授權服務器端統(tǒng)一采用C#開發(fā)的ashx一般處理程序進行數(shù)據(jù)驗證;帶有Server端的客戶端也采用一般處理程序ashx作為redirect_uri客戶端重定向地址。在基于桌面應用客戶端C/S架構下,使用C#開發(fā)WinForm程序,并進行SM2算法的簽名和驗證。

C#客戶端對消息進行簽名:

TanSM2 sm2=new TanSM2();

String msg=uid+"#"+time+"#"+state+"#"+

redirect_uri+"#"+client_id+"#"+response_type;

sm2.TanSM2Sign(msg, user_prikey,

out sigtoCA);

服務端進行簽名驗證:

TanSM2 sm2=new TanSM2();

String msg=uid+"#"+time+"#"+state+"#"+

redirect_uri+"#"+client_id+"#"+response_type;

bool flag = sm2.TanSM2Verify

(msg,pubkey,sig);

第一步,客戶端向授權服務器端發(fā)送請求簽名,數(shù)據(jù)格式如圖6所示。

圖6 客戶端向授權服務器發(fā)送請求數(shù)據(jù)格式

生成5位隨機字符串state,并加入時間戳date。

第二步,授權服務器向客戶端重定向地址發(fā)送授權碼,數(shù)據(jù)格式如圖7所示。服務端獲取到json數(shù)據(jù)后,從中解析出加密后的密文參數(shù),并使用服務端私鑰進行解密。解密完成后,從數(shù)據(jù)庫中查找該用戶的公鑰,并使用用戶公鑰對客戶端發(fā)送的明文消息進行簽名驗證。驗證成功后,授權服務器向重定向地址發(fā)送授權碼code。

圖7 授權服務器返回授權碼數(shù)據(jù)格式

第三步,客戶端攜帶授權碼向授權服務器請求access_token,請求數(shù)據(jù)格式如圖8所示。重定向地址接收到授權碼之后,解密并驗證簽名。驗證通過后攜帶授權碼向授權服務器/token目錄請求access_token。

圖8 客戶端攜帶授權碼申請令牌數(shù)據(jù)格式

第四步,服務端向客戶端返回access_token,返回數(shù)據(jù)格式如圖9所示。服務端驗證code后,向客戶端返回access_token。

圖9 授權服務器返回令牌數(shù)據(jù)格式

下一步客戶端便可以使用access_token訪問資源服務器上的受保護資源,資源服務器將請求轉(zhuǎn)發(fā)至CA驗證access_token的有效性之后便可將受保護資源返回給客戶端。

3 安全性分析

3.1 基本分析

(1)數(shù)據(jù)機密性。

由于在數(shù)據(jù)傳輸過程中使用國密SM2簽名算法對交互數(shù)據(jù)進行數(shù)字簽名,并在授權服務器端進行簽名驗證,防止了攻擊者惡意篡改數(shù)據(jù)。

(2)數(shù)據(jù)完整性。

授權服務器端會逐一驗證簽名中的參數(shù)和傳遞的參數(shù)是否一致,攻擊者無法刪除掉交互過程中的任意參數(shù)。

(3)不可抵賴性。

客戶端會和用戶都擁有自己的唯一私鑰,并用客戶端和用戶的唯一私鑰進行簽名。授權服務器會使用私鑰對應的公鑰進行驗證,保證了數(shù)據(jù)的不可抵賴性。

(4)消息新鮮性。

消息的新鮮性可有效抵抗重放攻擊。在發(fā)送的消息中加入時間戳與隨機字符串state,授權服務器根據(jù)時間戳來確定消息的新鮮性。

3.2 對比分析

各個應用了OAuth2.0協(xié)議平臺方案安全性對比分析如表1所示。

表1 安全性對比分析

方案1:微軟和GitHub OAuth;

方案2:人人網(wǎng)OAuth 2.0授權;

方案3:百度開放平臺OAuth授權接口;

方案4:基于國密SM2的OAuth2.0認證。

從表1中可以看出,方案1、2、3由于存在重定向uri篡改問題,在數(shù)據(jù)機密性和來源可靠性方面存在安全問題。方案4采用國密SM2算法對信息進行數(shù)字簽名,有效保證了數(shù)據(jù)完整性、數(shù)據(jù)機密性、不可抵賴性、消息新鮮性與來源可靠性。

4 結束語

針對目前OAuth2.0協(xié)議中存在的數(shù)據(jù)來源性問題,提出了一種基于國密SM2的OAuth2.0身份認證方案。方案對可能會被篡改的信息如uid、client_id、state、date 、redirect_uri等進行數(shù)字簽名,并在授權服務器端進行簽名驗證。隨后針對B/S、C/S、APP/S三種場景下的身份認證進行仿真實驗,實驗表明該方案具有數(shù)據(jù)機密性、數(shù)據(jù)完整性、不可抵賴性、消息新鮮性,且傳輸效率未降低。