9 個用于英國、歐盟和全球驗證的增值稅 API
對于當今企業(yè)的高級官員來說，API 安全的至關(guān)重要性也變得越來越明顯。事實上，在我們的 API 安全現(xiàn)狀調(diào)查中，近一半（48%）的受訪者表示 API 安全現(xiàn)已成為 C 級討論的話題。獨立研究公司 Global Surveyz 代表 Salt Security 開展的一項全球調(diào)查的結(jié)果也證實了這一結(jié)論，全球大多數(shù) CISO（78%）表示，與兩年前相比，API 安全是當今更優(yōu)先考慮的問題，95% 的 CISO 表示，API 安全將是未來兩年的首要任務(wù)。
盡管 API 網(wǎng)關(guān)和 Web 應(yīng)用程序防火墻 (WAF) 等傳統(tǒng)安全措施可以為企業(yè)的安全堆棧增添價值，但它們跟不上當今日益復(fù)雜的 API 攻擊方法。事實上，它們無法阻止攻擊者竊取敏感數(shù)據(jù)、影響用戶體驗或造成其他破壞。要預(yù)防和減輕 API 攻擊，您需要專門針對 API 而設(shè)計的安全策略和技術(shù)。
攻擊方式已發(fā)生變化，而且很容易被忽略
針對應(yīng)用程序接口的惡意攻擊者已經(jīng)超越了傳統(tǒng)的 “一勞永逸 “攻擊，如 SQLi 和 XSS。他們現(xiàn)在的重點是尋找 API 業(yè)務(wù)邏輯中的漏洞。您的 API 是獨一無二的，因此攻擊也必須是獨一無二的。攻擊者需要花費幾天、幾周甚至幾個月的時間來探測和學(xué)習(xí) API，他們使用的是傳統(tǒng)安全工具無法察覺的 “低慢 “技術(shù)。
REST API 安全性、SOAP 安全性和 GraphQL 安全性在確保 API 和網(wǎng)絡(luò)應(yīng)用程序的保護方面都發(fā)揮著重要作用。每種技術(shù)都有不同的安全方法，需要考慮特定的安全因素。
REST 是 “表征狀態(tài)傳輸”（Representational State Transfer）的縮寫，是網(wǎng)絡(luò)服務(wù)中常用的一種架構(gòu)風(fēng)格。它依賴于 GET、POST、PUT、DELETE 等標準 HTTP 方法，并使用 URL 來標識資源。 REST API 有其獨特的安全考慮因素，例如：
身份驗證機制–REST API 通常使用 API 密鑰、OAuth 標記或 JSON Web 標記 (JWT) 等身份驗證機制來驗證客戶身份并授予對資源的訪問權(quán)限。
授權(quán)機制：用戶通過身份驗證后，REST API 會使用授權(quán)機制來控制他們可以訪問哪些資源。
速率限制：實施速率限制，限制客戶端在一定時間內(nèi)的請求次數(shù)，防止濫用和 DoS 攻擊。
輸入驗證：必須采用這種方法來防止常見的安全漏洞，如 SQL 注入和跨站腳本 (XSS) 攻擊。
HTTPS 加密：對客戶端和服務(wù)器之間傳輸?shù)臄?shù)據(jù)進行加密對 REST API 至關(guān)重要。HTTPS 加密用于防止未經(jīng)授權(quán)的攔截。
跨源資源共享（CORS）：REST 架構(gòu)中必須使用 CORS 標頭，以控制哪些域可以訪問手頭的 API。
要有效保護 REST API，除了其他 REST API 安全最佳實踐外，還必須考慮到所有這些方面。
SOAP（簡單對象訪問協(xié)議）是一種用于在網(wǎng)絡(luò)服務(wù)中交換信息的協(xié)議。它通常使用 XML 并依賴于其他網(wǎng)絡(luò)協(xié)議，如 HTTP、SMTP 和 TCP。SOAP 還有一些重要的安全考慮因素：
敏感數(shù)據(jù)加密：SOAP 信息中的敏感數(shù)據(jù)應(yīng)加密，以確保傳輸過程中的保密性。
XML 驗證：根據(jù)預(yù)定義模式驗證 XML 有助于防止 XML 注入和相關(guān)攻擊。
WS-security 標準：SOAP 為確保信息安全提供了這一安全標準，其中包括信息完整性、保密性、身份驗證和授權(quán)等功能。
HTTPS 安全：與 REST API 類似，SOAP 信息也應(yīng)通過 HTTPS 加密傳輸，以確保傳輸數(shù)據(jù)的安全。
數(shù)字簽名：應(yīng)盡可能使用數(shù)字簽名來評估 SOAP 消息的完整性和合法性。
GraphQL 是一種用于 API 的查詢語言，也是一種用于通過后端系統(tǒng)執(zhí)行這些查詢的運行時。與為不同資源提供多個 API 端點的 REST 不同，GraphQL 使用單個端點進行所有查詢。以下是 GraphQL 最重要的安全注意事項：
身份驗證和授權(quán)：GraphQL API 必須實施身份驗證和授權(quán)機制，以控制對各種查詢和突變的訪問。近年來，已知有惡意行為者成功利用 GraphQL 授權(quán)漏洞實施 API 攻擊。
速率限制：應(yīng)用速率限制對于控制客戶端在給定時間內(nèi)可執(zhí)行的 GraphQL 查詢次數(shù)至關(guān)重要。
輸入驗證：對 GraphQL 中的用戶輸入進行驗證和消毒有助于防止常見的安全漏洞。
查詢深度限制：必須對 GraphQL 查詢的深度設(shè)置限制，以防止可能導(dǎo)致拒絕服務(wù) (DoS) 攻擊的復(fù)雜和資源密集型查詢。
歸根結(jié)底，無論是 REST、SOAP 還是 GraphQL，任何 API 的安全性都取決于最佳實踐的組合，其中包括身份驗證和授權(quán)機制、數(shù)據(jù)驗證以及安全通信協(xié)議的使用。一個涵蓋發(fā)現(xiàn)、運行時保護和左移實踐的強大 API 安全戰(zhàn)略對于保護 API 不受新出現(xiàn)的威脅至關(guān)重要。
Salt—完整的應(yīng)用程序接口安全，提供全面保護
要想有效保護 API，首先要了解當今的攻擊為何與眾不同。當今最常見的 API 攻擊可分為四類：
在這類攻擊中，攻擊者利用的 API 要么是組織完全不知道的 API（影子 API 或僵尸 API），要么是安全狀況不可見的 API（如未托管 API 或第三方 API）。
要實施這種類型的攻擊，不良行為者會完全按照設(shè)計使用 API，但會利用設(shè)計或開發(fā)缺陷，以非預(yù)期的惡意方式利用結(jié)果，造成惡意結(jié)果，如數(shù)據(jù)外滲。
在基于業(yè)務(wù)邏輯的攻擊中，黑客會長期使用偵察技術(shù)，在每個 API 的獨特業(yè)務(wù)邏輯中尋找漏洞。在可能持續(xù)數(shù)天、數(shù)周甚至數(shù)月的偵察階段，攻擊者會尋找可探索的領(lǐng)域，如未經(jīng)授權(quán)訪問 API 中的數(shù)據(jù)或功能。
當不良行為者使用社交工程技術(shù)訪問有權(quán)限的 API 密鑰時，就會出現(xiàn)這類威脅。這樣，他們就能竊取憑證并使用 API，就好像他們是經(jīng)過認證的合法用戶或管理員一樣。根據(jù)《2023 年第一季度 API 安全狀況報告》（State of API Security Report Q1 2023），在去年，78% 的攻擊來自于看似合法的用戶，但他們卻惡意實現(xiàn)了適當?shù)纳矸蒡炞C。
為了幫助 API 安全行業(yè)更深入地了解最常見的 API 攻擊，開放式 Web 應(yīng)用程序安全項目（OWASP）首次發(fā)布了 2019 年 API 安全十大漏洞列表。該榜單在 2023 年進行了更新，列出了十個較為重要的 API 漏洞。其中，最常見的有：
破損的對象級授權(quán)（BOLA）約占 API 攻擊的 40%，是最常見的 API 威脅。
由于 API 經(jīng)常暴露處理對象 ID 的端點，這就形成了一個巨大的潛在攻擊面。對象級授權(quán)是一種訪問控制方法，通常在代碼級實施，用于驗證用戶訪問特定對象的能力。現(xiàn)代應(yīng)用程序使用各種復(fù)雜而普遍的授權(quán)和訪問控制系統(tǒng)。開發(fā)人員經(jīng)常忽略在訪問對象前應(yīng)用這些檢查，即使應(yīng)用程序包含了強大的授權(quán)檢查基礎(chǔ)架構(gòu)。攻擊者可以通過操縱在 API 請求中發(fā)送的對象 ID，輕松利用易受對象級授權(quán)漏洞影響的 API 端點。BOLA 授權(quán)漏洞可導(dǎo)致數(shù)據(jù)外泄以及未經(jīng)授權(quán)的數(shù)據(jù)查看、修改或銷毀。最終，BOLA 可導(dǎo)致全面賬戶接管 (ATO)。
攻擊者很容易將目標鎖定在身份驗證流程上，尤其是在這些流程完全暴露或可被公眾訪問的情況下。OWASP 報告的第二大最常見漏洞是用戶身份驗證漏洞，攻擊者可利用憑證填充、竊取身份驗證令牌和暴力破解攻擊來獲取對應(yīng)用程序的未授權(quán)訪問。這樣，攻擊者就能控制用戶賬戶，非法訪問其他用戶的數(shù)據(jù)，并進行未經(jīng)授權(quán)的交易。技術(shù)問題，如密碼復(fù)雜性不足、賬戶鎖定標準缺失、密碼和證書的輪換時間過長，或?qū)?API 密鑰作為唯一的身份驗證方法，都可能導(dǎo)致 API 的身份驗證出現(xiàn)問題。
攻擊者若能成功利用身份驗證程序中的弱點，就能在未經(jīng)授權(quán)的情況下訪問其他用戶的數(shù)據(jù)，并使用該用戶的賬戶進行非法交易。
破壞對象屬性級授權(quán)合并了通過 “過度數(shù)據(jù)暴露”（之前被列為 2019 年 OWASP API 安全 Top 10 中的第 3 位）或 “大規(guī)模分配”（之前被列為 2019 年榜單中的第 6 位）未經(jīng)授權(quán)訪問敏感信息的攻擊。這兩種技術(shù)都是基于 API 端點操作來獲取敏感數(shù)據(jù)。
將這一新威脅引入榜單的主要原因是，即使 API 可以執(zhí)行足夠的對象級授權(quán)安全措施，這可能仍然不足以保護它。通常需要對對象及其特征進行更具體的授權(quán)。還必須考慮 API 對象內(nèi)部的不同訪問級別，因為 API 對象通常同時具有公共屬性和私有屬性。
不受限制的資源消耗漏洞取代了之前在 OWASP API 安全十大漏洞中排名第四的 “缺乏資源和速率限制 “漏洞。不過，雖然名稱變了，但該漏洞總體上沒有變化。
API 調(diào)用會占用網(wǎng)絡(luò)、CPU、內(nèi)存和存儲等資源。用戶的輸入和端點的業(yè)務(wù)邏輯對滿足請求所需的資源數(shù)量有重大影響。客戶端或用戶請求的資源大小或數(shù)量不一定受 API 的限制。這不僅有可能對 API 服務(wù)器性能造成負面影響并導(dǎo)致拒絕服務(wù)（DoS），而且還會使支持身份驗證和數(shù)據(jù)檢索的 API 容易受到暴力攻擊和枚舉攻擊，包括令牌和憑證破解。
根據(jù)《2023 年第一季度 API 安全狀況報告》（State of API Security Report Q1 2023），只有 54% 的受訪者將 OWASP API 安全十大問題作為其安全計劃的優(yōu)先考慮事項，盡管 62% 的針對組織的未遂攻擊至少利用了其中一種方法。
傳統(tǒng)的安全解決方案（包括 WAF、API 網(wǎng)關(guān)、API 管理工具以及身份和訪問管理 (IAM) 工具）并不是為防止對 API 的攻擊而設(shè)計的。這是因為 API 的安全防護面臨著獨特的挑戰(zhàn)：
API無序擴張：不斷變化的環(huán)境
隨著當今的 DevOps 團隊不斷開發(fā)和更改 API，API 所面臨的威脅類型也發(fā)生了變化。過去，基于事務(wù)的攻擊（如 SQL 注入和其他代碼執(zhí)行方法）是最普遍的攻擊手段，但如今的攻擊通常旨在利用每個 API 背后的底層應(yīng)用程序和業(yè)務(wù)邏輯。有 37% 的公司每周更新一次 API，指望開發(fā)團隊在部署新的或更新的 API 之前發(fā)現(xiàn)每一個可能的 API 漏洞是不現(xiàn)實的。
SQL 注入或跨站腳本等傳統(tǒng)攻擊仍在發(fā)生，但當今最成功的基于應(yīng)用程序邏輯的 API 攻擊并不遵循那些利用已知漏洞的 “一勞永逸 “機制。由于每個 API 端點都是不同的，而且每次攻擊很少源于單個 API 調(diào)用，因此每次 API 攻擊本質(zhì)上都是零日攻擊，傳統(tǒng)工具無法通過基于規(guī)則和簽名的方法檢測到它們。不良分子的偵查活動需要時間。他們可能需要數(shù)周甚至數(shù)月的時間來尋找數(shù)據(jù)、查找漏洞并誘導(dǎo)異常行為，從而找到破壞供應(yīng)鏈或從 API 中滲出數(shù)據(jù)的微妙方法。
一直以來，企業(yè)在部署應(yīng)用程序之前都依賴測試來發(fā)現(xiàn)安全漏洞。然而，敏捷開發(fā)方法的廣泛采用和 API 過度擴展的問題使得對每一個 API 漏洞進行測試變得根本不可能。雖然標準的生產(chǎn)前測試可以發(fā)現(xiàn) API 安全最佳實踐中的一些漏洞，但卻無法發(fā)現(xiàn)源于 API 業(yè)務(wù)邏輯漏洞的漏洞，而這些漏洞恰恰是當今攻擊者想要利用的。此外，指望任何開發(fā)人員每次都能編寫出完全安全的代碼是不現(xiàn)實的，因此檢測和阻止 API 威脅的唯一方法就是實施運行時保護。
API 的保護具有挑戰(zhàn)性。傳統(tǒng)解決方案無法處理 API 生態(tài)系統(tǒng)的復(fù)雜性。攻擊者深知這一點，因此他們將重點放在 API 上。
以下最佳實踐可以幫助您改善 API 的安全狀況：
對應(yīng)用程序接口的最佳保護是一個從一開始就考慮到應(yīng)用程序接口安全性的專用平臺。正確的 API 安全平臺應(yīng)自動
發(fā)現(xiàn)所有新的和已更改的 API，以及它們暴露的任何敏感數(shù)據(jù)。
在偵查階段檢測并阻止對 API 的攻擊。
通過向開發(fā)團隊提供可行的見解，盡可能在構(gòu)建階段消除漏洞。
為整個應(yīng)用程序接口生命周期提供保護：
完整的 API 安全解決方案應(yīng)該能夠收集、存儲和分析數(shù)百萬用戶和 API 調(diào)用中的數(shù)百個屬性，更重要的是，能夠利用人工智能（AI）和機器學(xué)習(xí)（ML）對其進行長期關(guān)聯(lián)。要獲得這種廣度的背景信息，需要云規(guī)模的大數(shù)據(jù)，因為基于服務(wù)器或虛擬機的方法隨著時間的推移不會有足夠廣泛的數(shù)據(jù)集來識別當今復(fù)雜、低速和緩慢的 API 攻擊。只有具備了這種自適應(yīng)智能和深度上下文，您才能擁有保護所有 API 所需的能力。
原文鏈接：API Security 101: API Security Strategy and Fundamentals Guide