???

作者丨Artem Arzamas

譯者丨陳峻

策劃丨孫淑娟

【51CTO.com快譯】本文簡(jiǎn)單回顧了 API 的發(fā)展歷史，其基本概念、功能、相關(guān)協(xié)議、以及使用場(chǎng)景，重點(diǎn)討論了與之相關(guān)的不同安全要素、威脅、認(rèn)證方法、以及十二項(xiàng)優(yōu)秀實(shí)踐。

根據(jù)有記錄的歷史，隨著 Salesforce 的銷(xiāo)售自動(dòng)化解決方案的推出，首個(gè) Web API 在 1990 年底出現(xiàn)了。在那個(gè)時(shí)候，它是一種每個(gè)人都可以訪問(wèn)到的開(kāi)放資源。Salesforce 的自動(dòng)化工具由 XML 驅(qū)動(dòng)。而用于交換該工具信息的數(shù)據(jù)格式，后來(lái)被公認(rèn)為 SOAP API 標(biāo)準(zhǔn)。它擁有與允許或禁止各種請(qǐng)求相關(guān)聯(lián)的消息格式規(guī)范、以及特定于代碼的規(guī)則。也就是說(shuō)，大多數(shù)開(kāi)發(fā)人員除了需要針對(duì) API 的開(kāi)發(fā)和創(chuàng)建進(jìn)行必要的 SOAP 處理，也需要手動(dòng)將 XML 文檔與 RPC 協(xié)同使用。之后，開(kāi)發(fā)人員還需要解釋 API 的端點(diǎn)，并將 SOAP 套件發(fā)布到該端點(diǎn)處。這不僅是 API 的誕生，也算是 SaaS 概念的開(kāi)始。

而塑造現(xiàn)代 API 的關(guān)鍵事件，離不開(kāi) Flicker 和 Facebook API 的推出。Flicker 開(kāi)發(fā)了一個(gè)通過(guò)云端存儲(chǔ)數(shù)字圖像的平臺(tái)，該平臺(tái)通過(guò)開(kāi)發(fā) API，支持橫跨不同平臺(tái)的圖像共享，并集成了各種照片共享設(shè)施的新型服務(wù)。

到了 2008 年，API 進(jìn)化成為可以獨(dú)立操作，并能夠處理大量互連的信息。Twilio 通過(guò)推出一個(gè) API，可方便用戶(hù)連接電話、短信等整個(gè)產(chǎn)品所需各個(gè)部分。

什么是 API?

對(duì)于初學(xué)者來(lái)說(shuō)，API 是指為兩個(gè)不同的應(yīng)用之間實(shí)現(xiàn)流暢通信，而設(shè)計(jì)的應(yīng)用程序編程接口。它通常被稱(chēng)為應(yīng)用程序的“中間人”。由于我們需要保護(hù)用戶(hù)的持有數(shù)據(jù)、以及應(yīng)用本身的完整性，因此 API 的安全性是一種“剛需”。

而對(duì)于開(kāi)發(fā)人員而言，API 是一個(gè)非常好的工具。它可以在微服務(wù)和容器之間交換信息，并實(shí)現(xiàn)快節(jié)奏的通信交流。正如集成和互連對(duì)于應(yīng)用開(kāi)發(fā)的重要性那樣，API 在某種程度上，驅(qū)動(dòng)并增強(qiáng)了應(yīng)用程序的設(shè)計(jì)。

???

API 風(fēng)靡互聯(lián)網(wǎng)

在互聯(lián)網(wǎng)的早期，API 作為專(zhuān)有協(xié)議，在網(wǎng)絡(luò)中往往被用于受限的區(qū)域、目的或組織，讓不同網(wǎng)絡(luò)架構(gòu)的通信與計(jì)算成為可能。當(dāng) Web 2.0 出現(xiàn)后，基于 Web 的工具廣泛涌現(xiàn)，人們開(kāi)始使用 REST (REpresentational State Transfer Framework)這一社區(qū)開(kāi)發(fā)規(guī)范，來(lái)構(gòu)建實(shí)際應(yīng)用的 API 接口，例如我們常見(jiàn)的 OpenAPI。

在如今的 Web 3.0 時(shí)代，API 在 IoT 和 AI 驅(qū)動(dòng)的設(shè)備之間的通信中，發(fā)揮著至關(guān)重要的作用。API 的常規(guī)請(qǐng)求 - 響應(yīng)范式也轉(zhuǎn)變成為了事件驅(qū)動(dòng)的方式。

API 用例

API 作為方便信息交換的基本元素，被廣泛用于 Web 應(yīng)用程序的開(kāi)發(fā)領(lǐng)域。目前，業(yè)界最常使用且最為重要的 API 用例，有如下類(lèi)型：

單頁(yè)應(yīng)用程序(SPA)

REST API 不但可以加速單頁(yè)應(yīng)用程序的開(kāi)發(fā)，而且能夠協(xié)助應(yīng)用將所有內(nèi)容放在一張頁(yè)面上，以提供完整的用戶(hù)體驗(yàn)。在應(yīng)用的開(kāi)發(fā)過(guò)程中，程序員可以使用預(yù)定義的 CSS、JavaScript 和 HTML 文件，來(lái)啟動(dòng) Web 服務(wù)器間的通信。注意，REST 框架通常被用于服務(wù)器端的通信，以及針對(duì)特定類(lèi)型框架的客戶(hù)端信息交換。

常被用于 SPA 開(kāi)發(fā)的 REST API 框架包括：NancyFx、Express.js 和 ASP.Net WebAPI。作為無(wú)狀態(tài)的框架，REST API 不會(huì)受到客戶(hù)端為每個(gè)請(qǐng)求去調(diào)用一到多個(gè)服務(wù)器的困擾。因此使用 REST API 進(jìn)行 SPA 開(kāi)發(fā)，能夠提高應(yīng)用的可擴(kuò)展性。顯然，這不但減輕了開(kāi)發(fā)者為擴(kuò)展應(yīng)用程序而付出的成本，并且消除了應(yīng)用對(duì)于訪問(wèn)特定資源的需求。

在 SPA 開(kāi)發(fā)中，除了 REST API 文檔之外，沒(méi)有其他元素會(huì)被綁定到客戶(hù)端和服務(wù)器上。因此，這種獨(dú)立性促進(jìn)了應(yīng)用在開(kāi)發(fā)、測(cè)試和部署環(huán)節(jié)的靈活性。而這恰恰是動(dòng)態(tài)網(wǎng)頁(yè)框架所無(wú)法達(dá)到的。

公共 API、企業(yè)級(jí)的 B2B

長(zhǎng)期以來(lái)，電話、傳真和電子郵件一直是 B2B 運(yùn)營(yíng)的主要通信手段。然而，為了滿(mǎn)足基于物聯(lián)網(wǎng)的信息交換的需求，RESTful API 可以在自動(dòng)化的企業(yè)級(jí) B2B 通信方面，發(fā)揮關(guān)鍵性的作用。

從客戶(hù)的角度來(lái)看，發(fā)布公共 API 會(huì)使得企業(yè)能夠創(chuàng)建面向消費(fèi)者的應(yīng)用程序，并且最大化與外界的通信交流效果。同時(shí)，由于公共 API 允許 B2B 客戶(hù)端擴(kuò)展各種基于用戶(hù)的行為，因此它使得業(yè)務(wù)流程得以充分解耦，并在不增加成本負(fù)擔(dān)的前提下，增強(qiáng)了基于機(jī)器(machine-based)的互操作性。

私有 API 與內(nèi)部 API 服務(wù)

使用私有 API，B2B 客戶(hù)可以縮短面市的時(shí)間，并在加速啟用新的應(yīng)用和工具的同時(shí)，不會(huì)對(duì)現(xiàn)有工作流程造成瓶頸。在管理內(nèi)部工作流時(shí)，私有 API 可以為企業(yè)找出需要重組和現(xiàn)代化改造的可組合(composable)領(lǐng)域。而作為一個(gè)創(chuàng)造性的過(guò)程，可組合的業(yè)務(wù)模型可以將復(fù)雜的功能分解為，易于處理的微型部分。私有 API 通過(guò)支持內(nèi)部各個(gè)級(jí)別的高效通信，促進(jìn)了資源的戰(zhàn)略性使用。

由于內(nèi)部 API 提供了針對(duì)各種可能導(dǎo)致操作性故障，以及提高系統(tǒng)部件響應(yīng)時(shí)間的詳細(xì)信息，因此它使得商業(yè)智能分析的結(jié)果更加精準(zhǔn)。而且在使用私有 API 后，應(yīng)用的協(xié)作和信息交換能力也會(huì)變得更加快速且安全。

服務(wù)網(wǎng)格

作為基礎(chǔ)設(shè)施層的組件，服務(wù)網(wǎng)格具有高度的可配置性和低延遲性。通常，它被用于在網(wǎng)絡(luò)結(jié)構(gòu)中，處理大規(guī)模的內(nèi)部通信。通過(guò)合理地使用網(wǎng)格，開(kāi)發(fā)者可以保證各種與容器化和臨時(shí)應(yīng)用相關(guān)的快速、安全且可靠的信息交換。

API 可以被用于服務(wù)網(wǎng)格中的信息交換。不過(guò)當(dāng)網(wǎng)格的數(shù)據(jù)平面與通過(guò)系統(tǒng)的每個(gè)數(shù)據(jù)包或請(qǐng)求進(jìn)行聯(lián)系時(shí)，情況會(huì)變得復(fù)雜許多。因此，使用通用數(shù)據(jù)平面(Universal Data Plane)和 xDS 等 API 可以簡(jiǎn)化此類(lèi)工作。它們可以檢查系統(tǒng)的健康狀況，監(jiān)控其性能、路由各種傳入或傳出請(qǐng)求、以負(fù)載共享的方式平衡系統(tǒng)流量，以及通過(guò)服務(wù)發(fā)現(xiàn)的方式，來(lái)發(fā)現(xiàn)與用戶(hù)授權(quán)相關(guān)的誤操作。

移動(dòng)后端

作為一種新興的服務(wù)交付模型，移動(dòng)后端通常被用于移動(dòng)優(yōu)化方案的開(kāi)發(fā)中。被稱(chēng)為移動(dòng)后端即服務(wù)(Mobile Backend as a Service，MBaaS)的開(kāi)發(fā)模型，充分給予了開(kāi)發(fā)人員維護(hù)服務(wù)器和服務(wù)器相關(guān)工具的自由，其中包括：用戶(hù)管理、推送通知和社交登錄插件等組件。

MBaaS 的各個(gè)資源會(huì)使用靈活的 SDK，去連接 API 的端點(diǎn)。例如，MBaaS 會(huì)使用 Flutter、Unity、Iconic 和 React Native 等技術(shù)，為 Android 和 iOS 操作系統(tǒng)開(kāi)發(fā)前端應(yīng)用。同時(shí)，MBaaS 平臺(tái)的各種 API 能夠?yàn)殚_(kāi)發(fā)人員在工作流管理、通知更新和任務(wù)規(guī)劃等方面帶來(lái)自動(dòng)化。

此外，這些 API 可以生成一個(gè)應(yīng)用層，以實(shí)現(xiàn)在各種系統(tǒng)和所使用的服務(wù)之間，進(jìn)行無(wú)縫的信息交換。開(kāi)發(fā)人員也可以為新添加的用戶(hù)集群，設(shè)計(jì)各種基于需求的服務(wù)。

物聯(lián)網(wǎng)(IoT)

由于物聯(lián)網(wǎng)設(shè)備需要連接到客戶(hù)端、或其他網(wǎng)絡(luò)用戶(hù)的設(shè)備上，以完成信息的交換，因此在使用 API 時(shí)，往往難免暴露交換信息。為此，開(kāi)發(fā)人員需要?jiǎng)?chuàng)建足夠安全的、基于上下文的應(yīng)用，而不可直接使用 UI 與外部進(jìn)行交互。

REST API 是目前用于物聯(lián)網(wǎng)設(shè)備真實(shí)場(chǎng)景的、最普遍的 API，它通過(guò)互聯(lián)網(wǎng)協(xié)議來(lái)進(jìn)行信息交換。此外，REST API 也允許開(kāi)發(fā)人員實(shí)施身份驗(yàn)證和授權(quán)策略。

不同人眼中的 API

API 的多樣性往往會(huì)被用于不同的應(yīng)用場(chǎng)景中，而不同角色的開(kāi)發(fā)者，對(duì)于 API 有著不同的認(rèn)識(shí)。

后端開(kāi)發(fā)：

• 框架：一個(gè)結(jié)構(gòu)良好的規(guī)劃或戰(zhàn)略，它定義了操作和流程的工作方式。
• 規(guī)范：一種基于 Swagger 的文檔，可描述 REST 或 OpenAPI 等功能。例如，與 Geo PC 內(nèi)容相關(guān)的某種 GraphQL 模式。
• 數(shù)據(jù)和業(yè)務(wù)邏輯：后端開(kāi)發(fā)人員更喜歡在客戶(hù)端(例如，移動(dòng)應(yīng)用或?yàn)g覽器)之間分離數(shù)據(jù)和邏輯。這將有利于他們自己的代碼或數(shù)據(jù)，例如，單頁(yè)面應(yīng)用和移動(dòng)應(yīng)用可以使用相同的數(shù)據(jù)與 API，去處理各種自定義的集成。
• 統(tǒng)一的移動(dòng)、Web 和集成后端，可以改進(jìn)和簡(jiǎn)化同步的過(guò)程。

DevOps：

• 滿(mǎn)足生產(chǎn)環(huán)境的規(guī)范：例如，如果端點(diǎn)經(jīng)常返回 502 錯(cuò)誤的話，您就應(yīng)該考慮使用 API，來(lái)對(duì)其進(jìn)行修復(fù)。
• 可擴(kuò)展性：如果端點(diǎn)需要通過(guò)擴(kuò)展，來(lái)解決 504 錯(cuò)誤的話，您需要找出與此相關(guān)的微服務(wù)、最佳流程、以及解決問(wèn)題的方向(例如，針對(duì) GraphQL 的 REST API)。

???

API 的工作原理流程圖

安全：

• 新的協(xié)議：如何應(yīng)對(duì)防火墻、掃描儀和其他舊工具停止升級(jí)的問(wèn)題?
• 東 - 西向(East-west，即各個(gè)后端應(yīng)用與數(shù)據(jù)庫(kù)之間，區(qū)別于我們常說(shuō)的南 - 北向)安全：在網(wǎng)絡(luò)內(nèi)缺乏對(duì)通信的良好監(jiān)控。
• 新的安全、網(wǎng)絡(luò)或其他 IT 組件的合規(guī)性需求。

API 安全的重要性

如前所述，API 與 API 安全是相輔相成的。那些安全性較差的 API，往往容易暴露，且受黑客的攻擊。而由于 API 主要用于交換信息、連接服務(wù)和傳輸數(shù)據(jù)，因此一旦出現(xiàn)數(shù)據(jù)泄露，就會(huì)給企業(yè)帶來(lái)重大的損失。

API 的各種認(rèn)證方法

在授予用戶(hù)訪問(wèn)權(quán)限之前，我們有必要驗(yàn)證那些查看或編輯 API 資源的用戶(hù)的真實(shí)身份，以防止 API 被不恰當(dāng)?shù)厥褂谩?/p>

1、基于主機(jī)的認(rèn)證

該過(guò)程通過(guò)驗(yàn)證主機(jī)或服務(wù)器，以保證只有經(jīng)過(guò)驗(yàn)證的用戶(hù)，才能訪問(wèn)到部署在服務(wù)器上的資源。我們并不需要任何密鑰、或其他方式，來(lái)啟動(dòng)該過(guò)程。但是，服務(wù)器應(yīng)該有能力通過(guò)實(shí)時(shí)驗(yàn)證登錄密鑰，以控制 DNS 欺騙、路由欺騙、以及 IP 欺騙等事件。

在流程和實(shí)現(xiàn)方式上，基于主機(jī)的認(rèn)證與 RSA 非常相似。默認(rèn)情況下，我們可以不必設(shè)置任何參數(shù)?；谥鳈C(jī)的用戶(hù)驗(yàn)證，可以由管理員通過(guò)為本地主機(jī)創(chuàng)建私鑰、或提取用于本地主機(jī)的公鑰來(lái)完成。

2、基本認(rèn)證

這是最直接的 API 身份確認(rèn)方案之一。由于客戶(hù)端發(fā)送帶有預(yù)構(gòu)建標(biāo)頭的 HTTP 請(qǐng)求，因此，該方法使用 HTTP 協(xié)議和進(jìn)程，來(lái)請(qǐng)求和驗(yàn)證用戶(hù)名和密碼等憑據(jù)。此類(lèi)檢查往往是在瀏覽器驅(qū)動(dòng)的環(huán)境中完成的。

由于能夠得到絕大多數(shù)瀏覽器和服務(wù)器的支持，因此此類(lèi)身份認(rèn)證所使用到的憑據(jù)詳細(xì)信息，可以明文形式在網(wǎng)絡(luò)上共享，或僅使用 base64 進(jìn)行編碼。它不但能夠在各種代理服務(wù)器上運(yùn)行，而且能夠?qū)⒃L問(wèn)權(quán)限授予那些并未托管在 IIS 服務(wù)器上的資源。由于缺少加密的保護(hù)，因此它很容易受到重放等方式的攻擊。

3、OAuth

作為一種可定制的開(kāi)放式 API 身份驗(yàn)證技術(shù)，OAuth 可以通過(guò)驗(yàn)證用戶(hù)身份和定義授權(quán)標(biāo)準(zhǔn)，實(shí)現(xiàn)應(yīng)用與服務(wù)器、及存儲(chǔ)類(lèi) API 的交互。

當(dāng)有人登錄系統(tǒng)時(shí)，它會(huì)通過(guò)請(qǐng)求令牌的方式，去驗(yàn)證用戶(hù)身份。為此，個(gè)人或請(qǐng)求的創(chuàng)建者必須將訪問(wèn)資源的請(qǐng)求，轉(zhuǎn)發(fā)到身份驗(yàn)證服務(wù)器上。服務(wù)器進(jìn)而會(huì)根據(jù)驗(yàn)證的結(jié)果，對(duì)請(qǐng)求予以接受或拒絕。

相比其他流程，OAuth 更為安全，因此它成為了許多用戶(hù)的首選。OAuth 的三個(gè)關(guān)鍵要素包括 OAuth 提供者(如 Google 和 Facebook)、OAuth 客戶(hù)端(指承載信息的網(wǎng)站 / 頁(yè)面)、以及所有者(指提出訪問(wèn)請(qǐng)求的用戶(hù))。

4、OAuth 2.0

作為 OAuth 的更新版本，OAuth 2.0 是一種被廣泛使用的 API 訪問(wèn)管理協(xié)議。其功能包括通過(guò)使用 HTTP 服務(wù)，來(lái)啟動(dòng)客戶(hù)端應(yīng)用，進(jìn)而限制 API 客戶(hù)端的訪問(wèn)。GitHub 和 Facebook 都在其關(guān)鍵性 HTTP 服務(wù)的身份驗(yàn)證代碼中，使用到了該協(xié)議，進(jìn)而免去了用戶(hù)憑據(jù)。

OAuth 2.0 的三個(gè)關(guān)鍵要素分別是：擁有數(shù)據(jù)的用戶(hù)、應(yīng)用程序和 API 本身。在身份驗(yàn)證的過(guò)程中，該方法可以很容易地解析到使用不同資源的用戶(hù)數(shù)據(jù)。它可以根據(jù)驗(yàn)證目的，被部署到基于 Web、移動(dòng)及桌面的應(yīng)用程序與設(shè)備中。

5、SAML

安全斷言標(biāo)記語(yǔ)言(Security Assertion Markup Language，SAML)，是使用單點(diǎn)登錄技術(shù)進(jìn)行身份驗(yàn)證的標(biāo)準(zhǔn)化 API 流程。它會(huì)根據(jù)用戶(hù)提供的詳細(xì)信息來(lái)進(jìn)行驗(yàn)證。只有完成驗(yàn)證，用戶(hù)才會(huì)被授予針對(duì)各種應(yīng)用程序或資源的訪問(wèn)權(quán)限。目前，SAML 2.0 是被普遍使用的版本。它與 ID 非常類(lèi)似，可以協(xié)助完成對(duì)于用戶(hù)身份的評(píng)估。

API 安全意味著什么?

API 安全不僅專(zhuān)注于保護(hù)那些直接或間接暴露給用戶(hù)的 API，還涉及到節(jié)流、速率限制等網(wǎng)絡(luò)安全原則，基于身份的安全分析，以及如下關(guān)鍵性的安全控制概念：

API 協(xié)議

API 可以根據(jù)不同的需求，以多種形式和樣式被使用。而不同的使用方式也決定了 API 實(shí)施的安全性。

SOAP

簡(jiǎn)單對(duì)象訪問(wèn)協(xié)議(Simple Object Access Protocol，SOAP)是一種基于 XML 的消息傳遞與通信協(xié)議。該協(xié)議可以擴(kuò)展 HTTP，并為 Web 服務(wù)提供數(shù)據(jù)傳輸。使用該協(xié)議，我們可以輕松地交換包含著所有內(nèi)容的文件、或遠(yuǎn)程調(diào)用過(guò)程。與諸如 CORB、DCOM 和 Java RMI 等其他框架的不同之處在于，SOAP 的整個(gè)消息都是被寫(xiě)在 XML 中的，因此它能夠獨(dú)立于各種語(yǔ)言。

REST

作為基于 HTTP 協(xié)議的 Web 標(biāo)準(zhǔn)架構(gòu)，REST 針對(duì)每個(gè)待處理的 HTTP 請(qǐng)求，可以使用四種動(dòng)詞：GET、POST、PUT 和 DELETE。對(duì)于開(kāi)發(fā)人員來(lái)說(shuō)，RESTful 架構(gòu)是理解 API 功能和行為的最簡(jiǎn)單工具之一。它不但能夠使得 API 架構(gòu)易于維護(hù)和擴(kuò)展，而且方便了內(nèi)、外部開(kāi)發(fā)人員去訪問(wèn) API。

gRPC

作為一個(gè)開(kāi)源的高性能框架，gRPC 改進(jìn)了老式的遠(yuǎn)程過(guò)程調(diào)用(Remote Procedure Call，RPC)協(xié)議。它使用 HTTP/2 這種二進(jìn)制幀傳輸協(xié)議，簡(jiǎn)化了客戶(hù)端和后端服務(wù)之間的通信和消息傳遞過(guò)程。

完全輕量級(jí)的 gRPC，要比 JSON 快 8 倍以上。它可以通過(guò)開(kāi)源技術(shù)協(xié)議調(diào)用緩沖區(qū)，并對(duì)結(jié)構(gòu)化的消息采用了一種與平臺(tái)無(wú)關(guān)的序列化格式。在 API 的使用中，開(kāi)發(fā)人員可以通過(guò) gRPC，找出應(yīng)該調(diào)用和評(píng)估參數(shù)值的各個(gè)過(guò)程。

Webhook

Webhook 能夠?qū)⒆詣?dòng)生成的消息，從一個(gè)應(yīng)用程序發(fā)送到另一個(gè)應(yīng)用程序。換句話說(shuō)，它可以在兩個(gè)應(yīng)用之間實(shí)時(shí)建立、發(fā)送、提取更新的通信。

由于 Webhooks 可以包含關(guān)鍵信息，并將其傳輸?shù)降谌椒?wù)器，因此我們可以通過(guò)在 Webhooks 中執(zhí)行基本的 HTTP 身份驗(yàn)證、或是 TLS 身份驗(yàn)證，來(lái)保證 API 的相關(guān)安全實(shí)踐。

WebSocket

WebSocket 是一種雙向通信協(xié)議，可以在客戶(hù)端和服務(wù)器之間提供成熟的雙向通信通道，進(jìn)而彌補(bǔ)了 HTTP 協(xié)議的局限性。

應(yīng)用客戶(hù)端可以使用 WebSocket 來(lái)創(chuàng)建 HTTP 連接請(qǐng)求，并發(fā)送給服務(wù)器。當(dāng)初始化通信連接被建立之后，客戶(hù)端和服務(wù)器都可以使用當(dāng)前的 TCP/IP 連接，根據(jù)基本的消息框架協(xié)議，傳輸數(shù)據(jù)與信息。

XML-RPC

XML-RPC 可以通過(guò)標(biāo)準(zhǔn)化的通信過(guò)程，實(shí)現(xiàn) WordPress 和其他系統(tǒng)之間的相互通信。它使用 HTTP 作為傳輸?shù)氖侄?，使?XML 作為編碼過(guò)程。其工作代碼被存儲(chǔ)在位于網(wǎng)站根目錄的 xmlrpc.php 文件中。作為 WordPress 3.5 版的默認(rèn)選項(xiàng)，XML-RPC 能夠讓移動(dòng)應(yīng)用與基于 Web 的 WordPress 安裝過(guò)程，實(shí)現(xiàn)無(wú)縫的交互。

不過(guò)，對(duì)于每個(gè)訪問(wèn)請(qǐng)求而言，由于 xmlrpc.php 能夠共享身份驗(yàn)證的詳細(xì)信息，因此它增加了暴力攻擊和 DDoS 攻擊的幾率。對(duì)此，我們?cè)诓捎?XML-RPC 的 API 時(shí)，需要增加相關(guān)安全實(shí)踐。

JSON-RPC

對(duì)于新手而言，JSON-RPC 是一種超輕型的 RPC 協(xié)議，可用來(lái)開(kāi)發(fā)基于以太坊區(qū)塊鏈的 API。它采用 JSON(RFC4627)作為基本的數(shù)據(jù)格式，具有解釋和處理多個(gè)數(shù)據(jù)結(jié)構(gòu)與規(guī)則的能力。該協(xié)議可以通過(guò)相同的套接字被反復(fù)使用。

MQTT

MQTT 是 OASIS 認(rèn)可的消息協(xié)議，已被廣泛地用在物聯(lián)網(wǎng)設(shè)備和工具開(kāi)發(fā)領(lǐng)域，實(shí)現(xiàn)了 HTTP 類(lèi)型的信息交換。由于非常輕巧，因此它可以讓開(kāi)發(fā)人員能夠一次性擴(kuò)展到數(shù)百萬(wàn)臺(tái)設(shè)備上。在 API 安全性方面，MQTT 不但能夠協(xié)助實(shí)現(xiàn)消息加密，而且可以輕松地應(yīng)用 TLS 和身份驗(yàn)證。

AMQP

作為一個(gè)開(kāi)放的協(xié)議，高級(jí)消息隊(duì)列協(xié)議(Advanced Message Queuing Protocol，AMQP)規(guī)定了消息提供者的行為過(guò)程，可以被應(yīng)用到應(yīng)用層上，創(chuàng)建互操作式的系統(tǒng)。由于是采用二進(jìn)制實(shí)現(xiàn)的，因此該協(xié)議不但支持各種面向消息的中間件通信，而且可以確保消息的全面妥投。

XMPP

作為一整套免費(fèi)的源技術(shù)，XMPP 可用于開(kāi)發(fā)多方協(xié)作、即時(shí)消息、多方聊天、視頻通話、以及輕量級(jí)中間件等領(lǐng)域。它的四個(gè)關(guān)鍵性組件包括：PHP、MySQL、Apache 和 Perl。

CoAP

作為一種由 RFC 7252 定義的 IETF 標(biāo)準(zhǔn)，CoAP 可以被當(dāng)作標(biāo)準(zhǔn)化的 API 安全協(xié)議，來(lái)約束物聯(lián)網(wǎng)設(shè)備上的應(yīng)用。由于 CoAP 可以支持通過(guò) LPWAN 進(jìn)行通信，因此它是保護(hù)簡(jiǎn)單微控制器節(jié)點(diǎn)的最佳選擇。CoAP 工作在 TCP/IP 層，并采用 UDP 作為基本的傳輸協(xié)議。

云、本地和混合部署中的 API 安全

云服務(wù)、集成平臺(tái)和 API 網(wǎng)關(guān)等技術(shù)領(lǐng)域的發(fā)展，使得 API 提供商們能夠以多種方式來(lái)保護(hù) API。可以說(shuō)，針對(duì)構(gòu)建 API 所選擇的技術(shù)棧類(lèi)型，會(huì)對(duì)保護(hù) API 產(chǎn)生直接的影響。例如，一個(gè)大型組織可能會(huì)使用多個(gè)帶有自研 API 的應(yīng)用程序。而在他們合并各種應(yīng)用的過(guò)程中，可能會(huì)造成各種 API 孤島的出現(xiàn)。這些孤島往往就是安全隱患的所在。

???

在異構(gòu)生態(tài)系統(tǒng)中，跨 API 孤島的特定 API 安全基礎(chǔ)架構(gòu)，可以被配置為 sidecar、sideband 代理，嵌入到云端與本地的部署之間。由于具有高度可移植性，因此此類(lèi)安全配置可以方便任何面向未來(lái)的技術(shù)，輕松地傳輸或提取 API。

API 安全層

API 安全層應(yīng)該是多層次的結(jié)構(gòu)。各個(gè)層面各司其職，最大程度地提供安全保護(hù)。

API 發(fā)現(xiàn)

API 安全的第一層是 API 發(fā)現(xiàn)，畢竟如果不知道目標(biāo)與威脅，何談如何實(shí)施保護(hù)。如前所述，API 孤島是阻礙安全人員發(fā)現(xiàn) API 的首要問(wèn)題。由于缺少 API 的可見(jiàn)性，它將直接妨礙 API 訪問(wèn)權(quán)限的管理。

???

影子 API 是 API 可見(jiàn)性的第二大障礙。當(dāng) API 作為應(yīng)用的一部分被開(kāi)發(fā)時(shí)，往往只有開(kāi)發(fā)小組成員對(duì)其了如指掌，而安全人員對(duì)此類(lèi)“影子 API”的實(shí)施細(xì)節(jié)不得而知。

第三大障礙便是 API 版本控制。在軟件應(yīng)用的生命周期中，其 API 通常需要不斷地進(jìn)行迭代?？墒切掳姹镜?API 往往不能立刻且全面地替換掉舊的版本。由于用戶(hù)端的應(yīng)用版本不盡相同，因此舊版本的 API 需要根據(jù)向后兼容的需求，繼續(xù)運(yùn)行一段時(shí)間。然后呢?它們會(huì)逐漸離開(kāi)開(kāi)發(fā)團(tuán)隊(duì)的視野，甚至被遺忘。這一切都是悄然發(fā)生的。

因此，API 發(fā)現(xiàn)實(shí)際上是 API 提供者和攻擊之間的競(jìng)賽。如果提供者能夠在攻擊者之前發(fā)現(xiàn)上述類(lèi)型的 API，那么他們便可以從 API 網(wǎng)關(guān)、負(fù)載平衡器、以及直接內(nèi)聯(lián)的網(wǎng)絡(luò)流量中提取 API 的流量元數(shù)據(jù)，并通過(guò)專(zhuān)門(mén)的引擎，生產(chǎn)有效的 API 列表報(bào)告，以便與 API 管理層上的可用 API 目錄進(jìn)行比較。

API 安全的 OWASP 十大安全威脅

???

API1:2019 對(duì)象級(jí)別授權(quán)的缺陷

通常，API 端點(diǎn)通過(guò)發(fā)現(xiàn)處理對(duì)象的標(biāo)識(shí)符，來(lái)獲取訪問(wèn)控制層面的攻擊。我們需要針對(duì)由客戶(hù)端提供的信息，進(jìn)行逐條檢查。

API2:2019 用戶(hù)認(rèn)證的缺陷

攻擊者往往會(huì)利用獲取到的令牌、或驗(yàn)證系統(tǒng)的執(zhí)行缺陷，來(lái)冒充合法用戶(hù)，并執(zhí)行非法操作。

API3:2019 過(guò)度的數(shù)據(jù)暴露

攻擊者可以通過(guò) API 的調(diào)用，合法獲取的數(shù)據(jù)，推斷出某些條目的相關(guān)屬性，進(jìn)而篩選出各種實(shí)用的信息。

API4:2019 資源不足和限流

通常，API 不會(huì)對(duì)被調(diào)用的數(shù)據(jù)進(jìn)行流量或數(shù)量上的限制。而這就給攻擊者留下了發(fā)起拒絕服務(wù)(DoS)等搶占資源類(lèi)攻擊的機(jī)會(huì)。

API5:2019 功能級(jí)授權(quán)的缺陷

有些 API 在復(fù)雜的訪問(wèn)控制策略上并不完備，甚至帶有授權(quán)上的缺陷。這會(huì)導(dǎo)致攻擊者可以通過(guò)函數(shù)調(diào)用，獲得其他用戶(hù)能夠調(diào)用的資源。

API6:2019 批量分配

為了提高效率，以 JSON 方式為用戶(hù)提供信息的模型，往往會(huì)提供批量分配(Mass Assignment)，而無(wú)需根據(jù)具體的許可名單，進(jìn)行合法的屬性篩選。據(jù)此，攻擊者可以通過(guò)仔細(xì)閱讀配套文檔，來(lái)推測(cè)出對(duì)象的屬性、查找到不同的 API 端點(diǎn)、或在請(qǐng)求負(fù)載中發(fā)掘額外的屬性，進(jìn)而對(duì)它們進(jìn)行篡改。

API7:2019 安全配置的錯(cuò)誤

安全配置的錯(cuò)誤往往源于不完備的默認(rèn)設(shè)計(jì)、隨意的編排、開(kāi)放的分布式存儲(chǔ)、HTTP 標(biāo)頭的錯(cuò)配、寬松的跨域資產(chǎn)共享(Cross-Origin asset sharing，CORS)、以及包含著敏感數(shù)據(jù)的冗長(zhǎng)錯(cuò)誤消息提示等方面。

API8:2019 注入

攻擊者的有害信息可能會(huì)騙過(guò)輸入檢查，在未經(jīng)適當(dāng)檢驗(yàn)的情況下，利用 SQL 或 NoSQL 的缺陷，執(zhí)行惡意命令或獲取信息。

API9:2019 資產(chǎn)管理不當(dāng)

API 通常能夠發(fā)現(xiàn)比常規(guī) Web 應(yīng)用更多的端點(diǎn)，這使得適當(dāng)?shù)馗屡涮孜臋n就顯得格外重要了。對(duì)此，我們應(yīng)當(dāng)持續(xù)完善 API 的相關(guān)表格，及時(shí)發(fā)現(xiàn)那些未被記入的端點(diǎn)。

API10:2019 日志和監(jiān)控不足

缺乏日志記錄和檢查，加上事件響應(yīng)能力不足，都會(huì)給 API 調(diào)用帶來(lái)被攻擊的威脅。

滲透測(cè)試

開(kāi)發(fā)人員可以考慮使用 Postman 代理的預(yù)構(gòu)建的 API 測(cè)試數(shù)據(jù)，直接與 API 進(jìn)行通信。通過(guò)快速且反復(fù)地開(kāi)展針對(duì) API 的滲透測(cè)試，我們可以在降低測(cè)試成本的基礎(chǔ)上，獲取詳細(xì)的報(bào)告。

由于滲透測(cè)試需要對(duì)目標(biāo) API、乃至整個(gè)系統(tǒng)都非常熟練，因此我們最好聘請(qǐng)熟練的安全團(tuán)隊(duì)、或使用開(kāi)源的工具，去模擬針對(duì) API 的攻擊。通過(guò)定期且持續(xù)的滲透測(cè)試，開(kāi)發(fā)人員將能夠及時(shí)找到符合 API 保護(hù)級(jí)別的補(bǔ)救措施。

12 項(xiàng) API 安全的優(yōu)秀實(shí)踐

由上述討論可知，API 的安全性對(duì)于以數(shù)據(jù)為中心的應(yīng)用開(kāi)發(fā)來(lái)說(shuō)，是至關(guān)重要的。下面讓我們來(lái)討論針對(duì) API 的不同類(lèi)型與階段的安全優(yōu)秀實(shí)踐。

1、使用加密

為了防范破解類(lèi)的攻擊，我們需要對(duì)那些被用在內(nèi)、外部通信的 API，使用 TLS 加密協(xié)議，并部署端到端的加密。

2、API 認(rèn)證

如前文所述，身份驗(yàn)證可以確保 API 不會(huì)被陌生人所直接使用。同時(shí)，通過(guò) API 密鑰或訪問(wèn)認(rèn)證，我們可以蹤調(diào) API 資源的調(diào)用。當(dāng)然，此類(lèi)安全措施也會(huì)增加系統(tǒng)的實(shí)施難度。

3、充分利用 OAuth 和 OpenID Connect

OAuth 和 OpenID Connect 的結(jié)合能夠?yàn)?API 的身份驗(yàn)證和 / 或授權(quán)，承擔(dān)全部的責(zé)任。例如，在授權(quán)過(guò)程中，API 的消費(fèi)者和提供者均不直接進(jìn)行授權(quán)操作，而是讓 OAuth 作為委托協(xié)議，為 API 添加一個(gè)基本的保護(hù)層，并在此基礎(chǔ)上讓 OpenID Connect 標(biāo)準(zhǔn)作為額外的身份層，使用 ID 令牌去擴(kuò)展 OAuth2.0。

4、安全專(zhuān)家

面對(duì)多種 API 安全實(shí)踐，您也許會(huì)犯“選擇困難癥”。此時(shí)，經(jīng)驗(yàn)豐富的安全專(zhuān)家可以指導(dǎo)您使用合適的防病毒系統(tǒng)、以及 ICAP(Internet Content Adaptation Protocol)服務(wù)器，來(lái)構(gòu)建穩(wěn)固的 API 安全態(tài)勢(shì)。

5、持續(xù)監(jiān)控、審計(jì)和日志記錄

常言道，預(yù)防勝過(guò)彌補(bǔ)。我們可以在 API 設(shè)計(jì)之初，就設(shè)置好待監(jiān)控與記錄的指標(biāo);而在應(yīng)用服務(wù)的使用過(guò)程中，通過(guò)適當(dāng)?shù)膬x表板去跟蹤 API 的交互，并及時(shí)審查相關(guān)記錄與錯(cuò)誤信息。同時(shí)，在后續(xù)的調(diào)試與版本更新環(huán)節(jié)，請(qǐng)不要忘記讓所有的 API 都得以同步。

6、僅共享有限的信息

記住，您通過(guò) API 共享出去的信息越少，API 自身的安全性風(fēng)險(xiǎn)就越小。同時(shí)，您也應(yīng)當(dāng)確保在錯(cuò)誤消息中，披露的信息盡可能地少。

此外，使用 IP 地址的白名單與黑名單，是限制 API 資源訪問(wèn)的好方法。它可以保證只有已授權(quán)人員或應(yīng)用，才能有限地訪問(wèn) API 資源，并保持接口上關(guān)鍵信息的隱藏性。

7、限流和配額保護(hù)

請(qǐng)根據(jù)后端系統(tǒng)、實(shí)際帶寬、以及服務(wù)器的運(yùn)能，合理地限制有限數(shù)量的消息，去訪問(wèn)某些 API，進(jìn)而能夠有效地防范 DDoS 攻擊的威脅。

8、有效的數(shù)據(jù)

服務(wù)器應(yīng)當(dāng)對(duì)接受到的所有內(nèi)容，進(jìn)行兩次檢查與驗(yàn)證。任何新增的內(nèi)容、龐大的數(shù)據(jù)集、以及由消費(fèi)端共享來(lái)的信息，都應(yīng)當(dāng)經(jīng)過(guò)驗(yàn)證。目前，JSON 和 XML 驗(yàn)證是兩種被用于檢查參數(shù)安全性的最廣泛工具。同時(shí)，它們也可以控制 SQL 注入、以及 XML 炸彈等事件。

9、強(qiáng)大的基礎(chǔ)設(shè)施

通過(guò)實(shí)施最新的安全網(wǎng)絡(luò)技術(shù)、新型服務(wù)器與負(fù)載平衡軟件，我們可以在基礎(chǔ)設(shè)施的層面上保持 API 的安全性，使之能夠抵御大數(shù)據(jù)量的泄露攻擊。

10、關(guān)注 OWASP Top10

通過(guò)上文分析，您不難看出，OWASP 羅列和詮釋出的十大 API 漏洞威脅，是一些最常見(jiàn)的攻擊影響方式。它們不但對(duì)于 Web 頁(yè)面，對(duì)于 API 的各種漏洞也具有極強(qiáng)的危害性。因此，我們需要事先做好代碼級(jí)的防范工作。

11、使用 API 防火墻

為 API 構(gòu)建防火墻可以起到兩方面的好處：

• 可用于執(zhí)行基本的安全檢查，例如：檢查消息的大小、被 SQL 注入的可能性、以及是否可以立即阻斷攻擊。
• 可在局域網(wǎng)內(nèi)部融入現(xiàn)有的防護(hù)體系，協(xié)同提高整體安全態(tài)勢(shì)。

12、部署 API 網(wǎng)關(guān)

無(wú)論是供內(nèi)網(wǎng)使用，還是供外網(wǎng)調(diào)用，API 所處的環(huán)境往往既復(fù)雜又危險(xiǎn)。因此，為了減輕管理 API 的壓力，我們可以通過(guò)部署 API 網(wǎng)關(guān)，對(duì) API 的相關(guān)流量進(jìn)行全面的控制、監(jiān)控和保護(hù)。

譯者介紹

陳 峻 (Julian Chen)，51CTO 社區(qū)編輯，具有十多年的 IT 項(xiàng)目實(shí)施經(jīng)驗(yàn)，善于對(duì)內(nèi)外部資源與風(fēng)險(xiǎn)實(shí)施管控，專(zhuān)注傳播網(wǎng)絡(luò)與信息安全知識(shí)與經(jīng)驗(yàn);持續(xù)以博文、專(zhuān)題和譯文等形式，分享前沿技術(shù)與新知;經(jīng)常以線上、線下等方式，開(kāi)展信息安全類(lèi)培訓(xùn)與授課。

原文鏈接：https://dzone.com/articles/api-security-beginners-guide

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

???