邱永哲

（中國科學技術館 網(wǎng)絡科普部，北京 100012）

1 互聯(lián)網(wǎng)發(fā)展概述

隨著互聯(lián)網(wǎng)的高速發(fā)展，各種社交、購物網(wǎng)站層出不窮，中國已經(jīng)全面邁入了互聯(lián)網(wǎng)時代。對用戶來說，這些繁雜的網(wǎng)站、應用程序在方便生活的同時，也引入了個人信息安全的問題。為避免個人信息遭到泄露，不同的網(wǎng)站設置不同的賬戶密碼這一方法也逐漸深入人心，成了每個網(wǎng)民在互聯(lián)網(wǎng)中保護個人安全的最有效方法。然而，大量的賬號和密碼也給用戶帶來了記憶負擔，大大降低了使用體驗。因此，跨應用數(shù)據(jù)共享這一需求逐漸呈現(xiàn)出越來越高的態(tài)勢，Google，F(xiàn)acebook，騰訊等各大互聯(lián)網(wǎng)廠商也相繼推出了自己的跨應用數(shù)據(jù)共享接口，使得用戶在不同網(wǎng)站之間能使用相同的用戶數(shù)據(jù)，在提高用戶數(shù)據(jù)安全性的同時也極大地方便了用戶的使用。

本文通過介紹跨應用授權協(xié)議OAuth及其運行機制，詳細闡述了不同應用之間數(shù)據(jù)的共享方式和其安全性保護措施，并列舉了OAuth 2.0協(xié)議在實施過程中容易出現(xiàn)的安全問題，最后對開發(fā)者提出了相應的安全性建議。

2 OAuth 2.0授權協(xié)議介紹

2.1 OAuth授權協(xié)議背景

開放授權（Open Authorization，OAuth）是一個開放的授權協(xié)議，其允許用戶讓第三方應用訪問自己在某一網(wǎng)站上存儲的私密資源（例如照片、視頻、聯(lián)系人等信息），而無需將用戶名和密碼提供給第三方應用。OAuth規(guī)定用戶必須使用一個訪問令牌來獲取存放在OAuth服務提供方的數(shù)據(jù)，每一個訪問令牌只對唯一一個第三方應用有效。如圖1所示為國內(nèi)開發(fā)者社區(qū)SegmentFault提供的Google，Github等平臺OAuth服務快速登錄接口。

OAuth的出現(xiàn)極大地方便了用戶在不同應用之間數(shù)據(jù)的共享需求。2010年4月，OAuth 1.0正式以RFC 5849的形式出現(xiàn)，后被全世界廣泛運用[1]。目前經(jīng)過多年的發(fā)展，OAuth授權協(xié)議已經(jīng)升級至2.0版本，其官方文檔也已更迭為RFC 6749。

2.2 OAuth 2.0運行流程

從RFC 6749當中可以看到OAuth 2.0的運行流程，如圖2所示。

圖中左側的Client（客戶端）為想要獲取用戶數(shù)據(jù)的第三方應用，右側的Resource owner、Authorization Server、Resource Server均為提供OAuth接口服務的Server（服務商）。因此整個OAuth 2.0的授權運行過程如下。

圖1 開發(fā)者社區(qū)SegmentFault快速登錄接口

圖2 OAuth 2.0運行流程

（1）用戶打開客戶端后客戶端要求給予授權。

（2）用戶同意給予客戶端授權。

（3）用戶使用上一步獲得的授權，向服務商授權服務器申請訪問令牌。

（4）服務商授權服務器對客戶端確認無誤后同意發(fā)放訪問令牌給客戶端。

（5）客戶端使用訪問令牌向服務商資源服務器獲取相應的數(shù)據(jù)。

（6）服務商資源服務器確認客戶端訪問令牌有效，向客戶端開放相應數(shù)據(jù)。

2.3 OAuth 2.0的4種授權方式

OAuth 2.0授權協(xié)議共有4種授權方式：Authorization code（授權碼）模式，Implicit（隱式）模式，Resource owner password credentials（賬號密碼）模式，Client credentials（客戶端）模式。其中，授權碼模式是目前OAuth 2.0中功能最完善、流程最嚴密的模式，因而被廣泛使用。這4種授權方式的流程分別如圖3—6所示。

圖3 Authorization code授權模式

圖4 Implicit授權模式

圖5 Resource owner password credentials授權模式

圖6 Client credentials授權模式

3 OAuth 2.0常見安全問題

OAuth 2.0本身是一套非常嚴密的結構，但是一些開發(fā)者在實現(xiàn)、部署OAuth授權服務的時候因為疏忽而產(chǎn)生了很多安全問題，這些問題一旦被利用，將導致嚴重的后果。下面就列舉一些OAuth 2.0授權協(xié)議在實現(xiàn)過程中容易造成的安全問題。

3.1 隱蔽重定向漏洞

2014年5月，新加坡南洋理工大學研究人員王晶發(fā)現(xiàn)，一些提供OAuth服務的網(wǎng)站在對第三方應用進行OAuth授權過程中未對回調(diào)的統(tǒng)一資源標識符（Uniform Resource Identifier，URI）進行驗證，導致回調(diào)的URI可以被修改為非原定URI，因此可以被用來釣魚，是一個明顯的跳轉漏洞。這一漏洞被命名為“Covert Redirect”即隱蔽重定向漏洞。

在國內(nèi)，該漏洞也被叫作OAuth redirect_uri回調(diào)污染。事實上該漏洞造成的危害不僅僅是可被用來釣魚攻擊，看下面的例子。假設某OAuth服務商使用授權碼模式進行第三方應用的授權服務，某個第三方應用可以通過該服務商的OAuth接口綁定賬號，以此來方便用戶登錄和使用。該客戶端綁定賬號的請求如下：

GET /authorize?which=Login&display=pc&response_type=code&client_id=100263567&redirect_uri=http://client.com/index.php/sign/callback&scope=get_user_info,add_pic_t,add_t HTTP/1.1

Host: server.com

現(xiàn)在某用戶已經(jīng)登錄了該第三方應用，攻擊者向他發(fā)送了如下一個URL：

http://server.com/authorize?which=Login&display=p c&response_type=code&client_id=100263567&redirect_uri=http://hacker.com/index.php&scope=get_user_info,add_pic_t,add_t

可以看出這是一個用于綁定賬號的URL，并且將用于回調(diào)的redirect_uri修改成自己控制的頁面http://hacker.com/index.php。此時，如果OAuth服務商存在隱蔽重定向漏洞，那么當該用戶點擊并授權以后頁面會跳轉至http://hacker.com/index.php?code=***。這時候該用戶的授權碼code將會被hacker.com捕獲便遭到了泄露。對于一些網(wǎng)站來說，授權碼code一旦泄露，將導致用戶賬號被劫持，國內(nèi)騰訊、新浪微博等OAuth服務均出現(xiàn)過此問題。同時，對于第三方應用來說，如果其自身存在XSS或者沒有做好頁面防嵌入，也同樣能造成授權碼code的泄露。

3.2 錯誤使用state參數(shù)導致CSRF

OAuth 2.0當中定義了一個state參數(shù)，根據(jù)RFC 6749，其含義為：

state:RECOMMENDED. An opaque value used by the client to maintain state between the request and callback.The authorization server includes this value when redirecting the user-agent back to the client.The parameter SHOULD be used for preventing cross-site request forgery as described in Section 10.12.

即該參數(shù)用于在授權過程中請求和回調(diào)階段的狀態(tài)保持，用于防止該過程中產(chǎn)生CSRF攻擊。然而事實卻是很多OAuth服務開發(fā)者忘記或錯誤使用state參數(shù)，造成大量用戶賬號被劫持的安全事件。國內(nèi)白帽子黑客horseluke給出了一個新浪微博的例子[2]。

某用戶在登錄了第三方網(wǎng)站a.com后想在該網(wǎng)站關聯(lián)并綁定自己的新浪微博賬號，于是就點擊了該網(wǎng)站上給出的“綁定微博”按鈕，該按鈕的URL為http://a.com/index.php?m=user_3rd

_bind_sina。該用戶點擊以后瀏覽器將用戶重定向至新浪微博OAuth授權頁面，URL為：http://

api.weibo.com/oaut h 2/aut hor i ze?cl ie nt_id=999999&redirect_uri=http://a.com/index.php?m=user_3rd_

bind_sina_callback&response_type=code。隨后用戶對a.com給予了授權，新浪微博授權服務器生成了授權碼code，瀏覽器將用戶重定向至http://a.com/index.php?m=user_3rd_bind_sina_callback&

code=809ui0asduve，此時完成了賬號綁定。

上述過程粗略地看并沒有問題，但事實上完成賬號綁定時的URL跟當前用戶沒有任何關系，因為該URL只能證明新浪微博用戶信息，但無法證明a.com的用戶信息?，F(xiàn)在如果有兩個用戶同時發(fā)起綁定請求，登錄到不同的微博賬號，隨后在獲取到授權碼code后雙方互相交換code，這將會導致兩個用戶綁定的新浪微博賬戶也發(fā)生交換和改變。黑客正是利用這一點實現(xiàn)了劫持用戶賬號的目的，而這一過程也體現(xiàn)了state參數(shù)的重要性[3]。

3.3 賬號體系控制不嚴造成任意登錄

2013年，國內(nèi)著名的音樂圈APP啪啪被發(fā)現(xiàn)存在任意賬號登錄的嚴重漏洞，這一問題是啪啪在使用OAuth授權服務時產(chǎn)生的[4]。啪啪客戶端為方便用戶使用，提供了使用新浪微博、QQ登錄的功能，登錄的大致流程為：

（1）用戶點擊使用新浪微博或QQ登錄，將彈出新浪微博或QQ的OAuth授權頁。（2）用戶授權以后啪啪客戶端獲得服務商提供的訪問令牌。（3）啪啪客戶端將訪問令牌移交給api.papa.me已獲取啪啪自己的認證字符串。（4）啪啪客戶端得到認證字符串后獲得操作該微博或QQ綁定的啪啪賬號權限。

漏洞發(fā)現(xiàn)者在測試過程中，將第二步獲得的訪問令牌替換為其他應用在OAuth服務商獲得的訪問令牌，隨后繼續(xù)進行第三步和第四步，結果發(fā)現(xiàn)登錄了另一個啪啪賬號。該漏洞的關鍵在于當啪啪通過OAuth服務商獲得授權信息（訪問令牌、令牌有效期等）后，是將其作為參數(shù)匹配到自己的賬號并自動登錄或自動注冊的。由于后續(xù)的匹配處理邏輯出現(xiàn)紕漏，甚至無驗證機制，就直接導致了啪啪賬號的任意登錄。

4 OAuth 2.0安全建議

可見，無論OAuth 2.0是多么嚴密安全的流程，對于OAuth服務商和其使用者來說，錯誤的實現(xiàn)和運用都可能會引發(fā)嚴重的漏洞，以至于大量用戶數(shù)據(jù)和信息也將面臨被劫持泄露的風險。針對目前發(fā)生過的一些安全問題，本文對于OAuth在實現(xiàn)和運用過程中有以下安全建議。

4.1 保護授權過程中的回調(diào)URI

為了防止OAuth授權過程產(chǎn)生隱蔽重定向漏洞和redirect_uri回調(diào)污染，OAuth服務商應當對redirect_uri進行全路徑校驗，避免產(chǎn)生跳轉漏洞。同時要加強驗證過程和邏輯，避免被繞過。

4.2 驗證授權過程中的第三方應用

為了防止訪問令牌泄露，應當驗證OAuth授權過程中的授權請求來源信息、第三方應用信息。例如在Resource owner password credentials（賬號密碼）授權模式中，用戶將在OAuth服務商的個人賬戶密碼移交給了第三方應用，如果第三方應用不被信任，則會產(chǎn)生用戶數(shù)據(jù)泄露的風險[5]。

4.3 正確使用state參數(shù)以防止CSRF

使用OAuth的第三方應用應當按照官方文檔的描述，在請求授權和回調(diào)過程中正確使用state參數(shù)以防止產(chǎn)生CSRF漏洞，該參數(shù)與anti csrf token類似，要做到隨機不可預測。

4.4 驗證OAuth使用者信息

使用OAuth的第三方應用需要考慮在自動登錄或者自動注冊的過程中，驗證OAuth服務商返回的授權信息，同時要驗證該授權信息例如訪問令牌是否為指定來源應用所頒發(fā)。第三方應用如果發(fā)現(xiàn)了訪問令牌中的服務商給出的uid和自己在服務商綁定的uid不一致、非自身應用appkey授權的訪問令牌、過期訪問令牌等異常情況均需要全部撤銷，并且要求這些異常用戶重新授權登錄。

4.5 避免不可信第三方應用強制使用Implicit授權模式

由于一些OAuth服務商在Implicit授權模式中直接將訪問令牌放進回調(diào)URL，這就增加了訪問令牌泄露的風險，因此OAuth服務商應當避免第三方應用強制更換授權方式為Implicit模式。

[參考文獻]

[1]佚名.RFC 6749.[EB/OL].（2017-12-29）[2018-03-05].http://www.rfc-editor.org/rfc/rfc6749.txt.

[2]阮一峰. 理解OAuth 2.0[EB/OL].（2014-05-12）[2018-03-05].http://www.ruanyifeng.com/blog/2014/05/oauth_2_0.html

[3]維基百科.OAuth概念解析[EB/OL].（2017-02-15）[2018-03-05].https://en.wikipedia.org/wiki/OAuth.

[4]HORSELUKE.OAuth 2.0安全案例回顧[EB/OL].（2014-03-11）[2018-03-05].http://wooyun.jozxing.cc/static/drops/papers-598.html.

[5]∑-TEAM.OAuth安全指南[EB/OL].（2014-05-13）[2018-03-05].http://wooyun.jozxing.cc/static/drops/papers-1989.html.