耳根,官场小说排行榜

新聞中心

這里有您想知道的互聯(lián)網(wǎng)營銷解決方案

現(xiàn)代API滲透技術(shù)

在由機械工業(yè)出版社發(fā)行的《API安全技術(shù)與實戰(zhàn)》一書中如果時間充分的話關(guān)于API滲透測試的內(nèi)容個人覺得還可以更豐滿一些。近期，在國外網(wǎng)站看到一篇不錯的文章，轉(zhuǎn)譯過來供大家學(xué)習(xí)參考。

安順網(wǎng)站建設(shè)公司創(chuàng)新互聯(lián)建站,安順網(wǎng)站設(shè)計制作，有大型網(wǎng)站制作公司豐富經(jīng)驗。已為安順上千提供企業(yè)網(wǎng)站建設(shè)服務(wù)。企業(yè)網(wǎng)站搭建\外貿(mào)營銷網(wǎng)站建設(shè)要多少錢，請找那個售后服務(wù)好的安順做網(wǎng)站的公司定做！

在過去的一些年里API 不像現(xiàn)在那么普遍，這是由于單頁應(yīng)用程序 (SPA) 流行的結(jié)果。10 年前，Web 應(yīng)用程序傾向于遵循單一模式，即大多數(shù)應(yīng)用程序在呈現(xiàn)給用戶之前在服務(wù)器端生成。任何需要的數(shù)據(jù)都將由生成 UI 的同一臺服務(wù)器直接從數(shù)據(jù)庫中收集。它的形式看起來像這樣：

圖：10年前的Web應(yīng)用模型

現(xiàn)代 Web 應(yīng)用程序通常是與SPA（單頁應(yīng)用程序）不同的模型。在這個模型中，通常由一個 API 后端、一個 JavaScript UI 和數(shù)據(jù)庫構(gòu)成。API 只是作為 web 應(yīng)用程序和數(shù)據(jù)庫之間的接口，對 API 的所有請求都是直接從 Web 瀏覽器發(fā)出的。

圖表：現(xiàn)代 Web 應(yīng)用程序模型

相對SPA形式，現(xiàn)代Web應(yīng)用程序模型是一個更好的解決方案，因為它更容易擴展并允許更專業(yè)的開發(fā)人員為項目工作，即前端開發(fā)人員只關(guān)注前端工作，而后端開發(fā)人員則在 API 上工作。這些應(yīng)用程序也往往感覺更快速，因為不是每個請求都需要頁面加載。

然而，同一頁面的不同組件也會神奇地刷新，會給使用者與原生應(yīng)用程序類似的感覺。這也使得這種模型也變得越來越流行，因為大量不同的前端 JavaScript 框架（React、Vue 和 Angular 等）已經(jīng)出現(xiàn)。

這就是說——現(xiàn)代應(yīng)用程序到處都有 API，所以我們應(yīng)該學(xué)習(xí)如何破解和保護(hù)它們。

API測試配置

Postman 是一個方便進(jìn)行 API 安全測試的應(yīng)用程序。你可以從其官方網(wǎng)站下載 Postman 。本質(zhì)上，Postman 只是另一個 HTTP 客戶端，可用于輕松修改并向 API 發(fā)送請求。

如果你的文件中有一組 API 請求，可以通過單擊應(yīng)用程序左上角的“導(dǎo)入”按鈕將它們導(dǎo)入 Postman ：

導(dǎo)入集合后，你將看到 Postman 中加載的 API 調(diào)用，如下所示：

通過單擊單個 API 調(diào)用，將在右側(cè)看到完整的 API 請求。同時，請求的不同部分將被分解為Params、Authorization、Headers、RequestBody等部分，這將幫助你輕松地處理每個部分。

你可以像在 BurpSuite 中一樣修改請求標(biāo)頭和正文，分析對測試用例的響應(yīng)，你只需點擊右上角的發(fā)送按鈕即可。

Postman 中的響應(yīng)視圖看起來像這樣，響應(yīng)也分為不同的部分，如正文、Cookie、標(biāo)題等，你可以仔細(xì)分析每個部分。

由于 Postman 專門用于 API，因此有許多內(nèi)置選項來測試 API 中主要存在的功能。例如，通過單擊請求方法旁邊的下拉箭頭，你可以看到大量不同的請求動詞以進(jìn)行測試：

對于 GET 請求，你可以通過Params選項卡添加/刪除以及編輯參數(shù)。當(dāng)你選中/取消選中參數(shù)時，你可以看到它們相應(yīng)地出現(xiàn)在 URI 字段中。

在添加授權(quán)值時，Postman 為你提供了多種選項供你選擇，你可以根據(jù)目標(biāo) API 處理授權(quán)的方式選擇一個。

你還可以按照以下步驟將授權(quán)值添加到整個集合或子集合：

單擊集合/子集合名稱旁邊的三個點，然后選擇“編輯”選項

轉(zhuǎn)到“授權(quán)”選項卡，選擇身份驗證類型并添加其值。

最后，轉(zhuǎn)到單個 API 請求并選擇Inherit auth from parent選項

這將為你省去為每個請求設(shè)置授權(quán)值的麻煩。

Postman 的另一個方便的特性是它允許用戶使用 BurpSuite 代理 API 請求。你可以執(zhí)行以下步驟進(jìn)行設(shè)置：

從右上角的下拉菜單中單擊設(shè)置選項

轉(zhuǎn)到代理選項卡并執(zhí)行以下操作：

a) 關(guān)閉使用系統(tǒng)代理

b) 打開添加自定義代理配置

c) 設(shè)置了代理服務(wù)器的IP地址和端口，以配合你打嗝套房代理設(shè)置。默認(rèn)值為 127.0.0.1 和 8080。你的最終設(shè)置應(yīng)如下所示：

3. 要在沒有任何錯誤的情況下代理 HTTPS 請求，你可以在“常規(guī)”選項卡下關(guān)閉SSL 證書驗證。

API漏洞類型

API 有多種不同的形式，攻擊 API 的方法會因這些形式的不同而有很大差異。在一篇文章中涵蓋所有攻擊類型是不可能的，下面我重點介紹其中一部分。

API 暴露

與 Web 應(yīng)用程序非常相似，API 可以具有不同級別的可見性。有些可以通過互聯(lián)網(wǎng)訪問，而有些則只能在內(nèi)部使用。API 攻擊方式之一就是簡單地訪問你應(yīng)該無法訪問的 API。這可以通過以下方法來達(dá)到訪問目的，包括：

強制瀏覽：如果幸運的話，僅供內(nèi)部使用的 API 可能會意外暴露在 Internet 上，這可能是由于配置錯誤導(dǎo)致，或者僅僅是因為假設(shè)沒有人能夠找到它。在API攻擊時可以通過多種方式發(fā)現(xiàn)，比如分析 JavaScript 文件、分析暴露的源代碼、觀察主機名（例如api.internal.example.com）和 Google dorking等。
反射或旋轉(zhuǎn)：比如在外部主機上發(fā)現(xiàn)像 SSRF 這樣的漏洞可能允許你轉(zhuǎn)向內(nèi)部 API。

預(yù)防措施

有許多最佳實踐可以幫助你減輕無意暴露 API 的風(fēng)險，包括實施嚴(yán)格的部署實踐、通過 IAM 和網(wǎng)絡(luò)分段強制執(zhí)行最小權(quán)限原則等。

錯誤配置的緩存

對于需要身份驗證的 API，返回的數(shù)據(jù)通常是動態(tài)生成的，并且范圍限定為每個 API 密鑰。例如，/api/v1/userdetails以 Bob 身份訪問應(yīng)返回 Bob 的詳細(xì)信息，而以 Jane 身份訪問同一端點應(yīng)返回 Jane 的詳細(xì)信息。

當(dāng) API 不使用標(biāo)準(zhǔn)Authorization標(biāo)頭，而是使用自定義標(biāo)頭（如X-API-Key. 緩存服務(wù)器可能不會將此識別為經(jīng)過身份驗證的請求，并且可能會緩存它。

如果是這種情況，并且沒有Cache-Control或Pragma標(biāo)題，則簡單地訪問/api/v1/userdetails可能會泄露另一個用戶的信息。

預(yù)防措施

對此問題的解決方法是實現(xiàn)Cache-Control或Pragma標(biāo)頭，并使用標(biāo)準(zhǔn)Authorization標(biāo)頭。

暴露的令牌

我們不應(yīng)該忽視最基本的身份驗證攻擊，通過發(fā)現(xiàn) API 密鑰可能會獲取 API 的訪問權(quán)限。更糟糕的是，那些僅供內(nèi)部使用的 API，通常不需要實現(xiàn)復(fù)雜的身份驗證流程，通常實現(xiàn)靜態(tài)令牌作為其身份驗證，并將令牌存儲在代碼存儲庫、客戶端 JavaScript、攔截流量等中。

預(yù)防措施

在DevOps 管道中，實施代碼掃描檢測 API 密鑰部署到它們不應(yīng)該存在的地方，在部署之前捕獲它們。另外，一些代碼存儲庫提供者（包括GitHub），在推送 API 密鑰之前檢測它們。

JWT的弱點

如果你的 API 令牌是由兩個點 (.) 分隔的三個 base64blob構(gòu)成，則它可能是一個JSON Web 令牌 (JWT)。這些令牌在理論上是安全的，但是有很多方法會以引入安全問題的方式來弄亂實現(xiàn)。在我們深入研究 JWT 攻擊之前，我們將快速閱讀 JWT 入門。這是一個示例 JWT 令牌，根據(jù)你的閱讀習(xí)慣進(jìn)行了著色：

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9。eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9liwiaWF0IjoxNTE2MjM5MDIyfQ . SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

有三個由點分隔的 base64 編碼字符串，第一部分（紅色）是header. 第二個（紫色）是payload，第三個（藍(lán)色）是signature。

如果我們解碼第一部分，也稱為標(biāo)頭，我們將看到以下內(nèi)容：

{
"alg": "HS256",
"typ": "JWT"
}

這就是令牌所使用的算法 (HS256) 和令牌類型 (JWT)，如果你之前沒有使用過 JWT，你可能會想“為什么我們需要算法？”

令牌的第二部分也稱為有效載荷，解碼后我們將看到以下內(nèi)容：

{
"sub": "1234567890",
"name": "John Doe",
"iat": 1516239022
}

此部分可以包含任何內(nèi)容，但至少需要包含用戶標(biāo)識符和超時 (iat)。

令牌的第三部分（也稱為簽名）用密鑰對前兩部分進(jìn)行簽名。在這種情況下，它使用 HS256 算法進(jìn)行簽名，它可以通過查看標(biāo)頭中的“alg”值來確定。一般來說私鑰應(yīng)該只為應(yīng)用程序的所有者知道。當(dāng)應(yīng)用程序收到 JWT 令牌時，它可以通過解密簽名并將其與標(biāo)頭和有效負(fù)載中的數(shù)據(jù)進(jìn)行比較來驗證令牌是否合法。如果數(shù)據(jù)匹配則驗證數(shù)據(jù)，否則無效。

那么為什么會有人使用 JWT？這是因為它不需要服務(wù)器端會話管理。傳統(tǒng)上，當(dāng)用戶登錄時，應(yīng)用程序會為用戶分配一個秘密令牌并將該令牌存儲在數(shù)據(jù)庫中。每當(dāng)用戶使用他們的令牌發(fā)出請求時，應(yīng)用程序需要檢查令牌是否在數(shù)據(jù)庫中。如果是，則允許用戶繼續(xù)，否則不允許。當(dāng)我們使用 JWT 時，我們引入了一種信任從客戶端發(fā)送的數(shù)據(jù)的方法，而不是僅僅信任存儲在數(shù)據(jù)庫中的信息。如果應(yīng)用程序收到可以使用密鑰驗證的 JWT 令牌，則應(yīng)用程序沒有理由不信任它。

正如我們之前提到的，理論上 JWT 令牌是完全安全的。問題是它們通常以不安全的方式實施。這里有些例子：

None 算法：JWT 的一些實現(xiàn)將允許你指定“None”作為算法。如果算法為“無”，應(yīng)用程序?qū)⒉粫z查簽名的有效性，因此你可以簡單地將有效負(fù)載更新為你想要的任何內(nèi)容。最明顯的利用是將用戶 ID 更新為另一個用戶以控制他們的帳戶。
暴力破解：可以暴力破解 JWT 令牌的密鑰。這種攻擊的可行性將取決于密鑰的強度。你可以嘗試使用此工具破解 JWT 令牌?？梢栽贏uth0 的博客上找到有關(guān)該方法的完整文章。
簡單地改變有效載荷：在極少數(shù)情況下，服務(wù)器可能會完全跳過令牌驗證并信任有效載荷中的數(shù)據(jù)。雖然我沒有親眼見過這種情況，但我已經(jīng)讀到它發(fā)生在野外！
將 RS 切換到 HS：一些較舊的 JWT 庫存在一個缺陷，你可以在其中欺騙期望使用非對稱加密簽名的令牌的應(yīng)用程序接受對稱簽名的令牌。最終被使用的對稱簽名令牌實際上是一個公鑰，它通?？梢砸阅撤N方式獲得，或者從他們的 HTTPS 密鑰中重用。有這種方法的一個偉大的書面記錄在這里。
在超時未兌現(xiàn)，那么JWT令牌仍然有效，直到永遠(yuǎn)。

預(yù)防措施

JWT 弱點的最佳緩解方法是為所有 JWT 操作使用廣泛使用的、信譽良好的 JWT 庫。

授權(quán)問題/IDOR

授權(quán)是檢查經(jīng)過身份驗證的用戶是否有權(quán)訪問特定用戶的過程。與授權(quán)相關(guān)的常見漏洞稱為不安全的直接對象引用 (IDOR)。例如，在發(fā)票應(yīng)用程序的 API 中，我們可能有一個端點用于獲取發(fā)票的詳細(xì)信息：/api/v1/invoices/?id=1234

該id參數(shù)是應(yīng)返回的發(fā)票的標(biāo)識符，當(dāng)這個端點是安全的，我應(yīng)該只能獲得屬于我的發(fā)票的詳細(xì)信息。例如，如果我創(chuàng)建了一個 ID 為 1234 的發(fā)票，那么它應(yīng)該返回1234的詳細(xì)信息；

如果我嘗試訪問不是通過瀏覽創(chuàng)建的發(fā)票/api/v1/invoices/?id=1233，它應(yīng)該返回錯誤。如果我能夠更改標(biāo)識符并可以查看其他用戶（如1233）的發(fā)票詳細(xì)信息，那么這就是一個稱為 IDOR 的漏洞。

為了解決 IDOR 問題，當(dāng)今許多 API 都使用 UUID 作為對象標(biāo)識符。UUID 如下所示：

f1af4910-e82f-11eb-beb2-0242ac130002

需要注意的是，使用 UUID 作為標(biāo)識符并不是緩解 IDOR 問題的有效方法。事實上，UUID RFC特地將這一點稱為：

不要假設(shè) UUID 很難猜測；例如，它們不應(yīng)該用作安全功能（僅擁有就可以訪問的標(biāo)識符）?？深A(yù)測的隨機數(shù)源會加劇這種情況。

雖然將 UUID 用作對象 ID 而不是整數(shù)是一種很好的做法，但它們永遠(yuǎn)不應(yīng)用作抵御 IDOR 攻擊的唯一保護(hù)措施。

預(yù)防措施

授權(quán)問題通常很難以自動化方式檢測。代碼庫的結(jié)構(gòu)一般難以在特定端點上發(fā)生授權(quán)錯誤的方式設(shè)置。為實現(xiàn)這一點，應(yīng)盡可能在堆棧上實施授權(quán)措施。比如在類級別或使用中間件級別。

未記錄的端點

在API攻擊過程中，遇到?jīng)]有API文檔（或至少沒有你可以訪問的文檔）的情況是很常見的。帶有文檔的 API 具有超出文檔內(nèi)容的其他訪問端點也很常見。有時，這些端點的存在本身可能是一個安全問題——例如，端點可能是為管理目的而設(shè)計的，并允許你作為弱勢用戶執(zhí)行管理任務(wù)。其他時候，這些端點可能會出現(xiàn)漏洞，因為它們沒有像容易發(fā)現(xiàn)的端點那樣經(jīng)過徹底的測試。

我們可以利用以下幾種方法來發(fā)現(xiàn)未記錄的端點：

使用與 API 接口的應(yīng)用程序并捕獲流量。比如Burp Suite。
設(shè)置 Burp Suite 來代理應(yīng)用程序流量
使用所有應(yīng)用程序功能
通過查看目標(biāo)選項卡檢查使用的端點。
觀察錯誤。許多 API 會給出足夠詳細(xì)的錯誤來枚舉未記錄的端點和參數(shù)。例如，向發(fā)送一個空白的 POST 請求/api/v1/randomstring可能會導(dǎo)致出現(xiàn)類似Invalid route, valid routes are [/users,/invoices,/customers].
分析客戶端 JavaScript。如果你知道與 API 交互的應(yīng)用程序，你可以分析該應(yīng)用程序中的 JavaScript 以收集可訪問的 API 端點列表。
使用Kiterunner，這是Assetnote的一個工具，專為 API 上的內(nèi)容發(fā)現(xiàn)而設(shè)計
暴力猜測端點，Assetnote 網(wǎng)站上有一些優(yōu)秀的API詞表

預(yù)防措施

擁有一個強大的、結(jié)構(gòu)化的方法和流程來記錄 API 功能可以避免很多麻煩。

Swagger正是這一點的絕佳標(biāo)準(zhǔn)。此外，最好在編碼之前用文檔規(guī)劃 API 功能，而不是相反。

不同API版本問題

當(dāng)一個組織發(fā)布一個 API 時，它可能會與許多不同的應(yīng)用程序接口。如果 API 在任何時候更新，它可能會為這些應(yīng)用程序中的一個或多個API引入重大更改。出于這個原因，多個 API 版本通常被實現(xiàn)為支持舊的API 模式的一種方式，同時也隨著時間的推移為新用戶升級 API。

測試 API 的所有版本是一個值得投入的攻擊方式。舊版本可能仍然存在已在新版本中修復(fù)的安全問題，而較新的/前沿/測試版可能引入了新的安全問題。

api 版本控制的常見模式是：

/api/v1/

/api/v2/

/api/beta/

檢查非生產(chǎn)環(huán)境名稱也是不錯的選擇，例如：

devenv

devenv1

devenv2

preprod

pre-prod

test

testing

staging

stage

dev

development

deploy

slave

master

review

prod

uat

prep

Version2

該詞表取自DNSCewl 中的示例集。

預(yù)防措施

可以通過定義的生命周期支持 API 版本。例如，當(dāng)你發(fā)布 API 的V2 版本時，你可能會通知你的用戶V1版本將達(dá)到生命周期終止 (EoL) 并在未來的特定日期被棄用。預(yù)生產(chǎn)/測試版只有在經(jīng)過徹底的安全問題測試后才能公開訪問。

限速

大多數(shù)情況下，API 對用戶可以請求它們的次數(shù)沒有任何保護(hù)，這被稱為“缺乏速率限制”，當(dāng)攻擊者可以調(diào)用 API 數(shù)千次以導(dǎo)致一些意外行為時，就會發(fā)生這種情況。服務(wù)器將嘗試滿足這些請求中的每一個，這可能會：

通過使用請求重載服務(wù)器來對服務(wù)器進(jìn)行 DOS 處理
允許攻擊者快速泄露敏感的用戶信息，例如：用戶 ID、用戶名、電子郵件等。
通過強制登錄 API 繞過身份驗證
通過強制向受害者發(fā)送電子郵件/短信的功能來淹沒受害者的收件箱

讓我們看一個攻擊場景，其中對檢查憑據(jù)的 API 端點沒有速率限制：

GET/api/v1/user/1234/login/?password=mypassword

通常，你不會看到這樣在 GET 請求中發(fā)送的密碼，但出于演示說明的目的，假設(shè)你看到了。為了在上面的端點中暴力破解密碼，攻擊者可以使用BurpSuite 的 Intruder工具。這個工具允許我們自定義不同類型的蠻力攻擊，但在這個例子中，我們將提供一個簡單的密碼列表。

在幾秒鐘內(nèi)，Intruder 將發(fā)出數(shù)百個 API 請求，對每個請求嘗試不同的密碼。

GET /api/v1/user/1234/login/?password=notmypassword1
GET /api/v1/user/1234/login/?password=notmypassword2
GET /api/v1/user/1234/login/?password=notmypassword3
.
.
GET /api/v1/user/1234/login/?password=correctpassword!

由于沒有速率限制，服務(wù)器會響應(yīng)所有請求，攻擊者可以繼續(xù)使用不同的密碼進(jìn)行暴力破解，直到找到正確的密碼。

為了防止速率限制錯誤，應(yīng)用程序應(yīng)該對用戶在特定時間范圍內(nèi)請求 API 的頻率實施限制。設(shè)置的確切限制將取決于該 API 或端點的用例。

預(yù)防措施

速率限制可以通過許多不同的方式實現(xiàn)。每個帳戶、每個 IP 地址、每個端點、整個 API 等。一些反向代理也可用于實現(xiàn)應(yīng)用程序范圍的節(jié)流，而無需額外開發(fā)。

具體你使用怎樣的實現(xiàn)將取決于特定應(yīng)用程序的要求。

競爭條件

競爭條件是在同一毫秒內(nèi)向 API 發(fā)送兩個或多個請求。當(dāng) API 沒有處理這種競爭情況的機制時，可能會導(dǎo)致 API 以意外的方式處理請求。在易受攻擊的電子商務(wù)應(yīng)用程序上兌換折扣或促銷碼時，可能會出現(xiàn)競爭條件的潛在攻擊場景。

POST /api/v1/discount
Target: www.ecommerce.com
Connection: close
{
"code","first10",
"amount":"10"
}

BurpSuite 有一個名為Turbo Intruder的擴展，它允許用戶使用內(nèi)置race.py腳本測試競爭條件。在 Turbo Intruder 中配置攻擊后，攻擊者可以向 API 發(fā)送多個并發(fā)請求以兌換此促銷碼。

POST /api/v1/discount          200 OK
POST /api/v1/discount          200 OK
POST /api/v1/discount          200 OK
POST /api/v1/discount          404NotFound
POST /api/v1/discount          404NotFound

如果 API 在收到第一個并發(fā)請求后沒有立即使促銷碼失效，則折扣金額可能會增加一倍、三倍等。

這種攻擊被稱為“競爭條件”，因為它是攻擊者發(fā)送修改資源請求的速度與應(yīng)用程序更新該特定資源的速度之間的競爭。

預(yù)防措施

不幸的是，緩解競爭條件問題通常意味著犧牲性能。緩解競爭條件的方法包括利用鎖和其他線程安全功能。大多數(shù)編程語言都內(nèi)置了線程安全功能，通常需要手動設(shè)置指定。

XXE攻擊

XXE 代表XML 外部實體，這個注入漏洞可以在任何使用 API 處理 XML 數(shù)據(jù)的地方進(jìn)行測試。SOAP API 也可能容易受到 XXE 注入的影響，因為它們基于 XML。

使用 XML 的 API 端點如下所示：

POST /soap/v2/user HTTP/1.1
Host: example.com
Content-Type: text/xml
]>



&username;

XML 文檔使用實體來表示單個數(shù)據(jù)對象，而 XML 文檔類型定義 (DTD) 用于定義要使用的實體、文檔的結(jié)構(gòu)等。

XXE 注入是指攻擊者注入指定 DTD 之外的自定義外部實體。一旦這些外部實體被 API 解析，攻擊者就可以訪問應(yīng)用程序的內(nèi)部文件，升級到 SSRF，將敏感數(shù)據(jù)泄漏到攻擊者控制的域或 DOS 服務(wù)器。

這是一個請求示例，其中攻擊者注入了一個名為 xxe 的外部自定義實體，該實體的目的是檢索內(nèi)部文件：

POST /soap/v2/user HTTP/1.1
Host: example.com
Content-Type: text/xml
[]>



&xxe;

如果 API 允許使用標(biāo)準(zhǔn) XML 解析器來處理數(shù)據(jù)，那么這個注入的外部實體將被應(yīng)用程序處理并將其內(nèi)容返回/etc/passwd給攻擊者。

預(yù)防措施

確保使用的 XML 解析器設(shè)置為不解析 XML 實體。

切換內(nèi)容類型

即使 API使用 JSON 作為數(shù)據(jù)格式進(jìn)行通信，底層服務(wù)器/框架仍可能接受其他數(shù)據(jù)格式，如 XML。因此，當(dāng)你看到帶有content-Typeof的 API 時application/json，你仍然可以嘗試修改Content-Type: text/xml來測試 XXE

例如，如果 API 使用 JSON：

POST /api/v1/user HTTP/1.1
Host: example.com
Content-Type: application/json

可以修改它以這種方式發(fā)送 XML 數(shù)據(jù)：

POST /soap/v2/user HTTP/1.1
Host: example.com
Content-Type: text/xml
aa []>

預(yù)防措施

這類錯誤僅存在于可以接受多種格式的應(yīng)用程序框架上，每種格式對應(yīng)一種數(shù)據(jù)傳輸對象。一般來說，框架通?？梢赃x擇將哪些可用格式列入白名單。需要重點指出的是，這在 2021 年非常罕見。

HTTP 方法

API 通常支持各種類型的 HTTP 方法，常見的有GET，POST，PATCH，DELETE和OPTIONS。如果一個GET請求在其中的應(yīng)用程序需要一個POST請求點發(fā)送，那么這可能會導(dǎo)致應(yīng)用程序以意想不到的響應(yīng)。

我們以CSRF為例。CSRF（跨站點請求偽造）是指攻擊者誘使受害者提交請求，從而導(dǎo)致受害者帳戶發(fā)生狀態(tài)更改操作。這些更改可以是更改受害者的個人詳細(xì)信息，在某些情況下甚至可以更改受害者的密碼，從而導(dǎo)致完全接管帳戶。更改受害者個人詳細(xì)信息的正常請求可能如下所示：

POST /api/v1/user
Target: www.example.com
Content-Type: application/json
{
  "name","victim",
  "email":"[email protected]",
  "location":"AU",
  "csrftoken":"76hhs683bki0"
}

觀察上述請求后，我們可能會得出結(jié)論，CSRF 攻擊是不可能的，因為該csrftoken值是在請求正文中發(fā)送的。但是，如果 API 不限制可用于此請求的 HTTP 方法，則攻擊者可能會通過使用 GET 方法發(fā)送此請求來繞過此保護(hù)。

GET /api/v1/[email protected]
m&location=FR
Target: www.example.com
Connection: close

此外，有時服務(wù)器根本不驗證 CSRF 令牌，或者如果請求中根本不存在 CSRF 令牌參數(shù)，則接受請求。

REST API 中的另一個常見漏洞是在端點上正確應(yīng)用了權(quán)限，但僅適用于一個 HTTP 動詞。例如，你可能無法 GET 其他人的記錄，但你可以使用 PATCH 動詞來編輯他們的記錄。

預(yù)防措施

在路由中手動指定 HTTP 動詞。禁用不必要地使用動詞，并確保指定的任何端點確實對所有動詞應(yīng)用了相同的控制。某些框架會自動執(zhí)行此操作，而其他框架則不會。

注入漏洞

服務(wù)器端注入缺陷類問題，如 SQL 注入、RCE、命令注入和SSRF，可以像在常規(guī) Web 應(yīng)用程序中一樣存在于 API 中。每當(dāng)任何注入的數(shù)據(jù)直接傳遞給后端的解釋器時，就會為攻擊者發(fā)送有針對性的查詢和命令以訪問內(nèi)部數(shù)據(jù)或執(zhí)行任意代碼留下空間。

例如，讓我們在以下 API 請求上測試 SSRF：

POST /api/v1/user
Target: www.example.com
Content-Type: application/json
{
  "name","victim",
  "email":"[email protected]",
  "profile_pic_url":"https://www.example.com/me.jpg"
}

攻擊者可以通過profile_pic_url發(fā)送如下請求在現(xiàn)場嘗試 SSRF ：

POST /api/v1/user
Target: www.example.com
Content-Type: application/json
{
  "name","victim",
  "email":"[email protected]",
  "profile_pic_url":"http://localhost/admin"
}

如果后端解釋器沒有profile_pic_url正確驗證該值，那么這可能導(dǎo)致攻擊者利用 SSRF 并成功訪問內(nèi)部數(shù)據(jù)。

同樣，如果此請求中的數(shù)據(jù)未正確驗證，攻擊者也可以嘗試 SQL 注入：

POST /api/v1/orders
Target: www.example.com
Content-Type: application/json
{
  "offset":0,
  "limit":10,
  "scope":"orders_all",
}

通過查看請求正文，我們可能會提示這些參數(shù)的值正在發(fā)送到后端數(shù)據(jù)庫解釋器。因此，我們可以通過將這些值修改為目標(biāo)查詢來嘗試 SQL 注入：

POST /api/v1/orders
Target: www.example.com
Content-Type: application/json
{
  "offset":0,
  "limit":10,
  "scope":"SELECT sleep(10)",
}

再一次，如果解釋器沒有正確驗證這些值，那么這可能會導(dǎo)致 SQL 注入，攻擊者可能會導(dǎo)致數(shù)據(jù)庫中的時間延遲，甚至泄露敏感數(shù)據(jù)。

預(yù)防措施

緩解 API 中的注入漏洞本質(zhì)上與緩解 Web 應(yīng)用程序中的注入漏洞相同。

SAST/DAST 掃描器可以幫助解決這個問題，但安全開發(fā)實踐是最好的緩解措施。預(yù)編譯參數(shù)化 SQL 查詢，盡可能使用 ORM 和信譽良好的庫，不要相信用戶輸入！

本文名稱：現(xiàn)代API滲透技術(shù)
分享路徑：http://www.fisionsoft.com.cn/article/ccsjsso.html

新聞中心

API測試配置

API漏洞類型

API 暴露

錯誤配置的緩存

暴露的令牌

JWT的弱點

授權(quán)問題/IDOR

未記錄的端點

不同API版本問題

限速

競爭條件

XXE攻擊

切換內(nèi)容類型

HTTP 方法

注入漏洞

其他資訊