常見API接口漏洞
了解接口常見漏洞，将幫助你在測試接口擷取更多的思路。
資訊披露
資訊可能會在 API 響應或公共來源（如代碼存儲庫、搜尋結果、新聞、社交媒體、目标網站和公共 API 目錄）中披露。
敏感資料可以包含攻擊者可以利用的任何資訊。
例如，使用WordPress API的網站可能會在不知不覺中與導航到API路徑的任何人共享使用者資訊。/wp-json/wp/v2/users
GET https://www.sitename.org/wp-json/wp/v2/users
[{"id":1,"name":"Administrator", "slug":"admin"}],
{"id":2,"name":"Vincent Valentine", "slug":"Vincent"}] 然後，可以使用這些 slug 嘗試以公開使用者的身份登入，并進行暴力破解、憑據填充或密碼噴射攻擊。
錯誤消息可幫助 API 使用者排查其與 API 的互動問題，并允許 API 提供者了解其應用程式的問題。但是，它也可以揭示有關資源、使用者和 API 底層體系結構（例如 Web 伺服器或資料庫的版本）的敏感資訊。
通常，您可以通過與 API 終端節點互動并分析響應來收集最多資訊。API 響應可以顯示标頭、參數和詳細錯誤中的資訊。其他良好的資訊來源是在偵察期間收集的 API 文檔和資源。
斷開的對象級别授權
當 API 提供者允許 API 使用者通路他們無權通路的資源時，就會發生 BOLA 漏洞。
例如，假設我們被授權僅通路使用者Cloud Strife。我們會向 https://bestgame.com/api/v3/users?id=5501 發送初始 GET 請求
{
"id": "5501",
"first_name": "Cloud",
"last_name": "Strife",
"link": "https://www.bestgame.com/user/strife.buster.97",
"name": "Cloud Strife",
"dob": "1997-01-31",
"username": "strife.buster.97"
} 在這種情況下，我們可能會使用另一個接近 Cloud ID 5501 的辨別号來檢查這些問題。假設我們能夠擷取有關其他使用者的資訊。
通常，您可以通過了解 API 的資源結構并嘗試通路不應通路的資源來測試 BOLA。通過檢測 API 路徑和參數中的模式，您應該能夠預測其他潛在資源。
BOLA 可能是一個低懸的 API 漏洞，您可以使用模式識别輕松發現它，然後通過幾個請求來刺激它。其他時候，由于對象 ID 的複雜性以及用于擷取其他使用者資源的請求，發現起來可能非常複雜。
使用者身份驗證中斷
使用者身份驗證中斷是指 API 身份驗證過程中的任何弱點。當 API 提供程式未實作身份驗證保護機制或未正确實作機制時，通常會發生這些漏洞。
正如我們從第2章讨論的REST API的六個限制中知道的那樣，RESTful API應該是無狀态的。為了成為無狀态的，提供者不需要記住從一個請求到另一個請求的使用者。要使此限制起作用，API 通常需要使用者經曆注冊過程才能獲得唯一的令牌。然後，使用者可以在請求中包含令牌，以證明他們有權發出此類請求
例如，為了确定代币生成過程是否較弱，我們可以收集代币樣本并分析它們的相似性。如果令牌生成過程不依賴于進階别 随機性或熵，我們有可能建立自己的令牌或劫持别人的令牌。
令牌處理可以是令牌的存儲、通過網絡傳輸令牌的方法、寫死令牌的存在等。我們也許能夠在 JavaScript 源檔案中檢測寫死令牌，或者在分析 Web 應用程式時捕獲它們。捕獲令牌後，我們可以使用它來通路以前隐藏的終結點或繞過檢測。如果 API 提供者将身份歸因于令牌，我們将通過劫持被盜令牌來承擔身份。
其他可能具有自己的一組漏洞的身份驗證過程包括注冊系統的各個方面，例如密碼重置和多重身份驗證功能。例如，假設密碼重置功能要求您提供電子郵件位址和六位數代碼來重置密碼。好吧，如果API允許您發出任意數量的請求，則隻需發出一百萬個請求即可猜測代碼并重置任何使用者的密碼。一個四位數的代碼隻需要 10，000 個請求。
由于 REST API 的無狀态性質，公開的 API 密鑰等效于發現使用者名和密碼。通過使用公開的 API 密鑰，你将代入與該密鑰關聯的角色。
過度的資料洩露
過度資料洩露是指 API 端點響應的資訊多于滿足請求所需的資訊。
當存在此漏洞時，可能相當于向某人詢問其姓名，并讓他們使用其姓名，出生日期，電子郵件位址，電話号碼以及他們認識的每個人的身份進行響應。
假設我請求了自己的帳戶資訊，并提出了以下請求：
GET /api/v3/account?name=Cloud+Strife
# respone
{
"id": "5501",
"first_name": "Cloud",
"last_name": "Strife",
"privilege": "user",
"representative": [
"name": "Don Corneo",
"id": "2203"
"email": "[email protected]",
"privilege": "super-admin"
"admin": true
"two_factor_auth": false,
} 要檢測過多的資料洩露，您需要做的就是測試目标 API 端點并檢視響應中發送的資訊
缺乏資源和速率限制
速率限制在 API 的貨币化和可用性中起着重要作用。如果不限制使用者可以發出的請求數量，API 提供商的基礎設施可能會被請求淹沒。沒有足夠資源的請求過多将導緻提供商的系統崩潰并變得不可用 - 例如，拒絕服務（DoS）狀态RapidAPI允許每月免費500個請求，但付費客戶每月允許1，000個請求。
一旦您被限制提出其他請求，就該嘗試檢視如何實施速率限制了。您可以通過添加或删除參數、使用其他用戶端或更改 IP 位址來繞過它嗎？
中斷的功能級别授權
中斷的功能級别授權 （BFLA） 是一個角色或組的使用者能夠通路另一個角色或組的 API 功能的漏洞。
BFLA 與 BOLA 類似，不同之處在于不是涉及通路資源的授權問題，而是執行操作的授權問題。
當 API 中存在 BOLA 漏洞時，您可能能夠通路該資訊 其他帳戶，例如付款曆史記錄、使用者名、電子郵件位址和帳号 如果存在 BFLA 漏洞，您可能能夠轉賬并實際更新帳戶資訊。相反，該功能可以基于 HTTP 請求方法，例如 、、 和 。如果提供程式不限制使用者可以使用的 HTTP 方法，則隻需使用其他方法進行 a 即可訓示 BFLA 漏洞。
GET
POST
PUT
DELETE
unauthorized request 發現 BFLA 的最簡單方法是查找管理 API 文檔，并以測試管理功能和能力的非特權使用者身份發送請求。如果特權操作的 API 文檔不可用，則需要在測試用于執行特權操作的終結點之前發現或對其進行反向工程。
品質配置設定
當 API 使用者在其請求中包含比應用程式預期更多的參數，并且應用程式将這些參數添加到代碼變量或内部對象時，就會發生批量配置設定。“我覺得這看起來像參數污染”
例如，應用程式可能具有帳戶更新功能，使用者應僅使用該功能來更新其使用者名、密碼和位址。如果使用者可以在與其帳戶相關的請求中包含其他參數（如帳戶權限級别或敏感資訊（如帳戶餘額），并且應用程式接受這些參數而不根據允許操作的白名單檢查它們，則使用者可以利用此弱點來更改這些值。
// Imagine an API is called to create an account with parameters for
"User" and "Password":
{
"User": "scuttleph1sh",
"Password": "GreatPassword123"
}
//While reading the API documentation regarding the account creation
//process, suppose you discover that there is an additional key, "isAdmin", that
//consumers can use to become administrators. You could use a tool like
//Postman or Burp Suite to add the attribute to a request and set the value
//to true:
{
"User": "scuttleph1sh",
"Password": "GreatPassword123",
"isAdmin": true
} 您可以通過在 API 文檔中查找感興趣的參數，然後将這些參數添加到請求中來發現批量配置設定漏洞。查找使用者帳戶屬性、關鍵功能和管理操作中涉及的參數。攔截 API 請求和響應也可以揭示值得測試的參數。此外，您可以在 API 請求中猜測參數或模糊參數。
安全配置錯誤
安全配置錯誤包括開發人員在 API 的支援安全配置中可能犯的所有錯誤。例如，如果 API 的支援安全配置揭示了未修補的漏洞，則攻擊者有可能利用已釋出的漏洞輕松“pwn”API 及其系統。
安全配置錯誤實際上是一組弱點，包括配置錯誤的标頭、配置錯誤的傳輸加密、使用預設帳戶、接受不必要的 HTTP 方法、缺乏輸入清理和詳細的錯誤消息。
缺乏輸入清理可能允許攻擊者将惡意負載上傳到伺服器。
例如，如果使用上傳端點将上傳的檔案傳遞到 Web 目錄，則它可能允許上傳腳本。導航到檔案所在的 URL 可以啟動腳本， 導緻對 Web 伺服器的直接外殼通路。
API 提供程式使用标頭為使用者提供處理響應和安全要求的說明。配置錯誤的标頭可能導緻敏感資訊洩露、降級攻擊和跨站點腳本攻擊。
例如，采用以下響應：
HTTP/ 200 OK
--snip--
X-Powered-By: VulnService 1.11 // reveal backend tech => search exploits
X-XSS-Protection: 0 // could be changed to 1
X-Response-Time: 566.43
//If the X-Response-Time header has a consistent response time for nonexistent records, for example, but increases
// its response time for certain other records, this could be an indication that those records exist.
HTTP/UserA 404 Not Found
--snip--
X-Response-Time: 25.5
HTTP/UserB 404 Not Found
--snip--
X-Response-Time: 25.5
HTTP/UserC 404 Not Found
--snip--
X-Response-Time: 510.00 在這種情況下，UserC 的響應時間值是其他資源的響應時間的 20 倍。由于樣本量如此之小，很難明确地斷定 UserC 存在。
例如，您知道像這樣的虛假帳戶的平均X響應時間為ms。您還知道，您現有的帳戶 /user/account/1021 收到的 X 響應時間為 。如果您随後發送了請求，強制所有帳号從 到 ，您可以檢視結果并檢視哪些帳号導緻響應時間大幅增加。/user/account/thisdefinitelydoesnotexist87625.5510.0010002000
任何向使用者提供敏感資訊的 API 都應使用傳輸層安全性 （TLS） 來加密資料。即使 API 僅在内部、私有或合作夥伴級别提供，使用 TLS（加密 HTTPS 流量的協定）也是確定 API 請求和響應在通過網絡傳遞時受到保護的最基本方法之一。配置錯誤或缺少傳輸加密可能會導緻 API 使用者以明文形式跨網絡傳遞敏感的 API 資訊。然後攻擊者可以使用MITM攻擊來利用它。
當服務使用預設帳戶和憑據并且預設值已知時，攻擊者可以使用這些憑據代入該帳戶的角色。這可能允許他們通路敏感資訊或管理功能，可能導緻 支援系統。
最後，如果 API 提供程式允許不必要的 HTTP 方法，則應用程式無法正确處理這些方法或導緻敏感資訊洩露的風險會增加。
您可以使用 Web 應用程式漏洞掃描程式（如 Nessus、Qualys、OWASP ZAP 和 Nikto）檢測其中的幾個安全錯誤配置。這些掃描程式将自動檢查 Web 伺服器版本資訊、标頭、cookie、傳輸加密配置和參數，以檢視是否缺少預期的安全措施。如果您知道要查找的内容，也可以通過檢查标頭、SSL 證書、cookie 和參數來手動檢查這些安全配置錯誤。
注入
當請求傳遞到 API 的支援基礎結構并且 API 提供程式不篩選輸入以删除不需要的字元（此過程稱為輸入清理）時，存在注入缺陷。詳細的錯誤消息、HTTP 響應代碼和意外的 API 行為都可能是您可能發現了注入缺陷的線索。
API 可能會将該有效負載直接傳遞到後端 SQL 資料庫，其中 OR 1=0 語句将失敗（因為 1 不等于 0），進而導緻一些 SQL 錯誤：
POST /api/v1/register HTTP 1.1
Host: example.com
--snip--
{
"Fname": "hAPI",
"Lname": "Hacker",
"Address": "' OR 1=0--",
} 注入漏洞通常輔以其他漏洞，例如輸入清理不良。在以下示例中，您可以看到一種代碼注入攻擊，該攻擊使用 API GET 請求來利用弱查詢參數。在這種情況下，弱查詢參數将請求的查詢部分中的任何資料直接傳遞到底層系統，而不先對其進行清理：以下響應正文顯示 API 端點已縱為顯示主機的 /etc/passwd 檔案，進而顯示系統上的使用者：
GET http://10.10.78.181:5000/api/v1/resources/books？show=/etc/passwd
root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/dev:/usr/sbin/nologin
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/usr/sbin/nologin
man:x:6:12:man:/var/cache/man:/usr/sbin/nologin
lp:x:7:7:lp:/var/spool/lpd:/usr/sbin/nologin
mail:x:8:8:mail:/var/mail:/usr/sbin/nologin
news:x:9:9:news:/var/spool/news:/usr/sbin/nologin 查找注入缺陷需要認真測試 API 端點，注意 API 的響應方式，然後精心制作嘗試操縱後端系統的請求。與目錄周遊攻擊一樣，注入攻擊已經存在了幾十年，是以有許多标準的安全控制措施來保護 API 提供程式免受這些攻擊。
資産管理不當
當組織公開 API 時，會發生不正确的資産管理 已停用或仍在開發中。仍在開發的 API 通常不如生産 API 對應項安全。
資産管理不當會導緻其他漏洞，例如資料過度暴露、資訊洩露、批量配置設定、速率限制不當和 API 注入等。
您可以通過密切關注倉庫中過時的 API 文檔、更改日志和版本曆史記錄來發現不當的資産管理。
組織通常在其終結點名稱中包含版本控制資訊，以區分較舊版本和較新版本，例如 等。仍在開發中的 API 通常使用諸如 .如果您知道 API 現在正在使用 apiv3.org/admin 但 API 文檔的一部分提到了 apiv1.org/admin，則可以嘗試測試不同的端點以檢視 apiv1 或 apiv2 是否仍處于活動狀态。此外，組織的更新日志 可能會披露 v1 更新或停用的原因。如果您有權通路 v1，則可以測試這些弱點/v1/, /v2/, /v3//alpha/, /beta/, /test/, /uat/, and /demo/
在使用文檔之外，您還可以通過使用猜測、模糊測試或暴力請求來發現不正确的資産管理漏洞。觀察 API 文檔或路徑命名方案中的模式，然後根據您的假設送出請求。
業務邏輯漏洞
業務邏輯漏洞（也稱為業務邏輯缺陷或 BLF）是攻擊者可以惡意使用的應用程式的預期功能。
例如，如果 API 具有不驗證編碼有效負載的上傳功能，則隻要任何檔案已編碼，使用者就可以上傳該檔案。這将允許最終使用者上傳和執行任意代碼，包括惡意負載。在這些情況下，組織基本上依賴于 信任作為一種安全控制，期望消費者采取仁慈的行為。不幸的是，即使是善良的 API 使用者也會犯錯誤，進而導緻應用程式受損。
您可以在 API 文檔中搜尋業務邏輯漏洞的迹象。像下面的陳述應該照亮你頭頂的燈泡：
“僅使用功能 X 來執行功能 Y。” “不要對端點 Y 執行 X。” “隻有管理者才能執行請求 X。”
當您攻擊他們的 API 時，請確定不服從此類請求以測試是否存在安全控制。
例如，請考慮使用者通常用來對其帳戶進行身份驗證的 Web 應用程式身份驗證門戶。假設 Web 應用程式發出了以下 API 請求：
POST /api/v1/login HTTP 1.1
Host: example.com
--snip--
UserId=hapihacker&password=arealpassword!&MFA=true 我們有可能通過簡單地将參數更改為 來繞過多因素身份驗證。MFAfalse
測試業務邏輯缺陷可能具有挑戰性，因為每個業務都是獨一無二的。自動掃描程式将很難檢測到這些問題，因為這些缺陷是API預期用途的一部分。您必須了解業務和 API 的運作方式，然後考慮如何利用這些功能來發揮自己的優勢。以對抗的心态研究應用程式的業務邏輯，并嘗試打破任何假設 被制造
總結
熟悉這些漏洞非常重要，這樣您就可以輕松識别它們，在參與滲透測試期間利用它們，并将其報告給組織，以防止犯罪分子将您的客戶拖入頭條新聞。現在您已經熟悉了 Web 應用程式、API 及其弱點。