您可能認(rèn)為需要編寫數(shù)百行代碼才能突破最安全的網(wǎng)絡(luò)防御。但實際上，網(wǎng)絡(luò)犯罪分子通常會通過 API 的標(biāo)準(zhǔn)功能以您意想不到的方式訪問您的敏感數(shù)據(jù)。
這些漏洞被稱為業(yè)務(wù)邏輯缺陷，它們是對您的 API 安全的最大威脅。
業(yè)務(wù)邏輯漏洞是 API 設(shè)計中的缺陷，它允許攻擊者操縱合法功能、數(shù)據(jù)或工作流程來達(dá)到惡意目標(biāo)。
業(yè)務(wù)邏輯缺陷非常普遍，以至于五大OWASP?API 攻擊媒介中有四個與這類漏洞有關(guān)，因此了解它們的工作原理至關(guān)重要。
從提升用戶權(quán)限到破壞數(shù)據(jù)庫，關(guān)鍵因素在于這些缺陷是由于對系統(tǒng)不同部分的工作和交互方式的錯誤假設(shè)而產(chǎn)生的。
舉一個現(xiàn)實世界的例子，業(yè)務(wù)邏輯漏洞是導(dǎo)致美國郵政服務(wù)大規(guī)模數(shù)據(jù)泄露和 6000 萬條敏感用戶數(shù)據(jù)記錄泄露的根本原因，給該組織的聲譽(yù)留下了永久的污點。
閱讀更多：什么是 API 安全以及它為何如此重要
API 是允許通過防火墻的管道。如果測試不當(dāng)，它們可能會存在漏洞（本質(zhì)上是設(shè)計上的漏洞），存在業(yè)務(wù)邏輯缺陷。
– Corey Ball，網(wǎng)絡(luò)安全咨詢經(jīng)理兼《Hacking API》作者
當(dāng)攻擊者試圖使用惡意軟件、SQL 注入或其他技術(shù)訪問您的網(wǎng)絡(luò)系統(tǒng)時，即使是最基本的安全措施也可能會觸發(fā)警報并警告您的安全團(tuán)隊正在發(fā)生網(wǎng)絡(luò)攻擊。
如果存在商業(yè)邏輯缺陷，那么情況就完全不同了。
想象一下這樣一個場景：您的開發(fā)團(tuán)隊忽略了允許在顯示用戶銀行賬戶當(dāng)前余額的頁面上使用 HTTP 請求方法的限制協(xié)議。攻擊者可能會使用 PUT 方法來編輯該值或完全刪除該記錄。
由于此類邏輯缺陷發(fā)生在合法 API 功能范圍內(nèi)，因此它們通常不會在您的數(shù)據(jù)被泄露很久之后觸發(fā)任何警報（如果有的話）。
企業(yè)因數(shù)據(jù)泄露而遭受財務(wù)損失、客戶信心下降、聲譽(yù)受損，甚至破產(chǎn)。
閱讀更多：什么是 API 測試？
雖然業(yè)務(wù)邏輯缺陷是基于給定 API 架構(gòu)的獨特漏洞，但我們可以找出最常見的類型，以幫助您領(lǐng)先于網(wǎng)絡(luò)犯罪分子。
網(wǎng)頁通常使用 HTML 構(gòu)建，其中包含可在客戶端使用 JavaScript 等腳本語言更改的動態(tài)元素。但是，當(dāng)這些元素容易受到外部參與者的操縱時，它們可能會帶來巨大的安全風(fēng)險。
如果攻擊者可以改變這些元素以進(jìn)行未經(jīng)授權(quán)的查詢，他們就可以繞過任何防火墻來訪問敏感數(shù)據(jù)。
一種稱為授權(quán)繞過的漏洞允許某些用戶訪問超出其授權(quán)級別的信息。由于這種漏洞的范圍非常廣泛，因此許多級別和實例的網(wǎng)絡(luò)攻擊都屬于這一類別也就不足為奇了。
損壞的對象級授權(quán) (BOLA) 已經(jīng)位居 OWASP API 安全前 10 名榜單的首位 – 這是有充分理由的。API 提供商在確保用戶通過 API 身份驗證方面做得非常出色，因此他們希望確保合法用戶可以訪問。
但最容易被忽視的一點是授權(quán)，即確保用戶 A 無法訪問用戶 B 的資源。隱藏資源 ID 是一回事，但重要的一點是用戶 A 根本無法訪問、交互或更改用戶 B 的資源。
授權(quán)繞過的兩種最常見子類型包括：
應(yīng)該實施強(qiáng)大的授權(quán)和身份驗證協(xié)議（例如OAuth或 OpenID），以防止繞過授權(quán)并保護(hù)您的系統(tǒng)免受此攻擊媒介的侵害。
攻擊者可以通過向開發(fā)人員未能預(yù)料到的 API 提供輸入來觸發(fā)系統(tǒng)的意外響應(yīng)，從而可能暴露敏感數(shù)據(jù)。
許多 API 缺乏其他攻擊載體所具備的安全控制，這使得它們相當(dāng)于死星的熱排氣口：一條通往企業(yè)厄運(yùn)和毀滅的道路。
在處理非常規(guī)用戶輸入時，企業(yè)必須非常小心，并對所有數(shù)據(jù)類型（包括意外的值和字符）進(jìn)行細(xì)致的測試。
他們可以通過運(yùn)行一系列模糊測試來向系統(tǒng)提供不同類型的隨機(jī)用戶輸入來實現(xiàn)這一點。
許多IT系統(tǒng)過于信任其授權(quán)用戶，從而產(chǎn)生大量安全潛在的安全漏洞。
如果攻擊者可以訪問真實管理員用戶的登錄憑據(jù)（無論是通過網(wǎng)絡(luò)釣魚攻擊還是簡單地在暗網(wǎng)上購買這些數(shù)據(jù)），他們就可以輕松潛入、訪問數(shù)據(jù)庫并造成數(shù)據(jù)泄露，類似于導(dǎo)致30 億條雅虎記錄泄露的事件。
為了保證您自己的安全，您必須假設(shè)每個用戶都是潛在的安全威脅，無論是否獲得授權(quán)。
這就是零信任安全模型的全部內(nèi)容，確保每個用戶都得到適當(dāng)?shù)氖跈?quán)和身份驗證——同時在允許他們進(jìn)入后監(jiān)控他們的行為。
特定領(lǐng)域缺陷是系統(tǒng)中僅存在于特定領(lǐng)域的弱點。
與影響整個應(yīng)用程序的一般漏洞不同，特定領(lǐng)域的缺陷僅存在于特定的模塊或功能中。
這個關(guān)鍵方面使得它們更難識別和修復(fù)，因為您需要深入了解攻擊者可能通過濫用特定領(lǐng)域的缺陷來嘗試實現(xiàn)的目標(biāo)。
您掌握的有關(guān)最終用戶行為的信息越多，就越容易準(zhǔn)確識別和標(biāo)記可疑行為。
一個好的起點是利用 API 管理工具的分析和報告功能來識別和分析使用模式。
有效的 API 安全測試至關(guān)重要。如果我們回想一下 USPS 數(shù)據(jù)泄露事件，該事件是在 6000 萬份私人數(shù)據(jù)泄露事件發(fā)生前一個月進(jìn)行的測試。這并不是說您只是對 API 進(jìn)行一般性測試，而是使用正確的工具和技術(shù)來幫助您的 API 安全漏洞管理程序很好地防止此類攻擊。
現(xiàn)在您已經(jīng)了解了最常見的業(yè)務(wù)邏輯缺陷類型，是時候采取一些措施來解決這個問題了。
以下是測試 API 安全性中的業(yè)務(wù)邏輯缺陷的一些技巧：
確保您的 API 安全性嚴(yán)密的第一步是設(shè)計盡可能多的測試用例，以涵蓋所有可能的攻擊場景。
測試的攻擊場景越多，識別底層業(yè)務(wù)邏輯漏洞的機(jī)會就越大。
這就是您需要深入了解 API 的各個方面以創(chuàng)建真正起作用的測試用例的地方。
API 可以直接訪問敏感數(shù)據(jù)。它們連接到您的應(yīng)用服務(wù)器、微服務(wù)和數(shù)據(jù)庫應(yīng)用程序，因此必須非常安全。而且許多 API 的權(quán)限過多 – 對于其中一些 API，您甚至沒有意識到它們可能泄露了憑據(jù)。
– Cecil Pineda，CISO XC 聯(lián)合創(chuàng)始人
默認(rèn)將用戶輸入視為安全威脅。此方法需要驗證所有用戶輸入，無論其來自何處或由誰提交。
這樣，您就可以保護(hù)自己免受整個 API 漏洞層的攻擊，并大幅降低與內(nèi)部威脅相關(guān)的風(fēng)險。
所有無效輸入都應(yīng)被記錄并最終進(jìn)行監(jiān)控，以發(fā)現(xiàn)可能導(dǎo)致數(shù)據(jù)泄露的潛在漏洞。
零信任安全模型已被證明可以有效減少網(wǎng)絡(luò)安全事件的數(shù)量，因此將其應(yīng)用于您的 API 是一個好主意。
確保您的 API 有足夠的文檔記錄，以便開發(fā)人員能夠了解其工作原理。
這將提高您的采用率并幫助您發(fā)現(xiàn)業(yè)務(wù)邏輯中的任何錯誤或不一致之處。
記錄良好的 API 將使您更容易測試安全漏洞。
API 日志記錄和監(jiān)控對于保護(hù)您的用戶免受網(wǎng)絡(luò)攻擊至關(guān)重要。
沒有任何系統(tǒng)能夠完全安全，因此對于您的團(tuán)隊來說，不斷跟蹤和分析所有可審計事件（從失敗的登錄到大額交易）至關(guān)重要。
一些用戶操作可能會指向一個關(guān)鍵的業(yè)務(wù)邏輯漏洞，因此要密切關(guān)注您的日志。
如果您對這些信息感到不知所措或者不知道從哪里開始，那么自動化您的安全測試是一個很好的起點。
問題在于，即使擁有一支開發(fā)團(tuán)隊，業(yè)務(wù)邏輯缺陷也極難識別和檢測。
通常，開發(fā)人員是你工資單上最昂貴的員工。
流行的 API 測試工具缺乏真正保護(hù)您的 API 所需的深度，因為安全性不是它們的專長，只允許您自動執(zhí)行仍然必須手動創(chuàng)建的數(shù)千個測試用例。
文章來源：Why Business Logic Vulnerabilities Are Your #1 API Security Risk