［徐博文　賈曼　曹維華　朱華虹］

?

基于OAuth協(xié)議的天翼開放平臺安全性淺析

［徐博文賈曼曹維華朱華虹］

摘要OAuth協(xié)議是當(dāng)前互聯(lián)網(wǎng)最流行的開放授權(quán)標(biāo)準(zhǔn)。以天翼開放平臺為例，介紹了OAuth2.0協(xié)議的工作原理，重點分析了OAuth2.0安全問題的兩個焦點，一是技術(shù)應(yīng)用漏洞，即由于授權(quán)場景的多樣性導(dǎo)致部署時產(chǎn)生邏輯和代碼設(shè)計漏洞，二是業(yè)務(wù)應(yīng)用漏洞，即由于安全機制不夠完善以及協(xié)議涉及的實體之間無法有效配合導(dǎo)致業(yè)務(wù)應(yīng)用層面的安全性降低。

關(guān)鍵詞：OAuth2.0 授權(quán)協(xié)議 天翼開放平臺 應(yīng)用漏洞

徐博文

中國電信股份有限公司廣東研究院，主要研究方向為IP網(wǎng)絡(luò)通信技術(shù)。

賈曼

中國電信集團公司網(wǎng)絡(luò)運行維護事業(yè)部數(shù)據(jù)處，主要研究方向為IP網(wǎng)絡(luò)通信技術(shù)。

曹維華

中國電信股份有限公司廣東研究院，主要研究方向為IP技術(shù)、移動互聯(lián)網(wǎng)技術(shù)。

朱華虹

中國電信股份有限公司廣東研究院，主要研究方向為IP技術(shù)、SDN技術(shù)。

1　引言

中國電信天翼開放平臺為合作伙伴提供統(tǒng)一的開放合作服務(wù)門戶（Open.189.cn），打造統(tǒng)一的運營商級能力開放合作品牌和入口，平臺于2012年3月27日正式上線，基于OAuth協(xié)議提供授權(quán)服務(wù)，支持版本為2.0。OAuth（Open Authorization，即開放授權(quán)）為用戶資源的授權(quán)提供了一個安全、開放而又簡易的標(biāo)準(zhǔn)，OAuth授權(quán)不會使第三方觸及到用戶的帳號信息（如用戶名與密碼），即第三方無需使用用戶的用戶名與密碼就可以申請獲得該用戶資源的授權(quán)。OAuth提供的是可信的第三方認(rèn)證，既能通過其統(tǒng)一認(rèn)證解決用戶在不同Web應(yīng)用之間的身份認(rèn)證問題，又能實現(xiàn)在保證用戶信息安全的基礎(chǔ)上，將用戶指定的資源授權(quán)給第三方，實現(xiàn)用戶身份認(rèn)證以及資源開放授權(quán)，因此出現(xiàn)不久即成為RFC標(biāo)準(zhǔn)并獲得各大網(wǎng)絡(luò)服務(wù)提供商的支持，包括微軟、Google、Facebook、Twitter，以及國內(nèi)的新浪、騰訊、網(wǎng)易、人人和豆瓣等在內(nèi)的互聯(lián)網(wǎng)公司均在其開放平臺上提供了OAuth認(rèn)證接口。本文將以天翼開放平臺為例，介紹OAuth2.0協(xié)議工作原理，同時探討OAuth2.0的安全問題。

2　OAuth2.0協(xié)議工作原理

（1）協(xié)議實體

OAuth2.0協(xié)議定義了 4種不同的實體：資源擁有者（Resource Owner），指能夠?qū)κ鼙Ｗo資源進行授權(quán)的實體，如天翼用戶。資源服務(wù)器（Resource Server），存放用戶受保護的資源并通過與授權(quán)服務(wù)器的交互對資源的訪問請求作出應(yīng)答，天翼開放平臺資源服務(wù)器地址為api.189.cn。授權(quán)服務(wù)器（Authorization Server），對資源擁有者進行身份認(rèn)證，對驗證通過的授予訪問權(quán)限，天翼開放平臺授權(quán)服務(wù)器地址為oauth.api.189.cn，授權(quán)服務(wù)器和資源服務(wù)器構(gòu)成了天翼開放平臺的主體?？蛻舳耍–lient），指第三方應(yīng)用系統(tǒng)或程序，可以是一個遠程Web站點、一段JavaScript代碼或一個本地App，它獲得域內(nèi)用戶授權(quán)之后可以訪問用戶存放在資源服務(wù)器上的資源，天翼開放平臺支持開發(fā)者根據(jù)平臺所提供資源，創(chuàng)建和管理第三方合作應(yīng)用，通過合作應(yīng)用調(diào)用平臺的資源。

（2）協(xié)議工作流程

OAuth 2.0協(xié)議的基本工作流程如圖 1 所示。

圖1　OAuth 2.0協(xié)議基本工作流程

①客戶端向資源擁有者發(fā)起“授權(quán)請求”（authorization request）；②資源擁有者同意客戶端的授權(quán)請求，并返回“授權(quán)許可”（authorization grant）給客戶端；③客戶端將“授權(quán)許可”提交給授權(quán)服務(wù)器，請求獲得用戶資源的訪問權(quán)限；④授權(quán)服務(wù)器驗證通過后向客戶端返回“訪問令牌”（access token）；⑤客戶端將“訪問令牌”提交給資源服務(wù)器，請求訪問用戶資源；⑥資源服務(wù)器將對應(yīng)用戶的受保護資源（Protected Resource）返回給客戶端。

（3）授權(quán)模式

OAuth2.0強調(diào)可擴展性和靈活性，為此定義了多種授權(quán)模式，以適應(yīng)多個應(yīng)用場景授權(quán)，包括授權(quán)碼模式（Authorization Code）、簡化模式（Implicit Grant）、客戶端授權(quán)模式（Client Credentials）以及資源擁有者密碼授權(quán)模式（Resource Owner Password Credentials），天翼開放平臺支持前3種，其中Authorization Code主要用于Web應(yīng)用，Implicit Grant用于手機和桌面等Native應(yīng)用，Client Credentials可用于Web和Native應(yīng)用，但僅限于用來訪問一些公共資源，而不是受限資源如某個特定天翼用戶的資源。

3　OAuth2.0協(xié)議安全問題分析

OAuth 2.0協(xié)議領(lǐng)導(dǎo)者之一Eran Hammer認(rèn)為OAuth2.0沒有達到安全和互操作性這兩個最重要的目標(biāo)，“在大部分開發(fā)者手中明顯出現(xiàn)了不安全的實現(xiàn)結(jié)果”［1］。從大量案例［2］來看，OAuth2.0協(xié)議的安全焦點集中在技術(shù)應(yīng)用漏洞和業(yè)務(wù)應(yīng)用漏洞兩個方面。本文并未對天翼開放平臺進行安全方面的深入測試，針對OAuth2.0安全性的探討來自其他案例，天翼開放平臺僅作為場景類比和討論。

（1）技術(shù)應(yīng)用漏洞

由于OAuth2.0授權(quán)場景的復(fù)雜化，容易導(dǎo)致開放平臺方設(shè)計和部署不周，或者對應(yīng)用方的安全指引不足而錯誤使用應(yīng)用場合。另外，場景之間的安全問題容易產(chǎn)生交叉，使一些潛在威脅通過場景轉(zhuǎn)換成為顯性漏洞［3］。

以第三方登錄認(rèn)證為例，當(dāng)應(yīng)用方通過平臺方的Access token 獲取接口得到用戶的授權(quán)信息后，將授權(quán)信息（Access Token、uid、expire_time）作為本應(yīng)用賬號系統(tǒng)的匹配參數(shù)，實現(xiàn)新用戶注冊或者已有用戶的身份認(rèn)證。在這個流程中，如果應(yīng)用方在授權(quán)信息匹配處理邏輯部分設(shè)計不嚴(yán)謹(jǐn)，例如參數(shù)選擇不當(dāng)或沒有應(yīng)用方來源驗證機制，將導(dǎo)致嚴(yán)重漏洞，最常見的攻擊是授權(quán)信息篡改，可導(dǎo)致任意登錄應(yīng)用方賬號的嚴(yán)重漏洞。

圖2　基于天翼開放平臺的某手機客戶端應(yīng)用OAuth認(rèn)證案例

圖2是OAuth 2.0應(yīng)用于移動終端進行用戶身份認(rèn)證的典型案例，在其業(yè)務(wù)邏輯的第3步，當(dāng)基于天翼開放平臺的某手機客戶端應(yīng)用獲取開放平臺方返回的Access Token、uid等用戶授權(quán)信息后，將授權(quán)信息上報給手機客戶端應(yīng)用自身的用戶認(rèn)證系統(tǒng)進行賬號匹配登錄，如果該應(yīng)用后續(xù)用戶匹配邏輯不嚴(yán)謹(jǐn)，存在錯誤選擇授權(quán)信息作為參數(shù)（如單純選擇uid一項）或者沒有對授權(quán)信息（Access Token）進行來源驗證，攻擊者可以通過截包篡改匹配參數(shù)，比如修改為其他天翼用戶uid，從而實現(xiàn)該手機客戶端自身用戶系統(tǒng)的任意賬號登錄。

另外，由于部署了OAuth2.0的平臺方和第三方應(yīng)用存在邏輯設(shè)計和代碼安全方面的問題，攻擊者可以對二者的賬號系統(tǒng)進行包括截包篡改、CSRF和XSS等多種形式的復(fù)合攻擊［4］。

（2）業(yè)務(wù)應(yīng)用漏洞

OAuth2.0協(xié)議作為一種授權(quán)認(rèn)證協(xié)議，在業(yè)務(wù)應(yīng)用層面涉及到用戶、平臺以及第三方應(yīng)用這3個實體，其安全問題由這3個實體綜合決定。平臺方在部署協(xié)議時，需要一套相應(yīng)的安全機制來保證整個業(yè)務(wù)環(huán)節(jié)的安全，而同時又有賴于第三方應(yīng)用和用戶在使用過程中的配合。然而，從對主流開放平臺應(yīng)用情況的調(diào)研來看，由于平臺方安全機制不夠完善，同時用戶與第三方應(yīng)用這兩個實體之間缺乏有效配合，導(dǎo)致OAuth2.0協(xié)議在業(yè)務(wù)應(yīng)用層面安全性降低。

3.1安全機制

（1）對平臺資源的權(quán)限分級不嚴(yán)格

OAuth認(rèn)證最終結(jié)果是獲得用戶平臺資源的訪問授權(quán)，如果平臺方對平臺資源權(quán)限分級不嚴(yán)格，將導(dǎo)致用戶信息和資源泄露的危險，因此必須對平臺資源進行嚴(yán)格的權(quán)限等級劃分，使第三方應(yīng)用只能根據(jù)自身網(wǎng)絡(luò)服務(wù)需求去申請并獲取用戶在平臺上的相應(yīng)資源，例如第三方登錄認(rèn)證只授權(quán)用戶賬號和頭像信息，郵件客戶端只授權(quán)用戶通信錄列表以及郵件讀取、發(fā)送和修改權(quán)限。天翼開放平臺對自身能力服務(wù)及第三方特色能力即平臺資源進行優(yōu)化配置、整合、分類和分級，形成了以天翼帳號、電信能力、數(shù)字內(nèi)容以及綜合信息為主體的四大類開放能力［1］，基于平臺的第三方應(yīng)用需要進行相應(yīng)的“能力綁定”，因此在平臺資源權(quán)限分級方面相對完善。

（2）缺乏與其他安全驗證機制的配合應(yīng)用

OAuth認(rèn)證使第三方獲得對用戶資源的授權(quán)訪問，如果該授權(quán)是由于漏洞攻擊引發(fā)的被動授權(quán)，那么如果沒有其他安全驗證機制的配合，攻擊將獲得成功。谷歌公司最早意識到這一點并且將OAuth認(rèn)證與兩步驗證機制（Two-step verification，簡稱2SV）結(jié)合起來，即在谷歌賬號系統(tǒng)中啟用OAuth認(rèn)證必須首先綁定手機并通過短信或電話進行一次性密碼的身份驗證，以保證OAuth認(rèn)證是在用戶知情的情況下發(fā)生的。其他平臺和應(yīng)用有的則是在授權(quán)頁面要求用戶填入第三方渠道如備用郵箱獲取的驗證碼來保證授權(quán)流程的安全性，但可惜的是大部分平臺方和應(yīng)用僅考慮操作方便性，沒有做到將OAuth認(rèn)證與其他安全驗證機制結(jié)合起來使用，忽視了賬戶安全。

3.2協(xié)議實體

（1）第三方應(yīng)用開發(fā)者：缺乏自律

在OAuth2.0的整體解決方案中，第三方應(yīng)用的配合是安全的重要一環(huán)，這種配合實際上指的是應(yīng)用開發(fā)者的自律。在平臺資源權(quán)限進行了嚴(yán)格劃分的基礎(chǔ)上，開發(fā)者應(yīng)該按照應(yīng)用自身網(wǎng)絡(luò)服務(wù)需求去申請相應(yīng)的權(quán)限，這些應(yīng)該在開發(fā)者協(xié)議條款中著重闡明，然而這種完全依賴開發(fā)者高度自律的機制是不可靠的，以Android系統(tǒng)移動應(yīng)用為例，就普遍存在高權(quán)限授權(quán)申請的情況。

（2）平臺方：審核機制存在漏洞

對第三方應(yīng)用的約束責(zé)任主要在平臺方，第一步就是對第三方應(yīng)用的審核上，審核內(nèi)容最重要的就是對用戶資源權(quán)限的申請是否符合要求，是否有越權(quán)行為等。然而，從對多個開放平臺的調(diào)研看，審核標(biāo)準(zhǔn)不一，有的甚至只需要填寫應(yīng)用的基本信息，對用戶資源請求權(quán)限根本不做任何審查和限制，惡意第三方應(yīng)用可以繞過審查，非法獲取超額權(quán)限。天翼開放平臺審核機制相對健全，對個人開發(fā)者和企業(yè)開發(fā)者均有較為嚴(yán)格的身份認(rèn)證，個人必須提供身份證件進行實名認(rèn)證，企業(yè)則需要提供法人和營業(yè)執(zhí)照，對接入應(yīng)用的信息審核項目也較為豐富。

（3）用戶：對OAuth認(rèn)證的安全性缺乏認(rèn)識

OAuth協(xié)議盡管在國內(nèi)得到較大應(yīng)用，但對于大多數(shù)用戶來說仍然屬于新鮮事物，而且國內(nèi)用戶缺乏保護賬戶信息和權(quán)限的習(xí)慣，往往在應(yīng)用方引導(dǎo)下一步步完成授權(quán)操作，只體驗到易用性而忽略了安全性，例如當(dāng)前流行的OAuth協(xié)議“一鍵登錄”操作，給用戶帶來極大便利的同時也降低了用戶的安全意識，用戶越來越不在意自己的賬號安全，敏感賬戶同時授權(quán)給多個應(yīng)用的情況非常常見。

4　結(jié)語

OAuth協(xié)議促進了Web2.0技術(shù)的發(fā)展，但同時也帶來了安全問題。盡管2.0版本已經(jīng)解決了協(xié)議自身的安全漏洞，但是在應(yīng)用層面仍然存在諸多問題，解決這些問題不僅需要平臺方在部署方面以及多個業(yè)務(wù)環(huán)節(jié)的努力，也需要第三方應(yīng)用的配合，同時藉由OAuth認(rèn)證的不斷普及，用戶能夠逐步提升對OAuth協(xié)議的了解和認(rèn)識，養(yǎng)成保護個人賬戶資源的習(xí)慣。天翼開放平臺與應(yīng)用開發(fā)者通過合作實現(xiàn)便利服務(wù)和價值增值，在強調(diào)業(yè)務(wù)擴展的同時，雙方同時承擔(dān)著推廣OAuth協(xié)議、培養(yǎng)用戶安全意識以及規(guī)范應(yīng)用開發(fā)業(yè)態(tài)的責(zé)任，真正構(gòu)建一個更為開放、安全的能力合作生態(tài)價值鏈。

參考文獻

1Eran Hammer.OAuth 2.0：通往地獄之路［Z/OL］. http：// article.yeeyan.org/view/50978/307535， 2012

2Horseluke. OAuth 2.0安全案例回顧［Z/OL］. http：//drops. wooyun.org/papers/598， 2013

3T. Lodderstedt， Ed.等. OAuth 2.0 Threat Model and Security Considerations［Z/OL］. https：//tools.ietf.org/html/ draft-ietf-oauth-v2-threatmodel-08， 2012

DOI：10.3969/j.issn.1006-6403.2016.04.003

收稿日期：（2016-03-22）