【51CTO.com快譯】如今，無(wú)論是以API為主營(yíng)服務(wù)(API-first)的公司，或是單頁(yè)面應(yīng)用/JAMStack，都通過(guò)各種豐富的API對(duì)外公布著大量的數(shù)據(jù)。不過(guò)，由于這些數(shù)據(jù)能夠被直接地訪問(wèn)到，而且繞過(guò)了瀏覽器的預(yù)防機(jī)制。因此，我們需要擔(dān)心的不再是SQL注入和XSS等“入向”問(wèn)題，而是敏感數(shù)據(jù)記錄可能被竊取等API“出向”安全性問(wèn)題。此外，由于API被設(shè)計(jì)為能夠向單個(gè)客戶(hù)端提供大量的API訪問(wèn)，因此諸如驗(yàn)證碼(Captchas)和瀏覽器指紋識(shí)別之類(lèi)的典型預(yù)防機(jī)制，也不再能夠起到明顯的效果。

那么，我們?cè)撊绾伍_(kāi)始做好API的安全防護(hù)呢?在此，讓自己從攻擊者的角度來(lái)檢查目標(biāo)API，以阻斷常見(jiàn)的未知對(duì)象攻擊，并參照OWASP安全API列表

(請(qǐng)參見(jiàn)--https://owasp.org/www-project-api-security/)，來(lái)防范各種零日漏洞的利用。

1. 限制不安全的資源訪問(wèn)

大多數(shù)API都提供了對(duì)于實(shí)體列表(例如/users或/widgets)的資源訪問(wèn)。諸如瀏覽器之類(lèi)的客戶(hù)端通常會(huì)使用如下方式，來(lái)進(jìn)行過(guò)濾和分頁(yè)(pagination)，以限制返回給客戶(hù)端的條目數(shù)：

First Call: GET /items?skip=0&take=10  
Second Call: GET /items?skip=10&take=10 

但是，如果該實(shí)體中含有任何PII(個(gè)人身份信息)或其他敏感信息，那么攻擊者就可能通過(guò)該端點(diǎn)，獲取數(shù)據(jù)庫(kù)中的所有實(shí)體信息。一旦這些實(shí)體的PII被意外泄露，競(jìng)爭(zhēng)對(duì)手就能夠推斷出貴企業(yè)的采購(gòu)信息和客戶(hù)狀況，甚至是大量的郵件列表。如果您對(duì)此有興趣的話，可以參看《如何清除Venmo數(shù)據(jù)》

(https://22-8miles.com/public-by-default/)一文。

常規(guī)的保護(hù)機(jī)制是記錄那些大于100或1000條的條目，并拋出異常信息。下面是兩種常見(jiàn)的默認(rèn)保護(hù)方法：

• 對(duì)于數(shù)據(jù)型API，合法客戶(hù)可能需要獲取并同步大量的記錄，并通過(guò)各種cron作業(yè)來(lái)實(shí)現(xiàn)。那么人為地限制分頁(yè)的大小，會(huì)迫使API頻繁地進(jìn)行同一種操作，進(jìn)而降低了整體吞吐量?？梢哉f(shuō)，此類(lèi)最大條目限制方法主要是為了滿足內(nèi)存和可擴(kuò)展性的要求，以及防止某些DDoS攻擊。
• 如下代碼段所示，通過(guò)編寫(xiě)簡(jiǎn)單的腳本，在重復(fù)的訪問(wèn)之間，隨機(jī)休眠一段時(shí)間。當(dāng)然，此類(lèi)防護(hù)對(duì)于攻擊者來(lái)說(shuō)，并非總是奏效。

skip = 0 
while True:    response = requests.post('https://api.acmeinc.com/widgets?take=10&skip=' + skip),                      headers={'Authorization': 'Bearer' + ' ' + sys.argv[1]})    print("Fetched 10 items")    sleep(randint(100,1000))    skip += 10 

2. 防止分頁(yè)攻擊

為了防止分頁(yè)攻擊，您應(yīng)該跟蹤在一定時(shí)間段內(nèi)，用戶(hù)或API密鑰訪問(wèn)某個(gè)資源的數(shù)量，而不是僅僅停留在請(qǐng)求本身。您可以在用戶(hù)或API密鑰達(dá)到閾值時(shí)(例如：每個(gè)用戶(hù)或API密鑰在一個(gè)小時(shí)內(nèi)之允許調(diào)用1,000,000條記錄)阻止它們。當(dāng)然，具體閾值的設(shè)定取決于您的API用例，以及它們的訂閱方式。就像每分鐘只能發(fā)送一次驗(yàn)證碼那樣，此舉減緩了黑客調(diào)用目標(biāo)API的速度。對(duì)此，攻擊者不得不手動(dòng)創(chuàng)建更多新的帳戶(hù)或API密鑰。

3. 保護(hù)API密鑰池

大多數(shù)API會(huì)受密鑰或JWT(JSON Web令牌)的保護(hù)。由于API安全工具可以檢測(cè)到異常的API行為，并自動(dòng)阻止對(duì)于API密鑰的訪問(wèn)，因此這是跟蹤和保護(hù)API的原生方式。但是，攻擊者往往會(huì)使用大量的IP地址，來(lái)規(guī)避DDoS的檢查;并通過(guò)生成大量的賬戶(hù)，來(lái)獲取大量的API密鑰。

抵御此類(lèi)攻擊的最簡(jiǎn)單方法是要求用戶(hù)注冊(cè)自己的服務(wù)，并生成對(duì)應(yīng)的API密鑰。我們可以通過(guò)使用驗(yàn)證碼和雙因素身份驗(yàn)證，來(lái)阻止各種僵尸(Bot)流量。除非是合法的業(yè)務(wù)用例，否則新注冊(cè)服務(wù)的用戶(hù)不能夠以程序的方式，生成API密鑰。相反，只有那些受信任的用戶(hù)，才具有生成API密鑰的能力。據(jù)此，我們可以確保在帳戶(hù)級(jí)別(不僅僅針對(duì)每個(gè)API密鑰)上，對(duì)異常行為進(jìn)行異常檢測(cè)。

4. 防止意外的密鑰泄露

總的說(shuō)來(lái)，如下使用API的方式會(huì)增加密鑰泄漏的可能性：

• 如果您將該API密鑰保存在服務(wù)器的環(huán)境變量中，并提供侍候型的訪問(wèn)方式，那么就會(huì)增加黑客獲得有效且未過(guò)期的密鑰的可能性。這顯然不及用戶(hù)在登錄交互式網(wǎng)站時(shí)，在會(huì)話中使用較短時(shí)間到期的API密鑰安全。
• API的使用者可以直接訪問(wèn)到密鑰，例如通過(guò)Postman或CURL進(jìn)行調(diào)試。那么任何一個(gè)開(kāi)發(fā)人員都可以將含有API密鑰的CURL命令，意外地復(fù)制/粘貼到諸如GitHub Issues或Stack Overflow之類(lèi)的公共論壇中。
• 如果不采用一次性令牌或雙因素身份驗(yàn)證，API將無(wú)法保護(hù)其密鑰。

防止密鑰泄露的最簡(jiǎn)單方法是利用兩個(gè)令牌而非一個(gè)。刷新令牌(refresh token)被存儲(chǔ)為環(huán)境變量，并且只能用于產(chǎn)生短暫的訪問(wèn)令牌(short lived access tokens)。與刷新令牌不同，這些短暫的令牌可以訪問(wèn)到資源，但是有著時(shí)間的限制，例如數(shù)小時(shí)或數(shù)天。

客戶(hù)存儲(chǔ)刷新令牌和其他API密鑰。SDK會(huì)在其初始化時(shí)、或是最后一個(gè)訪問(wèn)令牌到期時(shí)，生成新的訪問(wèn)令牌。如果CURL命令被粘貼到GitHub中，那么攻擊者必須在數(shù)小時(shí)內(nèi)使用短暫的訪問(wèn)令牌，不然就會(huì)過(guò)期(畢竟他獲取到刷新令牌的可能性極低)。

5. 阻止DDoS攻擊

API開(kāi)辟了全新的業(yè)務(wù)模式，用戶(hù)可以在其中以編程的方式訪問(wèn)到目標(biāo)API平臺(tái)。但是，這也會(huì)使得針對(duì)DDoS保護(hù)變得十分棘手。大多數(shù)DDoS的保護(hù)機(jī)制是清洗或拒絕攻擊者發(fā)來(lái)的大量請(qǐng)求。但是為了讓混淆在僵尸流量中正常請(qǐng)求能夠順利通過(guò)，我們需要對(duì)HTTP請(qǐng)求進(jìn)行指紋識(shí)別。但是對(duì)于API服務(wù)而言，這是極其困難的，畢竟所有的流量都看上去像僵尸流量，而非來(lái)自瀏覽器的Cookie。

如今，絕大多數(shù)的關(guān)于API的訪問(wèn)和調(diào)用都需要用到API密鑰。如果某個(gè)請(qǐng)求中沒(méi)有API密鑰，則會(huì)被自動(dòng)拒絕。那么，我們?cè)撊绾翁幹媚切┙?jīng)過(guò)驗(yàn)證的請(qǐng)求呢?目前，最簡(jiǎn)單的方法是利用每個(gè)API密鑰的速率限制計(jì)數(shù)器，例如：我們可以預(yù)先設(shè)定每分鐘可以處置X個(gè)請(qǐng)求，那么對(duì)于超過(guò)這個(gè)數(shù)量級(jí)的請(qǐng)求，則以帶有HTTP 429的響應(yīng)方式予以拒絕。目前，我們可以采用諸如漏斗和固定窗口計(jì)數(shù)器等多種算法，來(lái)實(shí)現(xiàn)這一點(diǎn)。

6. 通過(guò)正確的SSL來(lái)確保服務(wù)器安全

其實(shí)在服務(wù)器安全方面，API與Web服務(wù)器并無(wú)太大差別。錯(cuò)誤配置的SSL證書(shū)，或默認(rèn)允許非HTTPS的流量通過(guò)，都可能導(dǎo)致數(shù)據(jù)的泄漏。如今，非HTTPS請(qǐng)求雖然已經(jīng)逐漸被HTTPS所取代，但是用戶(hù)仍然可能錯(cuò)誤地從其應(yīng)用程序、或泄露了API密鑰的CURL中發(fā)出非HTTPS的請(qǐng)求。而且API是無(wú)法實(shí)現(xiàn)HSTS(HTTP Strict Transport Security，HTTP嚴(yán)格傳輸安全協(xié)議)、或HTTPS重定向之類(lèi)的瀏覽器級(jí)保護(hù)的。

目前比較普遍的做法是通過(guò)Qualys SSL Test(請(qǐng)參見(jiàn)--https://www.ssllabs.com/ssltest/)或類(lèi)似的工具，來(lái)實(shí)施并測(cè)試SSL。無(wú)論您的API是僅供自己的應(yīng)用來(lái)訪問(wèn)，還是要在服務(wù)器端被訪問(wèn)到，您都可以通過(guò)負(fù)載均衡設(shè)備來(lái)阻斷所有非HTTPS頭的請(qǐng)求。具體請(qǐng)參見(jiàn)《REST API跨域資源共享權(quán)威指南》

(https://www.moesif.com/blog/technical/cors/Authoritative-Guide-to-CORS-Cross-Origin-Resource-Sharing-for-REST-APIs/?utm_source=dzone&utm_medium=blog&utm_campaign=placed-article&utm_term=top-10-api-security-threats)一文。

7. 確保正確地配置緩存頭

API通過(guò)不同的密鑰，提供了對(duì)于既定范圍內(nèi)動(dòng)態(tài)數(shù)據(jù)的訪問(wèn)。那么任何緩存機(jī)制的實(shí)現(xiàn)，都應(yīng)該基于API密鑰的范圍，以防止出現(xiàn)數(shù)據(jù)的“交叉污染”。例如：某個(gè)用戶(hù)通過(guò)代理服務(wù)器正在使用多個(gè)API密鑰，其中一個(gè)被用于開(kāi)發(fā)環(huán)境，另一個(gè)被用于生產(chǎn)環(huán)境，那么兩個(gè)環(huán)境中的數(shù)據(jù)就可能產(chǎn)生相互泄露。此方面的一個(gè)真實(shí)案例是：Twitter曾在數(shù)據(jù)安全事件后證實(shí)泄漏了賬號(hào)相關(guān)信息(請(qǐng)參見(jiàn)：

https://www.bleepingcomputer.com/news/security/twitter-discloses-billing-info-leak-after-data-security-incident/)。

通常情況下，許多API并不使用標(biāo)準(zhǔn)的認(rèn)證頭，而是類(lèi)似于X-Api-Key的自定義頭。如下代碼段所示，緩存服務(wù)器在并不知曉此類(lèi)請(qǐng)求是否已通過(guò)驗(yàn)證的情況下，只能選擇對(duì)其進(jìn)行緩存?？梢?jiàn)，我們應(yīng)該正確地配置緩存控制(Cache-Control)頭。

app.use((req, res, next) => {  res.setHeader('Cache-Control', 'no-store, no-cache, must-revalidate');  res.setHeader('Pragma', 'no-cache');  // ... 
}); 

8. 正確地添加API日志記錄

通過(guò)對(duì)大多數(shù)入侵案例的研究，OWASP層發(fā)現(xiàn)：企業(yè)通常需要超過(guò)200天，才能檢測(cè)到數(shù)據(jù)發(fā)生了泄漏事件。而且，如果未能采用適當(dāng)?shù)腁PI日志記錄和監(jiān)控，攻擊者可能會(huì)持續(xù)使用相同的漏洞，進(jìn)而探測(cè)到更多的漏洞。

我們不但應(yīng)該確保API日志記錄能夠跟蹤API的請(qǐng)求本身，而且需要通過(guò)綁定以實(shí)現(xiàn)對(duì)用戶(hù)行為的分析。與此同時(shí)，此類(lèi)系統(tǒng)應(yīng)當(dāng)受到相應(yīng)的保護(hù)，以確保數(shù)據(jù)記錄不會(huì)被意外地刪除，或過(guò)早地銷(xiāo)毀掉(應(yīng)至少存儲(chǔ)一年)。為了安全起見(jiàn)，GDPR和CCPA都允許系統(tǒng)開(kāi)展API審計(jì)。如下圖的API審計(jì)日志所示，像Moesif API Security

(https://www.moesif.com/solutions/api-security?utm_source=dzone&utm_medium=blog&utm_campaign=placed-article&utm_term=top-10-api-security-threats)之類(lèi)的方案，能夠?yàn)锳PI產(chǎn)品提供了一整套監(jiān)視和分析功能，并且用戶(hù)只需數(shù)分鐘就能夠快速上手。

9. 正確地處理授權(quán)

雖然大多數(shù)API開(kāi)發(fā)人員都會(huì)自覺(jué)地添加諸如API密鑰、或OAuth之類(lèi)的全局性認(rèn)證方案、來(lái)驗(yàn)證調(diào)用方的身份。但是，我們也需要通過(guò)授權(quán)的方式，來(lái)檢查他們是否可以訪問(wèn)某些特定的資源。對(duì)此，我們往往會(huì)借用訪問(wèn)控制列表(ACL)，并為相關(guān)對(duì)象分配不同的角色，來(lái)實(shí)現(xiàn)基于角色的訪問(wèn)控制。您可以參考《為RESTful API構(gòu)建身份驗(yàn)證和授權(quán)的步驟》一文(請(qǐng)參見(jiàn)--https://www.moesif.com/blog/technical/restful-apis/Authorization-on-RESTful-APIs/?utm_source=dzone&utm_medium=blog&utm_campaign=placed-article&utm_term=top-10-api-security-threats)，以了解具體的防護(hù)方法。

10. 保護(hù)內(nèi)、外部端點(diǎn)

同一項(xiàng)API服務(wù)有可能具有內(nèi)、外不同的使用端點(diǎn)。那么，除了使用身份驗(yàn)證和授權(quán)等基本保護(hù)方案之外，我們還應(yīng)通過(guò)啟用負(fù)載均衡器或API網(wǎng)關(guān)，以確保這些端點(diǎn)不會(huì)完全暴露于公共互聯(lián)網(wǎng)上。此外，我們也可以通過(guò)提供多級(jí)安全性(一種常見(jiàn)的預(yù)防策略)，來(lái)進(jìn)行API的防護(hù)與加持。

原標(biāo)題：Top 10 API Security Threats Every API Team Should Know ，作者：Derric Gilling

【51CTO譯稿，合作站點(diǎn)轉(zhuǎn)載請(qǐng)注明原文譯者和出處為51CTO.com】