1.什么是API
API(Application Programming Interface,應(yīng)用程序編程接口)是一些預(yù)先定義的函數(shù),目的是提供應(yīng)用程序與開(kāi)發(fā)人員基于某軟件或硬件的以訪問(wèn)一組例程的能力,而又無(wú)需訪問(wèn)源碼,或理解內(nèi)部工作機(jī)制的細(xì)節(jié)。通過(guò)API,就算不知道如何操作,也能將產(chǎn)品或服務(wù)與其他產(chǎn)品或服務(wù)進(jìn)行互通。這樣就可以簡(jiǎn)化應(yīng)用開(kāi)發(fā),節(jié)省時(shí)間和成本。
API除了有應(yīng)用“應(yīng)用程序接口”的意思外,還特指 API的說(shuō)明文檔,也稱(chēng)為幫助文檔。 API作為應(yīng)用編程接口,由應(yīng)用程序來(lái)調(diào)用,提供API的稱(chēng)為提供者,使用API的稱(chēng)為消費(fèi)者。API本質(zhì)上是一個(gè)程序(程序1)中,專(zhuān)門(mén)用于與其他應(yīng)用程序(程序2)進(jìn)行交互的部分,也就是程序1的外部對(duì)接部門(mén)。程序員所編寫(xiě)的程序2可以通過(guò)API程序的函數(shù)聲明來(lái)和程序1進(jìn)行交互。API 由一個(gè)或多個(gè)方法組成,每個(gè)方法可以實(shí)現(xiàn)一個(gè)功能,比如發(fā)送消息,上傳文件,檢索消息等。 定義和作用看起來(lái)有些晦澀難懂,我們可以類(lèi)比一個(gè)常見(jiàn)且熟悉的接口User Interface(縮寫(xiě)為 UI)即用戶(hù)接口。UI本質(zhì)上是一個(gè)系統(tǒng)中專(zhuān)門(mén)用于與人類(lèi)使用者進(jìn)行交互的部分。
UI可以是一個(gè)實(shí)物上的面板,也可以是由程序所驅(qū)動(dòng)的顯示在屏幕上的界面。我們使用的應(yīng)用一般有是圖形化界面的,都可以看作是一種用戶(hù)接口,比如按鈕,窗口,圖標(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),用戶(hù)操作 UI 表達(dá)要實(shí)現(xiàn)的功能,而 UI 使用 API 來(lái)實(shí)際完成該功能。
2.API的分類(lèi)
(1)根據(jù)API提供者和消費(fèi)者所在的位置,可將API分為兩類(lèi):本地API:當(dāng)API的提供者和消費(fèi)者位于同一臺(tái)計(jì)算機(jī)上時(shí),稱(chēng)為本地API。遠(yuǎn)程API:當(dāng)API的提供者和消費(fèi)者位于不同的計(jì)算機(jī)上時(shí),稱(chēng)為遠(yuǎn)程API。 (2)根據(jù)API接口表現(xiàn)形式分類(lèi):
接口 | 協(xié)議 | 說(shuō)明 |
HTTP接口 | HTTP | 當(dāng)發(fā)起Http請(qǐng)求時(shí),Http會(huì)通過(guò)TCP建立起一個(gè)到服務(wù)器的連接通道,在請(qǐng)求需要的數(shù)據(jù)完畢后,Http會(huì)立即將TCP連接斷開(kāi),Http連接是一種短連接、無(wú)狀態(tài)的連接。 |
RPC接口 | HTTP、TCP、UDP、自定義協(xié)議 | RPC遠(yuǎn)程過(guò)程調(diào)用協(xié)議,它本質(zhì)上是一種Client/Server模式,就相當(dāng)于調(diào)用本地接口一樣調(diào)用遠(yuǎn)程服務(wù)的接口,支持多種數(shù)據(jù)傳輸方式,如Json、XML、Binary等。 |
WebService接口 | SOAP協(xié)議通過(guò)XML封裝數(shù)據(jù),Http協(xié)議傳輸數(shù)據(jù) | WebService是一個(gè)應(yīng)用程序向外界暴露出一個(gè)能通過(guò)Web進(jìn)行調(diào)用的API,也就是系統(tǒng)對(duì)外的接口,使用XML來(lái)封裝數(shù)據(jù),不依賴(lài)于語(yǔ)言,不依賴(lài)于平臺(tái)。 |
RESTFUL | HTTP | RESTFUL一種設(shè)計(jì)準(zhǔn)則,而不是一種規(guī)范,用不同的HTTP動(dòng)詞(如:GET、POST、DELETE、PUT)來(lái)表達(dá)不同的請(qǐng)求,降低開(kāi)發(fā)的復(fù)雜性,提高系統(tǒng)的可伸縮性。 |
WebSocket | TCP、UDP | WebSocket是一個(gè)持久化的雙向通信協(xié)議,可實(shí)現(xiàn)客戶(hù)端和服務(wù)器端之間即時(shí)通訊。在WebSocket中,客戶(hù)端和服務(wù)器只需要完成一次握手,就可以創(chuàng)建持久性的連接,并進(jìn)行雙向數(shù)據(jù)傳輸。 |
FTP | TCP/IP協(xié)議組中的協(xié)議之一 | FTP是文件傳輸協(xié)議,F(xiàn)TP協(xié)議包括兩個(gè)組成部分,其一為FTP服務(wù)器(存儲(chǔ)文件),其二為FTP客戶(hù)端。 |
(3)根據(jù)API接口訪問(wèn)形式分類(lèi):
訪問(wèn)形式 | 說(shuō)明 | 應(yīng)用 |
使用用戶(hù)令牌,通過(guò)Web API接口進(jìn)行數(shù)據(jù)訪問(wèn) | 可以有效識(shí)別用戶(hù)的身份,為用戶(hù)接口返回用戶(hù)相關(guān)的數(shù)據(jù)。 | 用戶(hù)信息維護(hù)、密碼修改、用戶(hù)管理等與用戶(hù)信息相關(guān)的數(shù)據(jù) |
使用安全簽名進(jìn)行數(shù)據(jù)提交 | 這種方式提交的數(shù)據(jù),URL連接的簽名參數(shù)是經(jīng)過(guò)安全一定規(guī)則的加密的,服務(wù)器收到數(shù)據(jù)后也經(jīng)過(guò)同樣規(guī)則的安全加密,確認(rèn)數(shù)據(jù)沒(méi)有被中途篡改后,再進(jìn)行數(shù)據(jù)修改處理。可以為不同接入方式(Web/APP/Winfrom等),指定不同的加密秘鑰,秘鑰是雙方約定的,并不在網(wǎng)絡(luò)連接上傳輸,連接傳輸?shù)囊话闶沁@個(gè)接入的AppID,服務(wù)器通過(guò)這個(gè)AppID來(lái)進(jìn)行簽名參數(shù)的加密對(duì)比,微信后臺(tái)的回調(diào)處理機(jī)制就類(lèi)似于這種處理方式。 | 獲取令牌、用戶(hù)注冊(cè)、處理業(yè)務(wù)數(shù)據(jù)等 |
提供公開(kāi)的接口調(diào)用,不需要傳入用戶(hù)令牌、或者對(duì)參數(shù)進(jìn)行加密簽名 | 這種接口一般較少,只是提供一些很常規(guī)的數(shù)據(jù)顯示而已。 | 查詢(xún)系統(tǒng)版本、時(shí)間、天氣等數(shù)據(jù) |
3.API安全
API安全基于多種安全規(guī)則的交叉,如下圖所示。
API安全的目標(biāo)(CIA):
安全目標(biāo)用于定義安全對(duì)于保護(hù)資產(chǎn)的實(shí)際意義。安全沒(méi)有統(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ù)期的讀者訪問(wèn); 完整性(Integrity):防止未授權(quán)的創(chuàng)建,修改和刪除; 可用性(Availability):當(dāng)用戶(hù)需要訪問(wèn)API時(shí),API總是可用的。 這三條原則始終很重要,在其他情景中,有一些原則和以上三條一樣重要。比如accountability/可追責(zé)(誰(shuí)做了什么)或者non-repudiation/抗抵賴(lài)(不能否認(rèn)做過(guò)的行為)等。
常見(jiàn)的API風(fēng)險(xiǎn)(STRIDE):
欺騙(Spoofing):偽裝成某人; 干預(yù)(Tampering):將不希望被修改的數(shù)據(jù)、消息或設(shè)置改掉; 否認(rèn)(Repudiation):拒絕承認(rèn)做過(guò)的事; 信息泄露(Information disclosure):將你希望保密的信息披露出來(lái); 拒絕服務(wù)(Denial of service):阻止用戶(hù)訪問(wèn)信息和服務(wù); 越權(quán)(Elevation ofprivilege):做了你不希望他能做的事。
風(fēng)險(xiǎn)與安全機(jī)制的對(duì)應(yīng)關(guān)系:
認(rèn)證=>欺騙:確保你的用戶(hù)或客戶(hù)端真的是他(它)們自己 ; 授權(quán)=>信息泄漏/干預(yù)/越權(quán):確保每個(gè)針對(duì)API的訪問(wèn)都是經(jīng)過(guò)授權(quán)的; 審計(jì)=>否認(rèn):確保所有的操作都被記錄,以便追溯和監(jiān)控; 流控=>拒絕服務(wù):防止用戶(hù)請(qǐng)求淹沒(méi)你的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ì)象訪問(wèn)標(biāo)識(shí)符而容易發(fā)生數(shù)據(jù)泄漏和未經(jīng)授權(quán)的數(shù)據(jù)操作。例如,攻擊者可以利用一個(gè)可迭代的整數(shù)對(duì)象標(biāo)識(shí)符。
用戶(hù)身份驗(yàn)證中斷:身份驗(yàn)證機(jī)制的實(shí)現(xiàn)通常不正確或缺失,使得攻擊者可以利用實(shí)現(xiàn)缺陷來(lái)訪問(wèn)數(shù)據(jù)。
過(guò)多的數(shù)據(jù)暴露:惡意行動(dòng)者會(huì)試圖直接訪問(wèn) API(可能通過(guò)重播有效請(qǐng)求),或者嗅探服務(wù)器和 API 之間的流量。對(duì) API 操作和可用數(shù)據(jù)的分析可能會(huì)為攻擊者生成敏感數(shù)據(jù),而這些敏感數(shù)據(jù)并沒(méi)有展示在前端應(yīng)用程序中,也沒(méi)有被前端應(yīng)用程序使用。
缺少資源和速率限制:缺少速率限制可能會(huì)導(dǎo)致數(shù)據(jù)外泄或?qū)蠖朔?wù)的成功 DDoS 攻擊,進(jìn)而導(dǎo)致所有使用者的服務(wù)中斷。
功能級(jí)別授權(quán)中斷:具有不同層次結(jié)構(gòu)、組和角色的復(fù)雜訪問(wèn)控制策略,以及管理功能和常規(guī)功能之間不明確的分離,都會(huì)導(dǎo)致授權(quán)缺陷。通過(guò)利用這些問(wèn)題,攻擊者可以訪問(wèn)其他用戶(hù)的資源或管理功能。
大量分配:如果一個(gè) API 提供的字段超過(guò)了客戶(hù)端對(duì)給定操作的需求,攻擊者可能會(huì)注入過(guò)多的屬性來(lái)對(duì)數(shù)據(jù)執(zhí)行未經(jīng)授權(quán)的操作。攻擊者可以通過(guò)檢查請(qǐng)求和響應(yīng)或其他 API 的格式來(lái)發(fā)現(xiàn)未記錄的屬性,或進(jìn)行猜測(cè)。如果你不使用強(qiáng)類(lèi)型的編程語(yǔ)言,則此漏洞尤其適用。
安全配置錯(cuò)誤:攻擊者可能會(huì)試圖利用安全配置錯(cuò)誤漏洞,例如:缺少安全強(qiáng)化措施、啟用了不必要的功能、不必要地向 Internet 開(kāi)放了網(wǎng)絡(luò)連接、使用了弱協(xié)議或密碼、可能允許未經(jīng)授權(quán)地訪問(wèn)系統(tǒng)的其他設(shè)置或終結(jié)點(diǎn)。
注入:接受用戶(hù)數(shù)據(jù)的任何終結(jié)點(diǎn)都可能會(huì)受到注入攻擊。示例包括但不限于:命令注入,其中惡意行動(dòng)者試圖更改 API 請(qǐng)求以在托管 API 的操作系統(tǒng)上執(zhí)行命令;SQL 注入,其中惡意行動(dòng)者試圖更改 API 請(qǐng)求以針對(duì) API 依賴(lài)的數(shù)據(jù)庫(kù)執(zhí)行命令和查詢(xún)。
資產(chǎn)管理不當(dāng):與不當(dāng)?shù)馁Y產(chǎn)管理相關(guān)的漏洞包括:缺少適當(dāng)?shù)?API 文檔或所有權(quán)信息、舊版 API 過(guò)多,可能缺少安全修補(bǔ)程序。
日志記錄和監(jiān)視不足:如果日志記錄和監(jiān)視不足,加上與事件響應(yīng)的整合缺失或無(wú)效,攻擊者就能夠進(jìn)一步攻擊系統(tǒng)、保持持久性、轉(zhuǎn)向更多系統(tǒng)進(jìn)行篡改,以及提取或銷(xiāo)毀數(shù)據(jù)。大多數(shù)違反行為研究表明,檢測(cè)到違反行為的時(shí)間超過(guò) 200 天,通常是由外部方而不是通過(guò)內(nèi)部流程或監(jiān)視方式檢測(cè)到的。
5.API協(xié)議
SOAP:簡(jiǎn)單對(duì)象訪問(wèn)協(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ì)象訪問(wèn)協(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 依賴(lài)于標(biāo)準(zhǔn)協(xié)議,尤其是 HTTP 和 SMTP,并為 Web 服務(wù)提供數(shù)據(jù)傳輸。SOAP 的整個(gè)消息都是被寫(xiě)在 XML 中的,因此它能夠獨(dú)立于各種語(yǔ)言在所有操作系統(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 被稱(chēng)為RESTful API。對(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。REST與SOAP又有著根本的區(qū)別,SOAP是一種協(xié)議,而REST是一種架構(gòu)模式。這意味著RESTful Web API沒(méi)有官方標(biāo)準(zhǔn)。只要API 符合RESTful系統(tǒng)的6個(gè)導(dǎo)向性約束,就算作RESTful API:客戶(hù)端/服務(wù)器架構(gòu)、無(wú)狀態(tài)、可緩存性、分層系統(tǒng)、統(tǒng)一接口、按需代碼(可選)。
JSON-RPC:JSON-RPC,是一個(gè)無(wú)狀態(tài)且輕量級(jí)的遠(yuǎn)程過(guò)程調(diào)用(RPC)傳送協(xié)議,其傳遞內(nèi)容透過(guò) JSON 為主。相較于一般的 REST 透過(guò)網(wǎng)址(如 GET /user)調(diào)用遠(yuǎn)程服務(wù)器,JSON-RPC 直接在內(nèi)容中定義了欲調(diào)用的函數(shù)名稱(chēng)(如 {"method": "getUser"}),這也令開(kāi)發(fā)者不會(huì)陷于該使用 PUT 或者 PATCH 的問(wèn)題之中。
gRPC:gRPC 是一個(gè)開(kāi)源 API,也屬于 RPC 的范疇,是一個(gè)高性能,開(kāi)源和通用的RPC框架,基于Protobuf序列化協(xié)議開(kāi)發(fā),且支持眾多開(kāi)發(fā)語(yǔ)言。面向服務(wù)端和協(xié)議端,基于http/2設(shè)計(jì),帶來(lái)諸如雙向流,流控,頭部壓縮,單TCP連接上的多路復(fù)用請(qǐng)求等特性。這些特性使得其在移動(dòng)設(shè)備上表現(xiàn)的更好,更省電和節(jié)省空間。在gPRC里客戶(hù)端可以向調(diào)用本地對(duì)象一樣直接調(diào)用另一臺(tái)不同機(jī)器上服務(wù)端應(yīng)用的方法,使得您能夠更容易地創(chuàng)建分布式應(yīng)用和服務(wù)。
編輯:黃飛
-
API
+關(guān)注
關(guān)注
2文章
1620瀏覽量
64045 -
編程接口
+關(guān)注
關(guān)注
1文章
38瀏覽量
8151
原文標(biāo)題:API安全基礎(chǔ)理論
文章出處:【微信號(hào):Tide安全團(tuán)隊(duì),微信公眾號(hào):Tide安全團(tuán)隊(duì)】歡迎添加關(guān)注!文章轉(zhuǎn)載請(qǐng)注明出處。
發(fā)布評(píng)論請(qǐng)先 登錄
數(shù)據(jù)的表現(xiàn)形式與運(yùn)算
編程是一種思維方式,而代碼是一種表現(xiàn)形式,硬件只不過(guò)是對(duì)思維方式的物理體現(xiàn)
電梯的干擾表現(xiàn)形式有哪幾種?
can線問(wèn)題具體表現(xiàn)形式
安川變頻器在出現(xiàn)故障代碼時(shí)有哪幾種表現(xiàn)形式
什么是API/DS3D
API-Shop-OCR-營(yíng)業(yè)執(zhí)照識(shí)別API接口Python調(diào)用示例代碼說(shuō)明

短信API接口的應(yīng)用
中國(guó)聯(lián)通張涌:5G將為電競(jìng)帶來(lái)新的表現(xiàn)形式和產(chǎn)業(yè)空間
關(guān)于API接口相關(guān)知識(shí) API的權(quán)限與安全問(wèn)題
如何設(shè)計(jì)一個(gè)優(yōu)雅的API接口
API+DevOps:華為云API Arts一體化平臺(tái),端到端呵護(hù)您的API
api接口怎么使用
api網(wǎng)關(guān) kong 教程入門(mén)

評(píng)論