1.什么是API

API(Application Programming Interface,應用程序編程接口)是一些預先定義的函數(shù)，目的是提供應用程序與開發(fā)人員基于某軟件或硬件的以訪問一組例程的能力，而又無需訪問源碼，或理解內(nèi)部工作機制的細節(jié)。通過API，就算不知道如何操作，也能將產(chǎn)品或服務與其他產(chǎn)品或服務進行互通。這樣就可以簡化應用開發(fā)，節(jié)省時間和成本。

API除了有應用“應用程序接口”的意思外，還特指 API的說明文檔，也稱為幫助文檔。 API作為應用編程接口，由應用程序來調(diào)用，提供API的稱為提供者，使用API的稱為消費者。API本質(zhì)上是一個程序(程序1)中，專門用于與其他應用程序(程序2)進行交互的部分，也就是程序1的外部對接部門。程序員所編寫的程序2可以通過API程序的函數(shù)聲明來和程序1進行交互。API 由一個或多個方法組成，每個方法可以實現(xiàn)一個功能，比如發(fā)送消息，上傳文件，檢索消息等。 定義和作用看起來有些晦澀難懂，我們可以類比一個常見且熟悉的接口User Interface（縮寫為 UI）即用戶接口。UI本質(zhì)上是一個系統(tǒng)中專門用于與人類使用者進行交互的部分。

UI可以是一個實物上的面板，也可以是由程序所驅(qū)動的顯示在屏幕上的界面。我們使用的應用一般有是圖形化界面的，都可以看作是一種用戶接口，比如按鈕，窗口，圖標等可視化組件。UI 定義了人與應用程序進行交互的方式。UI 由多個可視化組件構成，每個組件提供不同的交互方式，比如，在文本框中可以輸入一些消息，點擊按鈕可以發(fā)送消息等。 總之，API定義了應用程序與應用程序之間的交互，UI定義了人與應用程序之間的交互，并且兩種交互方式又相互關聯(lián)，用戶操作 UI 表達要實現(xiàn)的功能，而 UI 使用 API 來實際完成該功能。

2.API的分類

（1）根據(jù)API提供者和消費者所在的位置，可將API分為兩類：本地API：當API的提供者和消費者位于同一臺計算機上時，稱為本地API。遠程API：當API的提供者和消費者位于不同的計算機上時，稱為遠程API。 （2）根據(jù)API接口表現(xiàn)形式分類：

（3）根據(jù)API接口訪問形式分類：

3.API安全

API安全基于多種安全規(guī)則的交叉，如下圖所示。

API安全的目標（CIA）：

安全目標用于定義安全對于保護資產(chǎn)的實際意義。安全沒有統(tǒng)一的定義，有些場景中的定義可能是沖突的。從系統(tǒng)正確運行時希望達到或保持的安全目標出發(fā)，可以拆分安全目標。一些標準的安全目標幾乎適用于所有的系統(tǒng)，其中最著名的是“CIA三元組”： 機密性（Confientiality）：確保信息只被預期的讀者訪問； 完整性（Integrity）：防止未授權的創(chuàng)建，修改和刪除； 可用性（Availability）：當用戶需要訪問API時，API總是可用的。 這三條原則始終很重要，在其他情景中，有一些原則和以上三條一樣重要。比如accountability/可追責（誰做了什么）或者non-repudiation/抗抵賴（不能否認做過的行為）等。

常見的API風險（STRIDE）:

欺騙（Spoofing）：偽裝成某人； 干預（Tampering）：將不希望被修改的數(shù)據(jù)、消息或設置改掉； 否認（Repudiation）：拒絕承認做過的事； 信息泄露（Information disclosure）：將你希望保密的信息披露出來； 拒絕服務（Denial of service）：阻止用戶訪問信息和服務； 越權（Elevation ofprivilege）：做了你不希望他能做的事。

風險與安全機制的對應關系：

認證=>欺騙：確保你的用戶或客戶端真的是他（它）們自己 ； 授權=>信息泄漏/干預/越權：確保每個針對API的訪問都是經(jīng)過授權的； 審計=>否認：確保所有的操作都被記錄，以便追溯和監(jiān)控； 流控=>拒絕服務：防止用戶請求淹沒你的API； 加密=>信息泄漏：確保出入API的數(shù)據(jù)是私密的。

4.API安全威脅

OWASP API 安全性十大威脅： 對象級別授權中斷：對于未使用適當級別的授權保護的 API 對象，可能會因為較弱的對象訪問標識符而容易發(fā)生數(shù)據(jù)泄漏和未經(jīng)授權的數(shù)據(jù)操作。例如，攻擊者可以利用一個可迭代的整數(shù)對象標識符。

用戶身份驗證中斷：身份驗證機制的實現(xiàn)通常不正確或缺失，使得攻擊者可以利用實現(xiàn)缺陷來訪問數(shù)據(jù)。

過多的數(shù)據(jù)暴露：惡意行動者會試圖直接訪問 API（可能通過重播有效請求），或者嗅探服務器和 API 之間的流量。對 API 操作和可用數(shù)據(jù)的分析可能會為攻擊者生成敏感數(shù)據(jù)，而這些敏感數(shù)據(jù)并沒有展示在前端應用程序中，也沒有被前端應用程序使用。

缺少資源和速率限制：缺少速率限制可能會導致數(shù)據(jù)外泄或?qū)蠖朔盏某晒?DDoS 攻擊，進而導致所有使用者的服務中斷。

功能級別授權中斷：具有不同層次結(jié)構、組和角色的復雜訪問控制策略，以及管理功能和常規(guī)功能之間不明確的分離，都會導致授權缺陷。通過利用這些問題，攻擊者可以訪問其他用戶的資源或管理功能。

大量分配：如果一個 API 提供的字段超過了客戶端對給定操作的需求，攻擊者可能會注入過多的屬性來對數(shù)據(jù)執(zhí)行未經(jīng)授權的操作。攻擊者可以通過檢查請求和響應或其他 API 的格式來發(fā)現(xiàn)未記錄的屬性，或進行猜測。如果你不使用強類型的編程語言，則此漏洞尤其適用。

安全配置錯誤：攻擊者可能會試圖利用安全配置錯誤漏洞，例如：缺少安全強化措施、啟用了不必要的功能、不必要地向 Internet 開放了網(wǎng)絡連接、使用了弱協(xié)議或密碼、可能允許未經(jīng)授權地訪問系統(tǒng)的其他設置或終結(jié)點。

注入：接受用戶數(shù)據(jù)的任何終結(jié)點都可能會受到注入攻擊。示例包括但不限于：命令注入，其中惡意行動者試圖更改 API 請求以在托管 API 的操作系統(tǒng)上執(zhí)行命令；SQL 注入，其中惡意行動者試圖更改 API 請求以針對 API 依賴的數(shù)據(jù)庫執(zhí)行命令和查詢。

資產(chǎn)管理不當：與不當?shù)馁Y產(chǎn)管理相關的漏洞包括：缺少適當?shù)?API 文檔或所有權信息、舊版 API 過多，可能缺少安全修補程序。

日志記錄和監(jiān)視不足：如果日志記錄和監(jiān)視不足，加上與事件響應的整合缺失或無效，攻擊者就能夠進一步攻擊系統(tǒng)、保持持久性、轉(zhuǎn)向更多系統(tǒng)進行篡改，以及提取或銷毀數(shù)據(jù)。大多數(shù)違反行為研究表明，檢測到違反行為的時間超過 200 天，通常是由外部方而不是通過內(nèi)部流程或監(jiān)視方式檢測到的。

5.API協(xié)議

SOAP：簡單對象訪問協(xié)議（Simple Object Access Protocol，SOAP），它是廣泛使用的最古老的以 Web 為中心的 API 協(xié)議。SOAP 于 1990 年代后期推出，是最早設計用于允許不同應用程序或服務使用網(wǎng)絡連接以系統(tǒng)方式共享資源的協(xié)議之一。SOAP 代表簡單對象訪問協(xié)議，是一種基于 XML 的消息傳遞與通信協(xié)議。必須創(chuàng)建 XML 文檔才能進行調(diào)用，而 SOAP 所需的 XML 格式并不完全直觀。這就會使得調(diào)用和調(diào)試變得困難，因為調(diào)試需要解析長字符串的復雜數(shù)據(jù)。另一方面，SOAP 依賴于標準協(xié)議，尤其是 HTTP 和 SMTP，并為 Web 服務提供數(shù)據(jù)傳輸。SOAP 的整個消息都是被寫在 XML 中的，因此它能夠獨立于各種語言在所有操作系統(tǒng)上都可用。

REST：表述性狀態(tài)傳遞（Representational State Transfer），由Roy Fielding在2000年的一篇論文中引入，其目標是解決SOAP的一些缺點。REST是基于 HTTP 協(xié)議的 Web 標準架構，REST相比于SOAP更靈活，因為它支持多種數(shù)據(jù)格式，而不需要 XML。遵循REST架構約束的Web API 被稱為RESTful API。對于開發(fā)人員來說，RESTful 架構是理解 API 功能和行為的最簡單工具之一。它不但能夠使得 API 架構易于維護和擴展，而且方便了內(nèi)、外部開發(fā)人員去訪問 API。REST與SOAP又有著根本的區(qū)別，SOAP是一種協(xié)議，而REST是一種架構模式。這意味著RESTful Web API沒有官方標準。只要API 符合RESTful系統(tǒng)的6個導向性約束，就算作RESTful API：客戶端/服務器架構、無狀態(tài)、可緩存性、分層系統(tǒng)、統(tǒng)一接口、按需代碼（可選）。

JSON-RPC：JSON-RPC，是一個無狀態(tài)且輕量級的遠程過程調(diào)用（RPC）傳送協(xié)議，其傳遞內(nèi)容透過 JSON 為主。相較于一般的 REST 透過網(wǎng)址（如 GET /user）調(diào)用遠程服務器，JSON-RPC 直接在內(nèi)容中定義了欲調(diào)用的函數(shù)名稱（如 {"method": "getUser"}），這也令開發(fā)者不會陷于該使用 PUT 或者 PATCH 的問題之中。

gRPC：gRPC 是一個開源 API，也屬于 RPC 的范疇，是一個高性能，開源和通用的RPC框架，基于Protobuf序列化協(xié)議開發(fā)，且支持眾多開發(fā)語言。面向服務端和協(xié)議端，基于http/2設計，帶來諸如雙向流，流控，頭部壓縮，單TCP連接上的多路復用請求等特性。這些特性使得其在移動設備上表現(xiàn)的更好，更省電和節(jié)省空間。在gPRC里客戶端可以向調(diào)用本地對象一樣直接調(diào)用另一臺不同機器上服務端應用的方法，使得您能夠更容易地創(chuàng)建分布式應用和服務。

編輯：黃飛