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