作為第三方應(yīng)用，為了提升用戶體驗(yàn)，往往會提供第三方社交賬號登錄或者綁定的功能，這背后使用到的關(guān)鍵技術(shù)是OAuth認(rèn)證。想要在自己的應(yīng)用里集成OAuth不是難事兒，各大社交網(wǎng)站都提供了詳盡的文檔指南。

OAuth的復(fù)雜度比較高，有不少安全方面的坑，開發(fā)者在使用過程中一不注意可能就會掉進(jìn)去，比如說不正確的使用OAuth2可能會遭遇到CSRF攻擊。本文將對這個(gè)安全風(fēng)險(xiǎn)做一個(gè)通俗易懂的解釋。

OAuth2 授權(quán)模式回顧

在開始之前，讓我們先來回顧一下OAuth2中最典型的Authorization Code 授權(quán)模式，其大致流程如下：

OAuth2 Authorization Code Flow

我們把OAuth2的整個(gè)認(rèn)證過程大致分為三個(gè)階段。

• 第一階段主要是向用戶取得授權(quán)許可，對應(yīng)圖中的第1、2、3步;
• 第二階段主要是申請?jiān)L問令牌(access_token)，對應(yīng)圖中的第4、5步;
• 第三階段就是使用access_token獲取用戶數(shù)據(jù)。

這一過程中涉及了不少敏感參數(shù)和數(shù)據(jù)，例如client_secret相當(dāng)于是第三方應(yīng)用自己的密碼，access_token某種程度上來講就是用戶的session id。由于這些參數(shù)以及數(shù)據(jù)極其特殊，我們當(dāng)然得確保它們的安全性，HTTPS加密傳輸以及安全存儲是必不可少的防護(hù)手段。不過僅僅做到這些是遠(yuǎn)遠(yuǎn)不夠的，在這個(gè)流程里存在一個(gè)弱點(diǎn)，容易被攻擊者利用進(jìn)行CSRF攻擊。

針對OAuth2的CSRF攻擊

1. 攻擊流程

讓我們來看一個(gè)針對OAuth2的CSRF攻擊的例子。假設(shè)有用戶張三，和攻擊者李四，還有一個(gè)第三方Web應(yīng)用Tonr，它集成了第三方社交賬號登錄，并且允許用戶將社交賬號和Tonr中的賬號進(jìn)行綁定。此外還有一個(gè)OAuth2服務(wù)提供者Sparklr。

模擬攻擊案例中涉及的角色

Step 1. 攻擊者李四登錄Tonr網(wǎng)站，并且選擇綁定自己的Sparklr賬號。

Step 2. Tonr網(wǎng)站將李四重定向到Sparklr，由于他之前已經(jīng)登錄過Sparklr，所以Sparklr直接向他顯示“是否授權(quán)Tonr訪問”的頁面。

Step 3. 李四在點(diǎn)擊”同意授權(quán)“之后，截獲Sparklr服務(wù)器返回的含有Authorization Code參數(shù)的HTTP響應(yīng)。

Step 4. 李四精心構(gòu)造一個(gè)Web頁面，它會觸發(fā)Tonr網(wǎng)站向Sparklr發(fā)起令牌申請的請求，而這個(gè)請求中的Authorization Code參數(shù)正是上一步截獲到的code。

Step 5. 李四將這個(gè)Web頁面放到互聯(lián)網(wǎng)上，等待或者誘騙受害者張三來訪問。

Step 6. 張三之前登錄了Tonr網(wǎng)站，只是沒有把自己的賬號和其他社交賬號綁定起來。在張三訪問了李四準(zhǔn)備的這個(gè)Web頁面后，令牌申請流程在張三的瀏覽器里被順利觸發(fā)，Tonr網(wǎng)站從Sparklr那里獲取到access_token，但是這個(gè)token以及通過它進(jìn)一步獲取到的用戶信息卻都是攻擊者李四的。

Step 7. Tonr網(wǎng)站將李四的Sparklr賬號同張三的Tonr賬號關(guān)聯(lián)綁定起來，從此以后，李四就可以用自己的Sparklr賬號通過OAuth登錄到張三在Tonr網(wǎng)站中的賬號，堂而皇之的冒充張三的身份執(zhí)行各種操作。

等等，這一切發(fā)生得太快，還沒看清楚李四怎么就登錄到張三的賬號里去了。沒關(guān)系，讓我們從幾個(gè)不同的角度來看看這當(dāng)中發(fā)生了什么。

[[199150]]

2. 受害者張三(Resource Owner)視角

受害者張三訪問了一個(gè)Web頁面，然后，就沒有然后了，他在Tonr網(wǎng)站上的賬號就和攻擊者李四在Sparklr上的賬號綁定到了一起。偽造的請求是經(jīng)過精心構(gòu)造的，令牌申請這一過程在張三的瀏覽器里是非常隱蔽的被觸發(fā)的，換句話講就是，他根本不知道這背后發(fā)生了什么。

3. Tonr網(wǎng)站(Client)視角

從Tonr網(wǎng)站來看，它收到的所有請求看上去都是正常的。首先它收到了一個(gè)HTTP請求，其代表著當(dāng)前用戶張三在Sparklr網(wǎng)站上已經(jīng)做了“同意授權(quán)”操作。其內(nèi)容如下：

GET /bindingCallback?code=AUTHORIZATION_CODE 

不過需要注意的是，URL里的code不是當(dāng)前受害者張三的Authorization Code，而是攻擊者李四的。

當(dāng)Tonr收到這樣的請求時(shí)，它以為張三已經(jīng)同意授權(quán)(但實(shí)際上這個(gè)請求是李四偽造的)，于是就發(fā)起后續(xù)的令牌申請請求，用收到的Authorization Code向Sparklr換取access_token，只不過最后拿到的是攻擊者李四的 access_token。

最后，Tonr網(wǎng)站把攻擊者李四的access_token和當(dāng)前受害者張三在Tonr網(wǎng)站上的賬號進(jìn)行關(guān)聯(lián)綁定。

4. Sparklr網(wǎng)站(OAuth2服務(wù)提供者)視角

Sparklr網(wǎng)站也是一臉茫然的樣子，因?yàn)樵谒磥恚约菏盏降氖跈?quán)請求，以及后續(xù)的令牌申請請求都是正常的，或者說它無法得知接收到的這些請求之間的關(guān)聯(lián)關(guān)系，而且也無法區(qū)別出這些請求到底是來自張三本人，還是由李四偽造出來的。因此只要自己收到的參數(shù)是正確有效的，那就提供正常的認(rèn)證服務(wù)，僅此而已。

5. 攻擊者李四視角

李四偽造了一個(gè)用戶授權(quán)成功的請求，并且將其中的Authorization Code參數(shù)替換成了自己提前獲取到的code。這樣，當(dāng)受害者張三的瀏覽器被欺騙從而發(fā)起令牌申請請求時(shí)，實(shí)際上是在用張三在Tonr網(wǎng)站上的賬號和李四在Sparklr網(wǎng)站上的賬號做綁定。

攻擊完成后，李四在Tonr網(wǎng)站上可以通過自己在Sparklr網(wǎng)站的賬號進(jìn)行登錄，而且登錄進(jìn)入的是張三在Tonr網(wǎng)站上的賬號。而張三通過自己在Tonr網(wǎng)站上的賬號登錄進(jìn)去之后，看到的是李四在Sparklr網(wǎng)站上的數(shù)據(jù)。

6. 上帝視角

從整體上來看，這次攻擊的時(shí)序圖應(yīng)該是下面這個(gè)樣子的：

攻擊時(shí)序圖示

漏洞的本質(zhì)

這個(gè)問題的關(guān)鍵點(diǎn)在于，OAuth2的認(rèn)證流程是分為好幾步來完成的，在圖1中的第4步，第三方應(yīng)用在收到一個(gè)GET請求時(shí)，除了能知道當(dāng)前用戶的cookie，以及URL中的Authorization Code之外，難以分辨出這個(gè)請求到底是用戶本人的意愿，還是攻擊者利用用戶的身份偽造出來的請求。 于是乎，攻擊者就能使用移花接木的手段，提前準(zhǔn)備一個(gè)含有自己的Authorization Code的請求，并讓受害者的瀏覽器來接著完成后續(xù)的令牌申請流程。

前提條件

盡管這個(gè)攻擊既巧妙又隱蔽，但是要成功進(jìn)行這樣的CSRF攻擊也是需要滿足一定前提條件的。

首先，在攻擊過程中，受害者張三在Tonr網(wǎng)站上的用戶會話(User Session)必須是有效的，也就是說，張三在受到攻擊前已經(jīng)登錄了Tonr網(wǎng)站。

其次，整個(gè)攻擊必須在短時(shí)間內(nèi)完成，因?yàn)镺Auth2提供者頒發(fā)的Authorization Code有效期很短，OAuth2官方推薦的時(shí)間是不大于10分鐘，而一旦Authorization Code過期那么后續(xù)的攻擊也就不能進(jìn)行下去了。

最后，一個(gè)Authorization Code只能被使用一次，如果OAuth2提供者收到重復(fù)的Authorization Code，它會拒絕當(dāng)前的令牌申請請求。不止如此，根據(jù)OAuth2官方推薦，它還可以把和這個(gè)已經(jīng)使用過的Authorization Code相關(guān)聯(lián)的access_token全部撤銷掉，進(jìn)一步降低安全風(fēng)險(xiǎn)。

[[199151]]

防御辦法

要防止這樣的攻擊其實(shí)很容易，作為第三方應(yīng)用的開發(fā)者，只需在OAuth認(rèn)證過程中加入state參數(shù)，并驗(yàn)證它的參數(shù)值即可。具體細(xì)節(jié)如下：

(1) 在將用戶重定向到OAuth2的Authorization Endpoint去的時(shí)候，為用戶生成一個(gè)隨機(jī)的字符串，并作為state參數(shù)加入到URL中。

(2) 在收到OAuth2服務(wù)提供者返回的Authorization Code請求的時(shí)候，驗(yàn)證接收到的state參數(shù)值。如果是正確合法的請求，那么此時(shí)接受到的參數(shù)值應(yīng)該和上一步提到的為該用戶生成的state參數(shù)值完全一致，否則就是異常請求。

(3) state參數(shù)值需要具備下面幾個(gè)特性：

• 不可預(yù)測性：足夠的隨機(jī)，使得攻擊者難以猜到正確的參數(shù)值
• 關(guān)聯(lián)性：state參數(shù)值和當(dāng)前用戶會話(user session)是相互關(guān)聯(lián)的
• 唯一性：每個(gè)用戶，甚至每次請求生成的state參數(shù)值都是唯一的
• 時(shí)效性：state參數(shù)一旦被使用則立即失效

總結(jié)

要避免遭受本文提到的CSRF攻擊問題，需要第三方應(yīng)用正確的使用state參數(shù)，然而縱觀各大OAuth服務(wù)提供者，在其開發(fā)文檔里都沒有明確把state參數(shù)和CSRF攻擊聯(lián)系起來，僅僅只是像下面這樣一句話帶過：

讓事情變得更糟糕的是，state是可選參數(shù)，因此更容易被開發(fā)者忽略，造成安全風(fēng)險(xiǎn)。此外，本文中的攻擊非常巧妙，可以悄無聲息的攻陷受害者的賬號，難以被察覺到。

作為第三方應(yīng)用的開發(fā)者，我們除了參考OAuth2服務(wù)提供者的開發(fā)文檔之外，還應(yīng)當(dāng)加深自己對OAuth2的理解，盡可能的避開這些安全的坑。 而作為OAuth2服務(wù)提供者，也應(yīng)當(dāng)承擔(dān)起提醒開發(fā)者注意防范安全風(fēng)險(xiǎn)的責(zé)任。

【本文是51CTO專欄作者“ThoughtWorks”的原創(chuàng)稿件，微信公眾號：思特沃克，轉(zhuǎn)載請聯(lián)系原作者】

戳這里，看該作者更多好文