盗墓笔记同人小说,雪鹰领主

新聞中心

這里有您想知道的互聯(lián)網(wǎng)營銷解決方案

如何構(gòu)建和設(shè)計以確保 API 的安全性

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

管理好API安全性

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

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

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

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

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

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

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

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

對于所有公共且不受保護的API來說，我們必須用到TLS。如今隨著硬件的進步，TLS的實施開銷幾乎可以忽略不計了，而且隨著延遲在逐漸減小，越來越多的最終用戶會處于安全考慮而選用TLS。總的說來，TLS具有如下主要特點：

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

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

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

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

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

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

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

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

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

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

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

(8) 驗證請求

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

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

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

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

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

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

(1) OpenID與OAuth的歷史

(2) OAuth

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

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

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

(3) OpenID Connect

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

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

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

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

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

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

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

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

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

公共API的安全實踐

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

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

結(jié)論

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

當(dāng)前標(biāo)題：如何構(gòu)建和設(shè)計以確保 API 的安全性
文章路徑：http://fisionsoft.com.cn/article/cdejocj.html

新聞中心

其他資訊