?

常見(jiàn)API接口漏洞

?

了解接口常見(jiàn)漏洞，將幫助你在測(cè)試接口獲取更多的思路。

?

信息披露

?

信息可能會(huì)在 API 響應(yīng)或公共來(lái)源（如代碼存儲(chǔ)庫(kù)、搜索結(jié)果、新聞、社交媒體、目標(biāo)網(wǎng)站和公共 API 目錄）中披露。

敏感數(shù)據(jù)可以包含攻擊者可以利用的任何信息。

例如，使用WordPress API的網(wǎng)站可能會(huì)在不知不覺(jué)中與導(dǎo)航到API路徑的任何人共享用戶(hù)信息。/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 嘗試以公開(kāi)用戶(hù)的身份登錄，并進(jìn)行暴力破解、憑據(jù)填充或密碼噴射攻擊。

錯(cuò)誤消息可幫助 API 使用者排查其與 API 的交互問(wèn)題，并允許 API 提供者了解其應(yīng)用程序的問(wèn)題。但是，它也可以揭示有關(guān)資源、用戶(hù)和 API 底層體系結(jié)構(gòu)（例如 Web 服務(wù)器或數(shù)據(jù)庫(kù)的版本）的敏感信息。

通常，您可以通過(guò)與 API 終端節(jié)點(diǎn)交互并分析響應(yīng)來(lái)收集最多信息。API 響應(yīng)可以顯示標(biāo)頭、參數(shù)和詳細(xì)錯(cuò)誤中的信息。其他良好的信息來(lái)源是在偵察期間收集的 API 文檔和資源。

?

斷開(kāi)的對(duì)象級(jí)別授權(quán)

?

當(dāng) API 提供者允許 API 使用者訪問(wèn)他們無(wú)權(quán)訪問(wèn)的資源時(shí)，就會(huì)發(fā)生 BOLA 漏洞。

例如，假設(shè)我們被授權(quán)僅訪問(wèn)用戶(hù)Cloud Strife。我們會(huì)向 https://bestgame.com/api/v3/users?id=5501 發(fā)送初始 GET 請(qǐng)求

{
?"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"
}

在這種情況下，我們可能會(huì)使用另一個(gè)接近 Cloud ID 5501 的標(biāo)識(shí)號(hào)來(lái)檢查這些問(wèn)題。假設(shè)我們能夠獲取有關(guān)其他用戶(hù)的信息。

通常，您可以通過(guò)了解 API 的資源結(jié)構(gòu)并嘗試訪問(wèn)不應(yīng)訪問(wèn)的資源來(lái)測(cè)試 BOLA。通過(guò)檢測(cè) API 路徑和參數(shù)中的模式，您應(yīng)該能夠預(yù)測(cè)其他潛在資源。

BOLA 可能是一個(gè)低懸的 API 漏洞，您可以使用模式識(shí)別輕松發(fā)現(xiàn)它，然后通過(guò)幾個(gè)請(qǐng)求來(lái)刺激它。其他時(shí)候，由于對(duì)象 ID 的復(fù)雜性以及用于獲取其他用戶(hù)資源的請(qǐng)求，發(fā)現(xiàn)起來(lái)可能非常復(fù)雜。

?

用戶(hù)身份驗(yàn)證中斷

?

用戶(hù)身份驗(yàn)證中斷是指 API 身份驗(yàn)證過(guò)程中的任何弱點(diǎn)。當(dāng) API 提供程序未實(shí)現(xiàn)身份驗(yàn)證保護(hù)機(jī)制或未正確實(shí)現(xiàn)機(jī)制時(shí)，通常會(huì)發(fā)生這些漏洞。

正如我們從第2章討論的REST API的六個(gè)約束中知道的那樣，RESTful API應(yīng)該是無(wú)狀態(tài)的。為了成為無(wú)狀態(tài)的，提供者不需要記住從一個(gè)請(qǐng)求到另一個(gè)請(qǐng)求的使用者。要使此約束起作用，API 通常需要用戶(hù)經(jīng)歷注冊(cè)過(guò)程才能獲得唯一的令牌。然后，用戶(hù)可以在請(qǐng)求中包含令牌，以證明他們有權(quán)發(fā)出此類(lèi)請(qǐng)求

例如，為了確定代幣生成過(guò)程是否較弱，我們可以收集代幣樣本并分析它們的相似性。如果令牌生成過(guò)程不依賴(lài)于高級(jí)別 隨機(jī)性或熵，我們有可能創(chuàng)建自己的令牌或劫持別人的令牌。

令牌處理可以是令牌的存儲(chǔ)、通過(guò)網(wǎng)絡(luò)傳輸令牌的方法、硬編碼令牌的存在等。我們也許能夠在 JavaScript 源文件中檢測(cè)硬編碼令牌，或者在分析 Web 應(yīng)用程序時(shí)捕獲它們。捕獲令牌后，我們可以使用它來(lái)訪問(wèn)以前隱藏的終結(jié)點(diǎn)或繞過(guò)檢測(cè)。如果 API 提供者將身份歸因于令牌，我們將通過(guò)劫持被盜令牌來(lái)承擔(dān)身份。

其他可能具有自己的一組漏洞的身份驗(yàn)證過(guò)程包括注冊(cè)系統(tǒng)的各個(gè)方面，例如密碼重置和多重身份驗(yàn)證功能。例如，假設(shè)密碼重置功能要求您提供電子郵件地址和六位數(shù)代碼來(lái)重置密碼。好吧，如果API允許您發(fā)出任意數(shù)量的請(qǐng)求，則只需發(fā)出一百萬(wàn)個(gè)請(qǐng)求即可猜測(cè)代碼并重置任何用戶(hù)的密碼。一個(gè)四位數(shù)的代碼只需要 10，000 個(gè)請(qǐng)求。

由于 REST API 的無(wú)狀態(tài)性質(zhì)，公開(kāi)的 API 密鑰等效于發(fā)現(xiàn)用戶(hù)名和密碼。通過(guò)使用公開(kāi)的 API 密鑰，你將代入與該密鑰關(guān)聯(lián)的角色。

?

過(guò)度的數(shù)據(jù)泄露

過(guò)度數(shù)據(jù)泄露是指 API 端點(diǎn)響應(yīng)的信息多于滿(mǎn)足請(qǐng)求所需的信息。

當(dāng)存在此漏洞時(shí)，可能相當(dāng)于向某人詢(xún)問(wèn)其姓名，并讓他們使用其姓名，出生日期，電子郵件地址，電話(huà)號(hào)碼以及他們認(rèn)識(shí)的每個(gè)人的身份進(jìn)行響應(yīng)。

假設(shè)我請(qǐng)求了自己的帳戶(hù)信息，并提出了以下請(qǐng)求：

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":?"dcorn@gmail.com",
?"privilege":?"super-admin"
?"admin":?true
?"two_factor_auth":?false,
?}

要檢測(cè)過(guò)多的數(shù)據(jù)泄露，您需要做的就是測(cè)試目標(biāo) API 端點(diǎn)并查看響應(yīng)中發(fā)送的信息

?

缺乏資源和速率限制

?

速率限制在 API 的貨幣化和可用性中起著重要作用。如果不限制使用者可以發(fā)出的請(qǐng)求數(shù)量，API 提供商的基礎(chǔ)設(shè)施可能會(huì)被請(qǐng)求淹沒(méi)。沒(méi)有足夠資源的請(qǐng)求過(guò)多將導(dǎo)致提供商的系統(tǒng)崩潰并變得不可用 - 例如，拒絕服務(wù)（DoS）狀態(tài)RapidAPI允許每月免費(fèi)500個(gè)請(qǐng)求，但付費(fèi)客戶(hù)每月允許1，000個(gè)請(qǐng)求。

一旦您被限制提出其他請(qǐng)求，就該嘗試查看如何實(shí)施速率限制了。您可以通過(guò)添加或刪除參數(shù)、使用其他客戶(hù)端或更改 IP 地址來(lái)繞過(guò)它嗎？

?

中斷的功能級(jí)別授權(quán)

?

中斷的功能級(jí)別授權(quán) （BFLA） 是一個(gè)角色或組的用戶(hù)能夠訪問(wèn)另一個(gè)角色或組的 API 功能的漏洞。

BFLA 與 BOLA 類(lèi)似，不同之處在于不是涉及訪問(wèn)資源的授權(quán)問(wèn)題，而是執(zhí)行操作的授權(quán)問(wèn)題。

當(dāng) API 中存在 BOLA 漏洞時(shí)，您可能能夠訪問(wèn)該信息 其他帳戶(hù)，例如付款歷史記錄、用戶(hù)名、電子郵件地址和帳號(hào) 如果存在 BFLA 漏洞，您可能能夠轉(zhuǎn)賬并實(shí)際更新帳戶(hù)信息。相反，該功能可以基于 HTTP 請(qǐng)求方法，例如 、、 和 。如果提供程序不限制使用者可以使用的 HTTP 方法，則只需使用其他方法進(jìn)行 a 即可指示 BFLA 漏洞。

GET
POST
PUT
DELETE
unauthorized request

發(fā)現(xiàn) BFLA 的最簡(jiǎn)單方法是查找管理 API 文檔，并以測(cè)試管理功能和能力的非特權(quán)用戶(hù)身份發(fā)送請(qǐng)求。如果特權(quán)操作的 API 文檔不可用，則需要在測(cè)試用于執(zhí)行特權(quán)操作的終結(jié)點(diǎn)之前發(fā)現(xiàn)或?qū)ζ溥M(jìn)行反向工程。

?

質(zhì)量分配

?

當(dāng) API 使用者在其請(qǐng)求中包含比應(yīng)用程序預(yù)期更多的參數(shù)，并且應(yīng)用程序?qū)⑦@些參數(shù)添加到代碼變量或內(nèi)部對(duì)象時(shí)，就會(huì)發(fā)生批量分配。“我覺(jué)得這看起來(lái)像參數(shù)污染”

例如，應(yīng)用程序可能具有帳戶(hù)更新功能，用戶(hù)應(yīng)僅使用該功能來(lái)更新其用戶(hù)名、密碼和地址。如果使用者可以在與其帳戶(hù)相關(guān)的請(qǐng)求中包含其他參數(shù)（如帳戶(hù)權(quán)限級(jí)別或敏感信息（如帳戶(hù)余額），并且應(yīng)用程序接受這些參數(shù)而不根據(jù)允許操作的白名單檢查它們，則使用者可以利用此弱點(diǎn)來(lái)更改這些值。

//?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
}

您可以通過(guò)在 API 文檔中查找感興趣的參數(shù)，然后將這些參數(shù)添加到請(qǐng)求中來(lái)發(fā)現(xiàn)批量分配漏洞。查找用戶(hù)帳戶(hù)屬性、關(guān)鍵功能和管理操作中涉及的參數(shù)。攔截 API 請(qǐng)求和響應(yīng)也可以揭示值得測(cè)試的參數(shù)。此外，您可以在 API 請(qǐng)求中猜測(cè)參數(shù)或模糊參數(shù)。

?

安全配置錯(cuò)誤

?

安全配置錯(cuò)誤包括開(kāi)發(fā)人員在 API 的支持安全配置中可能犯的所有錯(cuò)誤。例如，如果 API 的支持安全配置揭示了未修補(bǔ)的漏洞，則攻擊者有可能利用已發(fā)布的漏洞輕松“pwn”API 及其系統(tǒng)。

安全配置錯(cuò)誤實(shí)際上是一組弱點(diǎn)，包括配置錯(cuò)誤的標(biāo)頭、配置錯(cuò)誤的傳輸加密、使用默認(rèn)帳戶(hù)、接受不必要的 HTTP 方法、缺乏輸入清理和詳細(xì)的錯(cuò)誤消息。

缺乏輸入清理可能允許攻擊者將惡意負(fù)載上傳到服務(wù)器。

例如，如果使用上傳端點(diǎn)將上傳的文件傳遞到 Web 目錄，則它可能允許上傳腳本。導(dǎo)航到文件所在的 URL 可以啟動(dòng)腳本， 導(dǎo)致對(duì) Web 服務(wù)器的直接外殼訪問(wèn)。

API 提供程序使用標(biāo)頭為使用者提供處理響應(yīng)和安全要求的說(shuō)明。配置錯(cuò)誤的標(biāo)頭可能導(dǎo)致敏感信息泄露、降級(jí)攻擊和跨站點(diǎn)腳本攻擊。

例如，采用以下響應(yīng)：

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 的響應(yīng)時(shí)間值是其他資源的響應(yīng)時(shí)間的 20 倍。由于樣本量如此之小，很難明確地?cái)喽?UserC 存在。

例如，您知道像這樣的虛假帳戶(hù)的平均X響應(yīng)時(shí)間為ms。您還知道，您現(xiàn)有的帳戶(hù) /user/account/1021 收到的 X 響應(yīng)時(shí)間為 。如果您隨后發(fā)送了請(qǐng)求，強(qiáng)制所有帳號(hào)從 到 ，您可以查看結(jié)果并查看哪些帳號(hào)導(dǎo)致響應(yīng)時(shí)間大幅增加。/user/account/thisdefinitelydoesnotexist87625.5510.0010002000

任何向使用者提供敏感信息的 API 都應(yīng)使用傳輸層安全性 （TLS） 來(lái)加密數(shù)據(jù)。即使 API 僅在內(nèi)部、私有或合作伙伴級(jí)別提供，使用 TLS（加密 HTTPS 流量的協(xié)議）也是確保 API 請(qǐng)求和響應(yīng)在通過(guò)網(wǎng)絡(luò)傳遞時(shí)受到保護(hù)的最基本方法之一。配置錯(cuò)誤或缺少傳輸加密可能會(huì)導(dǎo)致 API 用戶(hù)以明文形式跨網(wǎng)絡(luò)傳遞敏感的 API 信息。然后攻擊者可以使用MITM攻擊來(lái)利用它。

當(dāng)服務(wù)使用默認(rèn)帳戶(hù)和憑據(jù)并且默認(rèn)值已知時(shí)，攻擊者可以使用這些憑據(jù)代入該帳戶(hù)的角色。這可能允許他們?cè)L問(wèn)敏感信息或管理功能，可能導(dǎo)致 支持系統(tǒng)。

最后，如果 API 提供程序允許不必要的 HTTP 方法，則應(yīng)用程序無(wú)法正確處理這些方法或?qū)е旅舾行畔⑿孤兜娘L(fēng)險(xiǎn)會(huì)增加。

您可以使用 Web 應(yīng)用程序漏洞掃描程序（如 Nessus、Qualys、OWASP ZAP 和 Nikto）檢測(cè)其中的幾個(gè)安全錯(cuò)誤配置。這些掃描程序?qū)⒆詣?dòng)檢查 Web 服務(wù)器版本信息、標(biāo)頭、cookie、傳輸加密配置和參數(shù)，以查看是否缺少預(yù)期的安全措施。如果您知道要查找的內(nèi)容，也可以通過(guò)檢查標(biāo)頭、SSL 證書(shū)、cookie 和參數(shù)來(lái)手動(dòng)檢查這些安全配置錯(cuò)誤。

?

注入

?

當(dāng)請(qǐng)求傳遞到 API 的支持基礎(chǔ)結(jié)構(gòu)并且 API 提供程序不篩選輸入以刪除不需要的字符（此過(guò)程稱(chēng)為輸入清理）時(shí)，存在注入缺陷。詳細(xì)的錯(cuò)誤消息、HTTP 響應(yīng)代碼和意外的 API 行為都可能是您可能發(fā)現(xiàn)了注入缺陷的線索。

API 可能會(huì)將該有效負(fù)載直接傳遞到后端 SQL 數(shù)據(jù)庫(kù)，其中 OR 1=0 語(yǔ)句將失敗（因?yàn)?1 不等于 0），從而導(dǎo)致一些 SQL 錯(cuò)誤：

POST?/api/v1/register?HTTP?1.1
Host:?example.com
--snip--
{
"Fname":?"hAPI",
"Lname":?"Hacker",
"Address":?"'?OR?1=0--",
}

注入漏洞通常輔以其他漏洞，例如輸入清理不良。在以下示例中，您可以看到一種代碼注入攻擊，該攻擊使用 API GET 請(qǐng)求來(lái)利用弱查詢(xún)參數(shù)。在這種情況下，弱查詢(xún)參數(shù)將請(qǐng)求的查詢(xún)部分中的任何數(shù)據(jù)直接傳遞到底層系統(tǒng)，而不先對(duì)其進(jìn)行清理：以下響應(yīng)正文顯示 API 端點(diǎn)已縱為顯示主機(jī)的 /etc/passwd 文件，從而顯示系統(tǒng)上的用戶(hù)：

GET http://10.10.78.181:5000/api/v1/resources/books？show=/etc/passwd

root0root:/root:/bin/bash
daemon1daemon:/usr/sbin:/usr/sbin/nologin
bin2bin:/dev:/usr/sbin/nologin
sync4sync:/bin:/bin/sync
games5games:/usr/games:/usr/sbin/nologin
man6man:/var/cache/man:/usr/sbin/nologin
lp7lp:/var/spool/lpd:/usr/sbin/nologin
mail8mail:/var/mail:/usr/sbin/nologin
news9news:/var/spool/news:/usr/sbin/nologin

查找注入缺陷需要認(rèn)真測(cè)試 API 端點(diǎn)，注意 API 的響應(yīng)方式，然后精心制作嘗試操縱后端系統(tǒng)的請(qǐng)求。與目錄遍歷攻擊一樣，注入攻擊已經(jīng)存在了幾十年，因此有許多標(biāo)準(zhǔn)的安全控制措施來(lái)保護(hù) API 提供程序免受這些攻擊。

?

資產(chǎn)管理不當(dāng)

?

當(dāng)組織公開(kāi) API 時(shí)，會(huì)發(fā)生不正確的資產(chǎn)管理 已停用或仍在開(kāi)發(fā)中。仍在開(kāi)發(fā)的 API 通常不如生產(chǎn) API 對(duì)應(yīng)項(xiàng)安全。

資產(chǎn)管理不當(dāng)會(huì)導(dǎo)致其他漏洞，例如數(shù)據(jù)過(guò)度暴露、信息泄露、批量分配、速率限制不當(dāng)和 API 注入等。

您可以通過(guò)密切關(guān)注倉(cāng)庫(kù)中過(guò)時(shí)的 API 文檔、更改日志和版本歷史記錄來(lái)發(fā)現(xiàn)不當(dāng)?shù)馁Y產(chǎn)管理。

組織通常在其終結(jié)點(diǎn)名稱(chēng)中包含版本控制信息，以區(qū)分較舊版本和較新版本，例如 等。仍在開(kāi)發(fā)中的 API 通常使用諸如 .如果您知道 API 現(xiàn)在正在使用 apiv3.org/admin 但 API 文檔的一部分提到了 apiv1.org/admin，則可以嘗試測(cè)試不同的端點(diǎn)以查看 apiv1 或 apiv2 是否仍處于活動(dòng)狀態(tài)。此外，組織的更新日志 可能會(huì)披露 v1 更新或停用的原因。如果您有權(quán)訪問(wèn) v1，則可以測(cè)試這些弱點(diǎn)/v1/, /v2/, /v3//alpha/, /beta/, /test/, /uat/, and /demo/

在使用文檔之外，您還可以通過(guò)使用猜測(cè)、模糊測(cè)試或暴力請(qǐng)求來(lái)發(fā)現(xiàn)不正確的資產(chǎn)管理漏洞。觀察 API 文檔或路徑命名方案中的模式，然后根據(jù)您的假設(shè)發(fā)出請(qǐng)求。

?

業(yè)務(wù)邏輯漏洞

?

業(yè)務(wù)邏輯漏洞（也稱(chēng)為業(yè)務(wù)邏輯缺陷或 BLF）是攻擊者可以惡意使用的應(yīng)用程序的預(yù)期功能。

例如，如果 API 具有不驗(yàn)證編碼有效負(fù)載的上傳功能，則只要任何文件已編碼，用戶(hù)就可以上傳該文件。這將允許最終用戶(hù)上傳和執(zhí)行任意代碼，包括惡意負(fù)載。在這些情況下，組織基本上依賴(lài)于 信任作為一種安全控制，期望消費(fèi)者采取仁慈的行為。不幸的是，即使是善良的 API 使用者也會(huì)犯錯(cuò)誤，從而導(dǎo)致應(yīng)用程序受損。

您可以在 API 文檔中搜索業(yè)務(wù)邏輯漏洞的跡象。像下面的陳述應(yīng)該照亮你頭頂?shù)臒襞荩?/p>

“僅使用功能 X 來(lái)執(zhí)行功能 Y。” “不要對(duì)端點(diǎn) Y 執(zhí)行 X。” “只有管理員才能執(zhí)行請(qǐng)求 X。”

當(dāng)您攻擊他們的 API 時(shí)，請(qǐng)確保不服從此類(lèi)請(qǐng)求以測(cè)試是否存在安全控制。

例如，請(qǐng)考慮用戶(hù)通常用來(lái)對(duì)其帳戶(hù)進(jìn)行身份驗(yàn)證的 Web 應(yīng)用程序身份驗(yàn)證門(mén)戶(hù)。假設(shè) Web 應(yīng)用程序發(fā)出了以下 API 請(qǐng)求：

POST?/api/v1/login?HTTP?1.1
Host:?example.com
--snip--
UserId=hapihacker&password=arealpassword!&MFA=true

我們有可能通過(guò)簡(jiǎn)單地將參數(shù)更改為 來(lái)繞過(guò)多因素身份驗(yàn)證。MFAfalse

測(cè)試業(yè)務(wù)邏輯缺陷可能具有挑戰(zhàn)性，因?yàn)槊總€(gè)業(yè)務(wù)都是獨(dú)一無(wú)二的。自動(dòng)掃描程序?qū)⒑茈y檢測(cè)到這些問(wèn)題，因?yàn)檫@些缺陷是API預(yù)期用途的一部分。您必須了解業(yè)務(wù)和 API 的運(yùn)作方式，然后考慮如何利用這些功能來(lái)發(fā)揮自己的優(yōu)勢(shì)。以對(duì)抗的心態(tài)研究應(yīng)用程序的業(yè)務(wù)邏輯，并嘗試打破任何假設(shè) 被制造

?

總結(jié)

?

熟悉這些漏洞非常重要，這樣您就可以輕松識(shí)別它們，在參與滲透測(cè)試期間利用它們，并將其報(bào)告給組織，以防止犯罪分子將您的客戶(hù)拖入頭條新聞。現(xiàn)在您已經(jīng)熟悉了 Web 應(yīng)用程序、API 及其弱點(diǎn)。

編輯：黃飛

?