了解 API 技術(shù)：REST、GraphQL 和異步 API 的比較分析
因此，制定全面的 API 安全戰(zhàn)略至關(guān)重要。從身份驗證到安全存儲和加密，安全最佳實踐可確保您的數(shù)據(jù)安全。
在這篇文章中，我們將解釋 API 安全的基本原理，包括針對 API 的常見威脅以及防御這些威脅的最佳方法，這樣您就可以從這項技術(shù)中獲益，而不會受到其不利影響。
API 安全是保護 API 免受網(wǎng)絡(luò)攻擊和濫用的做法。適當?shù)膽?yīng)用程序接口安全措施可確保對API的所有處理請求均來自合法來源且有效。安全最佳實踐還可確保來自 API 的所有響應(yīng)都不會被攔截或利用。
API有助于在系統(tǒng)和外部用戶之間傳輸數(shù)據(jù)（通常是私人數(shù)據(jù)）。因此，維護不善和不安全的 API 是通向敏感數(shù)據(jù)的一扇未上鎖的大門。使用最佳實踐（如使用VPN而不是殺毒軟件和真實API）來保護您的數(shù)據(jù)非常重要。
這對黑客來說是個好消息，對您的客戶來說是個巨大威脅。如果你覺得這是在危言聳聽，那么你要知道，數(shù)十億條記錄已因網(wǎng)絡(luò)攻擊而曝光，其中許多都是由于不安全的 API 造成的。
惡意行為者將目標對準了大小公司。API 黑客已經(jīng)影響到 Facebook、Venmo、Twitter 和美國郵政等企業(yè)。為了保護敏感數(shù)據(jù)，您必須將 API 安全納入規(guī)劃和構(gòu)建流程。
雖然網(wǎng)絡(luò)安全是一個涵蓋所有在線技術(shù)的廣泛話題，但API卻帶來了獨特的挑戰(zhàn)。
API介于第三方開發(fā)人員和公司資源之間。這些安全漏洞會對應(yīng)用程序和用戶造成危害，因為被黑客攻擊的端點會直接訪問敏感信息。
雖然財務(wù)影響可能很大，但對品牌的損害可能無法彌補。使用您的 API 肯定會失去客戶的信任和信譽。第三方集成應(yīng)用程序甚至可能因此受到損害。
在回顧加固 API 的最佳實踐之前，我們需要知道我們要面對的是什么。以下是您應(yīng)該了解的針對 API 的最常見攻擊。
訪問API的最簡單方法之一就是劫持授權(quán)用戶的身份。例如，如果身份驗證令牌落入不法分子之手，它可能會被用來訪問具有惡意意圖的資源，同時看起來是合法的。
網(wǎng)絡(luò)犯罪分子會試圖猜測身份驗證密碼或破解薄弱的身份驗證程序，以獲取訪問權(quán)限。
當黑客截獲終端用戶與API之間的請求或響應(yīng)時，就會發(fā)生中間人（MITM）攻擊。他們可能竊取通信內(nèi)容（如登錄憑證或支付信息）或修改請求/響應(yīng)內(nèi)容。
在身份驗證和驗證方面存在漏洞的 API 也容易受到代碼注入的攻擊，在這種情況下，攻擊者會通過 API 請求向應(yīng)用程序的服務(wù)器發(fā)送腳本。這種腳本的目的是暴露或刪除數(shù)據(jù)、植入虛假信息和/或破壞應(yīng)用程序的內(nèi)部結(jié)構(gòu)。
您還會看到 “SQL 注入 ”一詞。這種代碼注入是在 SQL 數(shù)據(jù)庫中進行的。
拒絕服務(wù)（DoS）攻擊會通過 API 請求壓倒服務(wù)器資源，從而導(dǎo)致網(wǎng)絡(luò)服務(wù)器速度變慢、中斷或崩潰。這些攻擊通常由多個惡意源同時發(fā)起，即分布式拒絕服務(wù)（DDoS）攻擊。
盡管存在這些風險，但 API 不會很快消失。幾乎所有尋求與他人集成的在線應(yīng)用程序都需要 API。
每一個新的API都為黑客提供了另一個利用個人數(shù)據(jù)的機會。因此，任何監(jiān)督軟件集成的人都應(yīng)該了解 API 安全措施。這些最佳實踐有助于保護敏感數(shù)據(jù)免受網(wǎng)絡(luò)攻擊和未經(jīng)授權(quán)的訪問。
防止未經(jīng)授權(quán)訪問的第一道防線是實施身份驗證系統(tǒng)，要求用戶在訪問任何數(shù)據(jù)前提供有效憑證。授權(quán)也很重要，因為它規(guī)定了每個用戶訪問特定信息的級別。
我們喜歡的是：身份驗證和授權(quán)保護用戶免受未經(jīng)授權(quán)的訪問。
最適合：所有涉及敏感數(shù)據(jù)或需要用戶身份驗證的應(yīng)用程序。
專業(yè)建議：啟用雙因素身份驗證 (2FA)，提供額外的安全保障，確保只有獲得授權(quán)的人才能訪問系統(tǒng)。
API與客戶端之間的所有通信都應(yīng)通過 SSL 連接或 TLS 加密協(xié)議（如 HTTPS）來確保安全。這可確保通過網(wǎng)絡(luò)發(fā)送的所有數(shù)據(jù)都經(jīng)過加密，并防止第三方惡意攻擊。
我們喜歡的是：SSL/TLS加密為保護傳輸中的數(shù)據(jù)提供了一個額外的安全層。
最適合：任何通過網(wǎng)絡(luò)發(fā)送敏感數(shù)據(jù)或存儲用戶私人信息的應(yīng)用程序。
專業(yè)建議：確保您的網(wǎng)絡(luò)應(yīng)用程序使用最新、最安全的 HTTPS 版本，并啟用 TLS 1.3 協(xié)議，以最大限度地提高安全性。
為了防止惡意自動攻擊，您應(yīng)該對 API 調(diào)用實施速率限制。這將確保請求得到及時處理，而且不會有一個用戶同時向系統(tǒng)發(fā)出過多請求。
我們喜歡的是：速率限制可防止惡意自動攻擊。
最適合：任何網(wǎng)絡(luò)應(yīng)用程序或API都會快速接收來自同一用戶的多個請求。
專業(yè)建議：根據(jù)系統(tǒng)需要設(shè)置費率限制，并根據(jù)使用模式進行調(diào)整。
跟蹤用戶訪問的內(nèi)容以及他們使用這些信息所做的事情至關(guān)重要。確保記錄每個 API 請求，并保留用戶活動的審計日志，以確保數(shù)據(jù)安全和合規(guī)性。
我們喜歡的是：審計和日志記錄有助于跟蹤用戶活動，防止數(shù)據(jù)泄露或違規(guī)問題。
最適合：任何存儲或傳輸機密信息或個人數(shù)據(jù)的系統(tǒng)。
專業(yè)建議：確保您制定了全面的審計和日志記錄政策，并確保定期審查和更新，以跟上最新的安全威脅。
如果可能，限制對銀行信息或健康記錄等敏感數(shù)據(jù)的訪問。這可以通過授權(quán)策略或在數(shù)據(jù)通過網(wǎng)絡(luò)傳輸前對其進行加密來實現(xiàn)。
我們喜歡的是：限制敏感數(shù)據(jù)的訪問是防止?jié)撛跀?shù)據(jù)盜竊或濫用的好方法。
最適合：任何處理重要個人或財務(wù)信息的系統(tǒng)。
專業(yè)建議：評估不同的方法，如授權(quán)策略、加密、令牌化等，并使用最能滿足應(yīng)用需求的方法。
建立一個系統(tǒng)來監(jiān)控用戶行為，并在發(fā)現(xiàn)可疑活動（如多次嘗試訪問某個端點失敗）時發(fā)出警報。這將幫助你檢測和阻止惡意活動，避免其成為更大的問題。
我們喜歡的是：建立一個系統(tǒng)來監(jiān)控用戶行為并對可疑活動發(fā)出警報，可以幫助您在惡意攻擊成為更大問題之前發(fā)現(xiàn)并阻止它們。
最適合：任何需要驗證或攜帶敏感數(shù)據(jù)的網(wǎng)絡(luò)應(yīng)用程序。
專業(yè)建議：使用自動化工具定期掃描系統(tǒng)，并對任何異常活動設(shè)置警報。通過自動化工具利用流行的漏洞掃描儀來增強系統(tǒng)安全性。
確保為您的 API 更新最新的安全補丁，以及可能發(fā)布的任何新功能或錯誤修復(fù)。這有助于防止攻擊者利用任何已知漏洞。
我們喜歡的是：及時更新 API 可確保修補所有已知漏洞，這有助于防范潛在的攻擊者。
最適合：定期發(fā)布更新或漏洞修復(fù)的任何應(yīng)用程序。
專業(yè)建議：隨時關(guān)注最新的安全更新，并確保一有更新就立即應(yīng)用。
API 網(wǎng)關(guān)可以在客戶端和 API 之間充當 “守門員”，幫助保護 API 免受惡意攻擊。它將過濾掉任何可疑請求，并在請求到達目的地之前將其阻止。
我們喜歡的是：API網(wǎng)關(guān)充當客戶端和服務(wù)器之間的 “守門員”，在惡意攻擊到達目的地之前提供保護。
最適合：任何從外部接收大量請求的應(yīng)用程序。
專業(yè)建議：選擇具有高級過濾功能的 API 網(wǎng)關(guān)，以最大限度地防范潛在威脅。
任何本地存儲的數(shù)據(jù)都應(yīng)加密，以防止未經(jīng)授權(quán)的訪問。這包括可能拍攝的任何數(shù)據(jù)備份或快照。
我們喜歡的是：確保本地存儲的所有數(shù)據(jù)都經(jīng)過加密，防止未經(jīng)授權(quán)的個人或程序訪問。
最適合：在本地數(shù)據(jù)庫或備份中存儲敏感數(shù)據(jù)的任何應(yīng)用程序。
專業(yè)建議：確保在存儲機密信息時使用多層加密，以最大限度地提高數(shù)據(jù)安全性。
WAF是一款安全軟件，它位于您的API和互聯(lián)網(wǎng)之間，可以在惡意流量到達您的服務(wù)器之前將其過濾掉。它是防止 DDoS 攻擊和其他惡意活動的好方法。
最適合：任何面向外部流量的網(wǎng)絡(luò)應(yīng)用程序或API，例如通過公共網(wǎng)站或移動應(yīng)用程序暴露的網(wǎng)絡(luò)應(yīng)用程序或API。
專業(yè)建議：選擇一個可以根據(jù)您的特定需求輕松定制的 WAF，允許您根據(jù)系統(tǒng)內(nèi)不同的訪問點或用戶角色設(shè)置不同的安全級別。然后，確保您的 WAF 定期更新，以確保應(yīng)用最新的安全補丁，從而保證數(shù)據(jù)和應(yīng)用程序的安全。
確保在整個應(yīng)用堆棧中實施上述所有最佳實踐，不僅僅是API層。這將會確保您所有數(shù)據(jù)的全面安全性 ，無論其在何處。
API 安全的第一步是確保您的 API 按預(yù)期運行。這意味著通過 API 客戶端提交常規(guī)請求，并確保它們符合上述原則。開發(fā)能回答以下問題的方案：
一旦確定您的 API 可以正常工作，您就需要在適當?shù)臏y試環(huán)境中模擬針對系統(tǒng)的代碼注入、MITM、DoS 和密碼竊取攻擊。請在測試中注意以下幾點：
以下是您可以進行的一些具體測試。
注意：也許您沒有內(nèi)部員工來執(zhí)行這些測試。請尋找能夠提供這方面專業(yè)知識的顧問提供幫助。
如果身份驗證機制實施不當，攻擊者就會破壞身份驗證令牌，或利用實施缺陷假冒其他用戶的身份，從而訪問您的 API 端點。
若要測試身份驗證機制，請嘗試在沒有正確身份驗證的情況下發(fā)送API請求。查看API是否響應(yīng)正確的錯誤和消息。嘗試使用無憑據(jù)和不正確的憑據(jù)進行此測試。
要運行參數(shù)篡改測試，在 API 請求中嘗試各種無效查詢參數(shù)的組合，看看它是否以正確的錯誤代碼做出響應(yīng)。如果沒有，您的API可能存在一些必須解決的后臺驗證錯誤。
嘗試在 API 輸入中注入 SQL、NoSQL、LDAP、操作系統(tǒng)或其他命令。然后，看看你的 API 是否會執(zhí)行它們。這些命令應(yīng)該是無害的，比如重啟命令或 cat 命令。
大多數(shù) API 都有各種 HTTP 方法來檢索、存儲或刪除數(shù)據(jù)。有時，網(wǎng)絡(luò)服務(wù)器會默認訪問不支持的 HTTP 方法，從而使您的 API 容易受到攻擊。
要測試此漏洞，請嘗試所有標準 HTTP 方法（POST、GET、PUT、PATCH 和 DELETE）和一些不常用的方法。
例如，使用 HEAD 而不是 GET 發(fā)送 API 請求，或者使用 FOO 等任意方法發(fā)送請求。你應(yīng)該得到一個錯誤代碼。如果得到的是 200 OK 響應(yīng)，說明你的 API 存在漏洞。
模糊測試應(yīng)該是 API 安全審計流程的最后步驟之一。這類測試會將 API 推向極限，以發(fā)現(xiàn)任何尚未暴露的安全問題。
要做到這一點，請發(fā)送大量隨機請求，包括 SQL 查詢、系統(tǒng)命令、任意數(shù)字和其他非文本字符。然后，看看你的API是否會出現(xiàn)錯誤響應(yīng)、錯誤處理這些輸入或崩潰。
這類測試將模擬溢出和 DDoS 攻擊。
API管理器或網(wǎng)關(guān)工具將處理或幫助處理上述API安全準則（包括測試）。下面讓我們來詳細了解一下這些工具。
借助 API 管理平臺，您可以在一個地方確保跨環(huán)境和供應(yīng)商的所有 API 和端點的安全。您還可以通過分配預(yù)先配置的安全認證配置文件、創(chuàng)建和定制可用于保護所有 API 或單個 API 安全的策略等方式，實現(xiàn) API 安全流程的自動化。
可以說，API 管理平臺最重要的功能就是訪問控制。它們應(yīng)防止未經(jīng)授權(quán)的用戶獲得對 API 服務(wù)和數(shù)據(jù)的不當訪問權(quán)限。
為了執(zhí)行訪問控制，大多數(shù)API管理平臺至少支持以下一種或全部三種類型的安全方案：
要了解一些能幫助您保護 API 安全的流行 API 管理平臺，請查看”What Is an API Gateway & How Does It Work? [+Best Service Providers].”
這篇文章的重點是 REST API，因為目前 REST API 約占 API 的 83%，但任何 API 都存在安全漏洞的風險。這就是為什么我們將討論REST API安全性和另一種常見的API類型SOAP的安全性之間的關(guān)鍵差異。
軟件開發(fā)人員可以采用不同的架構(gòu)來構(gòu)建API 。最流行的是表示狀態(tài)傳輸（REST）和簡單對象訪問協(xié)議（SOAP）。
REST API 通過超文本傳輸協(xié)議（HTTP）傳輸數(shù)據(jù)。同時，SOAP 將數(shù)據(jù)編碼為 XML（一種用于存儲和傳輸信息的通用標記語言），并通過 HTTP 發(fā)送。
SOAP的要求比RESTful設(shè)計更嚴格，這使得這種API類型的構(gòu)建更具挑戰(zhàn)性。不過，與其他API設(shè)計相比，它往往更安全，更能保持數(shù)據(jù)的完整性。
下面讓我們來分析一下他們的不同之處。
RESTful 協(xié)議支持 SSL 以保護傳輸?shù)臄?shù)據(jù)，但缺乏內(nèi)置的安全功能，包括錯誤處理。它也不支持網(wǎng)絡(luò)服務(wù)（WS）規(guī)范，因此無法使用網(wǎng)絡(luò)服務(wù)安全等安全擴展來實現(xiàn)企業(yè)級安全。
這意味著 REST API 的安全性取決于 API 本身或 API 網(wǎng)關(guān)的設(shè)計。
與 RESTful 一樣，SOAP 協(xié)議也支持 SSL 以保護傳輸時的數(shù)據(jù)，但它更進一步。
它不僅包括 SAML 標記、XML 加密和 XML 簽名（基于 W3C 和 OASIS 建議），這些有助于保護 SOAP API 發(fā)送和接收數(shù)據(jù)的安全，而且還支持網(wǎng)絡(luò)服務(wù) (WS) 規(guī)范。
這樣，您就可以使用安全擴展，如用于企業(yè)級安全的 Web Services Security 和提供內(nèi)置錯誤處理功能的 WS-ReliableMessaging。
API 技術(shù)為在線應(yīng)用程序帶來了無數(shù)的可能性，但安全事故可能會讓您從 API 中獲得的任何好處迅速化為烏有。雖然不可能根除所有威脅，但上述原則對于任何關(guān)心其聲譽，更重要的是關(guān)心其客戶的組織來說都是必要的。
原文鏈接：https://blog.hubspot.com/website/api-security
