【51CTO.com快譯】面對(duì)常見的OWASP十大威脅、未經(jīng)授權(quán)的訪問、拒絕服務(wù)攻擊、以及竊取機(jī)密數(shù)據(jù)等類型的攻擊，企業(yè)需要使用通用的安全框架，來(lái)保護(hù)其REST API，并保證良好的用戶使用體驗(yàn)。本文向您介紹四種類型的API安全保護(hù)方式。

管理好API安全性

API的安全性涉及到各種端到端的數(shù)據(jù)保護(hù)，它們依次包括：來(lái)自客戶端的請(qǐng)求經(jīng)由網(wǎng)絡(luò)到達(dá)服務(wù)器/后端，由服務(wù)器/后端發(fā)送相應(yīng)的響應(yīng)，響應(yīng)橫跨網(wǎng)絡(luò)，最后到達(dá)客戶端，這一系列的過(guò)程。因此，API的安全性可以大致分為如下四種不同的類別，我們將逐一進(jìn)行詳細(xì)討論：

(1)傳輸中的數(shù)據(jù)安全

• 保護(hù)客戶端與API網(wǎng)關(guān)之間的動(dòng)態(tài)數(shù)據(jù)
• 保護(hù)API網(wǎng)關(guān)與后端服務(wù)之間的動(dòng)態(tài)數(shù)據(jù)

(2)訪問控制與抵御拒絕服務(wù)(DoS)攻擊

(3)身份驗(yàn)證與授權(quán)：使用OAuth2.0或OpenID Connect，來(lái)可靠地識(shí)別最終用戶的信息

(4)數(shù)據(jù)保密與屏蔽個(gè)人身份信息(Personally Identifiable Information，PII)

下圖描述了上述分類，以及各種端到端的數(shù)據(jù)保護(hù)方法：

1. 傳輸中的數(shù)據(jù)安全

對(duì)于所有公共且不受保護(hù)的API來(lái)說(shuō)，我們必須用到TLS。如今隨著硬件的進(jìn)步，TLS的實(shí)施開銷幾乎可以忽略不計(jì)了，而且隨著延遲在逐漸減小，越來(lái)越多的最終用戶會(huì)處于安全考慮而選用TLS?？偟恼f(shuō)來(lái)，TLS具有如下主要特點(diǎn)：

• TLS應(yīng)當(dāng)在北向(northbound)和南向(southbound)端點(diǎn)同時(shí)實(shí)施。
• 應(yīng)確保使用TLS的最新版本，并對(duì)客戶端、API網(wǎng)關(guān)和目標(biāo)后端予以支持。
• 證書密鑰、以及信任憑證的存儲(chǔ)都應(yīng)該受到高度保護(hù)和加密。
• 只有經(jīng)過(guò)授權(quán)的用戶才能訪問證書密鑰、以及信任憑證。

2. 訪問控制與抵御拒絕服務(wù)(DoS)攻擊

(1) 網(wǎng)絡(luò)級(jí)別的防御:如果API網(wǎng)關(guān)被托管在云端，則需要使用由云服務(wù)商所提供的 DDoS防御機(jī)制，例如：由Apigee(Google)所運(yùn)營(yíng)的Apigee Edge托管云平臺(tái)、 GCP(Google云平臺(tái))和AWS(Amazon Web)，它們都提供了網(wǎng)絡(luò)級(jí)別的DDoS防御。

(2) 內(nèi)容交付網(wǎng)絡(luò)：像Akamai、Neustar和Rackspace之類的CDN，都可以用于緩解那些對(duì)于API的DDoS攻擊。

(3) “僵尸”檢測(cè)：如今各大API管理平臺(tái)都已經(jīng)針對(duì)僵尸/機(jī)器人類型的攻擊，推出了檢測(cè)API流量，識(shí)別各種惡意/非必要請(qǐng)求，并生成警報(bào)/阻止惡意請(qǐng)求到達(dá)的API網(wǎng)關(guān)服務(wù)。例如：Apigee(Google)提供了一種稱為“Apigee Sense”的檢測(cè)服務(wù)。它是一種智能數(shù)據(jù)驅(qū)動(dòng)的API安全產(chǎn)品，它可以通過(guò)自動(dòng)識(shí)別各種可疑的API客戶端行為，以提供額外的保護(hù)層。同時(shí)，管理員也可以在此基礎(chǔ)上通過(guò)糾正性措施，來(lái)保證用戶的體驗(yàn)度，以及后端系統(tǒng)的安全性。

(4) 策略執(zhí)行：我們應(yīng)該在位于API客戶端和客戶后端之間的API代理上，通過(guò)強(qiáng)制實(shí)施各種策略，以嚴(yán)格管控合法用戶對(duì)于API的訪問。如下策略能夠在一定程度上保護(hù)API免受惡意黑客的攻擊：

• API速率限制：通過(guò)限速，我們可以減少大量導(dǎo)致拒絕服務(wù)的API請(qǐng)求，并抑制暴力攻擊和服務(wù)濫用。特別是在API代理服務(wù)器上，我們可以采用如下限速的機(jī)制：
• 基于應(yīng)用程序或個(gè)別API予以限速，以保證每個(gè)API或應(yīng)用程序只能按照固定的請(qǐng)求數(shù)配額，去訪問對(duì)應(yīng)的服務(wù)。
• 基于GET或POST請(qǐng)求予以限速，當(dāng)然具體的請(qǐng)求數(shù)設(shè)定，可以根據(jù)不同時(shí)段的GET或POST量而有所不同。

(5) 正則表達(dá)式保護(hù)：應(yīng)當(dāng)根據(jù)預(yù)定義的正則表達(dá)式(如DELETE、UPDATE和EXECUTE)來(lái)評(píng)估入棧請(qǐng)求的URI路徑、查詢參數(shù)、包頭、表格參數(shù)、變量、XML有效負(fù)載、以及JSON負(fù)載。任何匹配上了預(yù)定義表達(dá)式的請(qǐng)求都將被視為威脅，并被立即拒絕掉。請(qǐng)參閱OWASP top 10(https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project#OWASP_Top_10_for_2013)，以了解具體有關(guān)要如何驗(yàn)證正則表達(dá)式的信息。

(6) JSON輸入驗(yàn)證：對(duì)于PUT/POST/DELETE之類請(qǐng)求的負(fù)載，我們應(yīng)執(zhí)行JSON驗(yàn)證，以通過(guò)指定對(duì)于各種JSON結(jié)構(gòu)的限制(如最大深度、對(duì)象的最大數(shù)量、最長(zhǎng)字符串長(zhǎng)度的名稱、以及數(shù)組中所允許的最大元素?cái)?shù)等)，來(lái)最小化可能受到的攻擊面。

(7) XML輸入驗(yàn)證：應(yīng)當(dāng)對(duì)PUT/POSTE/DELETE之類請(qǐng)求的負(fù)載執(zhí)行XML驗(yàn)證。具體可使用如下方法來(lái)根據(jù)配置的限制，以檢測(cè)XML負(fù)載的各類攻擊、以及監(jiān)控針對(duì)XML的威脅：

• 根據(jù)XML的架構(gòu)(.xsd)來(lái)驗(yàn)證消息
• 根據(jù)特定黑名單里的關(guān)鍵字與模式，來(lái)評(píng)估消息內(nèi)容
• 在分析消息之前，檢測(cè)出已損壞或格式錯(cuò)誤的消息

(8) 驗(yàn)證請(qǐng)求

• 驗(yàn)證輸入HTTP動(dòng)詞：適當(dāng)?shù)貙?duì)那些允許類動(dòng)詞做出限制，而對(duì)于其他所有動(dòng)詞，則返回相應(yīng)的響應(yīng)代碼(如：“403禁止錯(cuò)誤”)。
• 驗(yàn)證包頭：應(yīng)當(dāng)根據(jù)API所支持的功能，顯式地驗(yàn)證“內(nèi)容類型”、“接受”和“內(nèi)容長(zhǎng)度”等包頭。此外，還應(yīng)該執(zhí)行針對(duì)強(qiáng)制性包頭(如：授權(quán)、以及特定類型的API包頭)的驗(yàn)證。
• 驗(yàn)證入棧內(nèi)容類型：對(duì)于PUT/POST/DELETE之類入棧請(qǐng)求的內(nèi)容類型(例如：應(yīng)用/XML或應(yīng)用/JSON)、以及內(nèi)容類型的包頭值進(jìn)行驗(yàn)證。對(duì)于缺少內(nèi)容類型的包頭、或異常內(nèi)容類型的包頭，應(yīng)當(dāng)直接拒絕，并返回“406不可接受”的響應(yīng)內(nèi)容。
• 驗(yàn)證響應(yīng)類型：不要簡(jiǎn)單地將“接受”包頭復(fù)制到響應(yīng)內(nèi)容類型的包頭中。如果“接受”包頭中并沒有明確地包含允許的類型，應(yīng)當(dāng)直接拒絕該請(qǐng)求，并返回“406不可接受”的響應(yīng)內(nèi)容。
• 處置不支持的資源：適當(dāng)通過(guò)限制資源，只開放可供調(diào)用的資源;而對(duì)于其他所有未實(shí)現(xiàn)的資源，則應(yīng)返回“未知資源”之類相應(yīng)的響應(yīng)代碼。

(9) 訪問控制：通過(guò)配置策略，只允許來(lái)自特定IP地址、域名或區(qū)域的請(qǐng)求。而那些未通過(guò)此類條件的請(qǐng)求，應(yīng)當(dāng)被網(wǎng)關(guān)直接拒絕掉。

3. 身份驗(yàn)證和授權(quán)

通常情況下，身份驗(yàn)證和授權(quán)是同步發(fā)生的。

• 身份驗(yàn)證常被用于識(shí)別最終用戶。
• 授權(quán)則被用于授予已識(shí)別用戶訪問某些資源的權(quán)限。

在API領(lǐng)域中，OAuth和OpenID Connect是最為常用的機(jī)制。它們通過(guò)利用現(xiàn)有的IAM架構(gòu)，并以交換訪問令牌的方式，來(lái)驗(yàn)證用戶的身份，進(jìn)而保護(hù)API的各個(gè)端點(diǎn)。通過(guò)OAuth和OpenID Connect，我們不需要每次都構(gòu)建單獨(dú)的系統(tǒng)，以存儲(chǔ)用戶名和密碼的方式，來(lái)匹配用戶可以訪問的API資源。

(1) OpenID與OAuth的歷史

(2) OAuth

OAuth通常采用不透明(OPAQUE)令牌，來(lái)實(shí)現(xiàn)委托訪問(Delegated Access)的目的。OAuth2.0授權(quán)框架使得第三方應(yīng)用能夠獲得對(duì)于HTTP服務(wù)的有限訪問權(quán)限。通常，用戶不應(yīng)當(dāng)為了訪問某些存儲(chǔ)在第三方的受保護(hù)數(shù)據(jù)，而在公網(wǎng)上傳輸自己的密碼。而OAuth恰好能夠?yàn)橛脩粼L問自己的數(shù)據(jù)，提供了信任憑據(jù)的安全保護(hù)。

OAuth不是一種身份驗(yàn)證協(xié)議，而是授權(quán)協(xié)議。由于身份驗(yàn)證通常發(fā)生在頒發(fā)訪問令牌之前，因此我們很容易理解為在接受訪問令牌時(shí)，也進(jìn)行了身份驗(yàn)證。然而，僅憑擁有訪問令牌，并不能證明用戶的身份。在OAuth中，令牌被設(shè)計(jì)為對(duì)客戶端來(lái)說(shuō)是不透明的，客戶端僅能從令牌中獲取權(quán)限信息，而不會(huì)涉及到用戶名與密碼。

不透明令牌:在許多的具體實(shí)現(xiàn)中，OAuth2.0會(huì)返回OPAQUE字符串，用以換取被稱為訪問令牌的用戶憑據(jù)，而這些令牌將被進(jìn)一步用于訪問各種API的資源。不透明令牌并非用來(lái)存儲(chǔ)用戶身份標(biāo)識(shí)與信息，而是指向了某個(gè)數(shù)據(jù)庫(kù)里的具體數(shù)據(jù)項(xiàng)。例如：我們可以用Redis來(lái)存儲(chǔ)各種鍵-值(key-value)。而Cassandra之類的NoSQL數(shù)據(jù)庫(kù)則非常適合利用內(nèi)存中的哈希表，根據(jù)I/O來(lái)查找有效負(fù)載。由于用戶角色是直接從數(shù)據(jù)庫(kù)中被讀出的，因此我們可以通過(guò)更改后端的角色，來(lái)傳遞并展現(xiàn)給用戶。

(3) OpenID Connect

OpenID Connect采用ID令牌和訪問令牌，來(lái)實(shí)現(xiàn)用戶識(shí)別與委托訪問。OpenID Connect是進(jìn)行用戶身份驗(yàn)證的標(biāo)準(zhǔn)。由于直接構(gòu)建在OAuth2.0之上，因此在大多數(shù)情況下，OpenID Connect是與OAuth架構(gòu)一起被部署的。在交付形式上，它還為客戶端提供OpenID Connect令牌。該身份令牌是一個(gè)已簽名的JSON Web令牌(JWT)，它與常規(guī)的OAuth訪問令牌一起被提交給客戶端應(yīng)用程序。

• JSON Web令牌：JWT令牌實(shí)際上是一個(gè)完整的JSON對(duì)象。它經(jīng)歷了base64編碼之后，使用對(duì)稱共享密鑰、或公/私鑰的方式進(jìn)行簽名。JWT可以包含諸如：主題、user_id、令牌頒發(fā)時(shí)間、以及過(guò)期時(shí)間等信息。通過(guò)密鑰簽名，它可以確保只對(duì)擁有授權(quán)訪問密鑰的系統(tǒng)才能生成令牌。不過(guò)值得注意的是，系統(tǒng)在對(duì)JWT進(jìn)行簽名時(shí)，JWT通常不會(huì)被加密(當(dāng)然，您也可以選擇對(duì)其進(jìn)行加密)。那么，這就意味著任何擁有令牌訪問權(quán)限的人都可以讀取令牌里的數(shù)據(jù)。因此，業(yè)界的最佳實(shí)踐是：只把用戶標(biāo)識(shí)(如user_id)放在令牌中，而不是個(gè)人身份信息(如電子郵件或社會(huì)保障號(hào)碼)。此外，它們應(yīng)當(dāng)通過(guò)TLS之類的加密通道來(lái)進(jìn)行傳遞。
• JWT限制：鑒于日常對(duì)于用戶的禁用、以及添加或刪除角色往往需要一段時(shí)間才能同步生效，而且由于令牌存儲(chǔ)在客戶端，即使我們?cè)跀?shù)據(jù)庫(kù)中對(duì)其所頒發(fā)的JWT用戶進(jìn)行了禁用標(biāo)記的話，也無(wú)法直接讓該令牌及時(shí)無(wú)效。雖然JWT采取了預(yù)定義到期的機(jī)制，但是用戶仍然需要等待到期。顯然這會(huì)影響到用戶的服務(wù)架構(gòu)，特別是那些電商類的應(yīng)用。

當(dāng)然，業(yè)界也提供了一些變通的方法。例如：您可以使用帶有令牌或user_id的黑名單，但是這需要向數(shù)據(jù)庫(kù)引入新的認(rèn)證機(jī)制。因此，一種推薦的方法是：通過(guò)黑名單以確保每個(gè)令牌都帶有一個(gè)JTI聲明(或帶有一個(gè)存儲(chǔ)在數(shù)據(jù)庫(kù)中的JWT Id)。因此，只要您希望注銷的令牌數(shù)量遠(yuǎn)小于應(yīng)用程序中的用戶數(shù)量，那么操作起來(lái)就非常靈活。

可見，對(duì)于那些擁有管理員、項(xiàng)目所有者、服務(wù)客戶經(jīng)理等多種角色的企業(yè)應(yīng)用來(lái)說(shuō)，切換用戶的不同角色并不會(huì)對(duì)JWT立即生效。例如：管理員修改了某個(gè)授權(quán)用戶的角色，那么只要他不去刷新JWT，也就無(wú)法獲悉該變更。

下面是OpenID Connect的三種實(shí)現(xiàn)用例：

• 出棧方向的Web單一登錄(SSO)：向企業(yè)用戶提供對(duì)于SaaS應(yīng)用、以及合作伙伴應(yīng)用的訪問管控，但并不公開本企業(yè)的用戶名與密碼。
• 入棧方向的Web單一登錄：允許社交賬號(hào)/第三方登錄，但無(wú)需存儲(chǔ)外部用戶與密碼。
• 實(shí)現(xiàn)各種本地應(yīng)用的原生單一登錄。

OAuth和OpenID Connect都支持OAuth2規(guī)范所指定的四種授權(quán)類型，下圖描述了其中一種授權(quán)流程圖。API開發(fā)人員可以根據(jù)手頭項(xiàng)目所需的約束與實(shí)現(xiàn)方案，來(lái)選用不同的授權(quán)類型。

4. 數(shù)據(jù)保密與屏蔽個(gè)人身份信息

眾所周知，由于密碼、安全令牌和API密鑰包含了不同程度的內(nèi)部信息，它們不應(yīng)該出現(xiàn)在URL中，或者被Web服務(wù)器的日志所捕獲。此外，諸如UserID、密碼、帳號(hào)、信用卡號(hào)碼等個(gè)人身份信息，也應(yīng)該處于“被打碼”的狀態(tài)，哪怕是在交易和審計(jì)日志中。

公共API的安全實(shí)踐

由于獨(dú)立于任何用戶，因此公共API的設(shè)計(jì)初衷就是為了公開各種非敏感、以及只讀的數(shù)據(jù)(例如天氣類API)，當(dāng)然也就不必添加任何身份驗(yàn)證與授權(quán)環(huán)節(jié)。不過(guò)，我建議您通過(guò)如下的方面，來(lái)打造能夠應(yīng)對(duì)各種威脅與濫用的API：

• 在IP地址級(jí)別上應(yīng)用速率限制的相關(guān)策略。
• 使用API密鑰驗(yàn)證的方式。通過(guò)存儲(chǔ)在網(wǎng)關(guān)上的方式，保證API的密鑰不會(huì)被公布給任何客戶端。因此，當(dāng)拒絕服務(wù)攻擊使用無(wú)效密鑰訪問API、或是在其他策略已無(wú)法阻斷黑客攻擊時(shí)，API密鑰驗(yàn)證方式能夠有效地發(fā)揮作用。
• 采用配額策略(單個(gè)或多種配額機(jī)制)，來(lái)實(shí)現(xiàn)API的使用限制。
• 如果API被用于特定地理區(qū)域的服務(wù)器進(jìn)行通信，那么就應(yīng)當(dāng)在地理級(jí)別上(縣/區(qū)等)采取IP地址的篩選。
• 開發(fā)人員應(yīng)盡量采用一次性注冊(cè)的方式，并使用自己的API密鑰去調(diào)用API。

結(jié)論

在企業(yè)內(nèi)部、以及企業(yè)之間需要集成不同的應(yīng)用時(shí)，開發(fā)人員能夠通過(guò)API來(lái)快速且方便地予以實(shí)現(xiàn)。不過(guò)，如果沒有恰當(dāng)?shù)乇Ｗo(hù)好API，那么就會(huì)讓整個(gè)企業(yè)面臨各種風(fēng)險(xiǎn)與威脅。因此，我們需要在開發(fā)和實(shí)施之前，就對(duì)API的安全性進(jìn)行良好的構(gòu)建和設(shè)計(jì)，從而提高企業(yè)的整體安全態(tài)勢(shì)。

原文標(biāo)題：Ensuring the Security of Your APIs?，作者：Vivek Yadav

【51CTO譯稿，合作站點(diǎn)轉(zhuǎn)載請(qǐng)注明原文譯者和出處為51CTO.com】