什么是API？API接口表現(xiàn)形式分類理論

1.什么是API

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

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

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

2.API的分類

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

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

3.API安全

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

API安全的目標(biāo)（CIA）：

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

常見的API風(fēng)險(xiǎn)（STRIDE）:

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

風(fēng)險(xiǎn)與安全機(jī)制的對(duì)應(yīng)關(guān)系：

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

4.API安全威脅

OWASP API 安全性十大威脅： 對(duì)象級(jí)別授權(quán)中斷：對(duì)于未使用適當(dāng)級(jí)別的授權(quán)保護(hù)的 API 對(duì)象，可能會(huì)因?yàn)檩^弱的對(duì)象訪問標(biāo)識(shí)符而容易發(fā)生數(shù)據(jù)泄漏和未經(jīng)授權(quán)的數(shù)據(jù)操作。例如，攻擊者可以利用一個(gè)可迭代的整數(shù)對(duì)象標(biāo)識(shí)符。

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

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

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

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

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

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

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

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

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

5.API協(xié)議

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

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

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

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

編輯：黃飛