2024年您產品必備的10大AI API推薦
你可能也喜歡這些API文章!
發現 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 使用者在其請求中包含比應用程序預期更多的參數，并且應用程序將這些參數添加到代碼變量或內部對象時，就會發生批量分配。“我覺得這看起來像參數污染”
例如，應用程序可能具有帳戶更新功能，用戶應僅使用該功能來更新其用戶名、密碼和地址。如果使用者可以在與其帳戶相關的請求中包含其他參數（如帳戶權限級別或敏感信息（如帳戶余額），并且應用程序接受這些參數而不根據允許操作的白名單檢查它們，則使用者可以利用此弱點來更改這些值。
// 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 exploitsX-XSS-Protection: 0 // could be changed to 1X-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.5HTTP/UserB 404 Not Found--snip--X-Response-Time: 25.5HTTP/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.1Host: 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/bashdaemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologinbin:x:2:2:bin:/dev:/usr/sbin/nologinsync:x:4:65534:sync:/bin:/bin/syncgames:x:5:60:games:/usr/games:/usr/sbin/nologinman:x:6:12:man:/var/cache/man:/usr/sbin/nologinlp:x:7:7:lp:/var/spool/lpd:/usr/sbin/nologinmail:x:8:8:mail:/var/mail:/usr/sbin/nologinnews: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.1Host: example.com--snip--UserId=hapihacker&password=arealpassword!&MFA=true我們有可能通過簡單地將參數更改為 來繞過多因素身份驗證。MFAfalse
測試業務邏輯缺陷可能具有挑戰性，因為每個業務都是獨一無二的。自動掃描程序將很難檢測到這些問題，因為這些缺陷是API預期用途的一部分。您必須了解業務和 API 的運作方式，然后考慮如何利用這些功能來發揮自己的優勢。以對抗的心態研究應用程序的業務邏輯，并嘗試打破任何假設 。
熟悉這些漏洞非常重要，這樣您就可以輕松識別它們，在參與滲透測試期間利用它們，并將其報告給組織，以防止犯罪分子將您的客戶拖入頭條新聞。現在您已經熟悉了 Web 應用程序、API 及其弱點。
