Service Mesh 和 API Gateway 關(guān)系深度探討
今天，令人印象深刻的是有 64% 的企業(yè)正在創(chuàng)建用于內(nèi)部或外部用例的 API。雖然有四分之一的受訪者現(xiàn)在根本沒有創(chuàng)建 API，但 40% 的受訪者都利用了內(nèi)部和外部用例中的 API。
目前，大多數(shù)利用 API 的企業(yè)都依賴他們的開發(fā)人員來編寫和管理這些 API。盡管 33% 的受訪者使用專門的技術(shù)來管理他們的 API，但 90% 的受訪者依靠他們的開發(fā)團(tuán)隊(duì)或外部資源從零開始編寫 API。
越來越多的新云應(yīng)用程序之間的集成編碼工作已經(jīng)讓企業(yè)不堪重負(fù)，因此企業(yè)對開發(fā)人員提出了更高的要求，要求他們?yōu)槠髽I(yè)創(chuàng)建和管理 API。
在設(shè)計(jì)、測試和部署 REST API 的任何時(shí)候，安全問題都是必須考慮的一個(gè)重要方面。隨著 REST API 的飛速發(fā)展，在設(shè)計(jì)和開發(fā) API 的過程中，安全級別往往被低估。如今，敏感數(shù)據(jù)（無論是組織信息還是個(gè)人信息）的安全性是困擾開發(fā)人員的一個(gè)重要因素。REST API 也不例外，它是重要系統(tǒng)的一部分，需要防范安全威脅和漏洞。
根據(jù) 2018 年 Postman 社區(qū)報(bào)告調(diào)查，與前一年相比，越來越多的開發(fā)人員開始關(guān)注 REST API 的安全性，并對其抱有更高的信心：
在本篇文章中，我將介紹當(dāng)今 IT 世界中的 7 大 REST API 安全威脅，以引起大家的注意，并幫助大家了解能夠影響 REST API 性能的安全威脅。
REST 框架中的分層轉(zhuǎn)換序列意味著鏈中的一個(gè)薄弱環(huán)節(jié)就可能會使我們的應(yīng)用程序變脆弱。
在注入攻擊中，危險(xiǎn)代碼被嵌入到一個(gè)不安全的軟件程序中，以發(fā)起攻擊，其中最著名的是 SQL 注入和跨站點(diǎn)腳本攻擊。實(shí)際上，這種暴露可以通過將不受信任的數(shù)據(jù)作為查詢或命令的一部分傳輸?shù)?API 中來操作。該輸入隨后由解釋器實(shí)現(xiàn)，這可能會導(dǎo)致攻擊者獲取未經(jīng)授權(quán)的信息訪問權(quán)限或造成其他損害。
阻止或拒絕注入攻擊最有效方法是添加輸入驗(yàn)證，以下是幾個(gè)最重要的準(zhǔn)則：
驗(yàn)證輸入：長度、范圍、格式及類型通過在 API 參數(shù)中使用強(qiáng)類型（如數(shù)字、布爾值、日期、時(shí)間或固定數(shù)據(jù)范圍）來實(shí)現(xiàn)隱式輸入?yún)?shù)校驗(yàn)用正則表達(dá)式約束字符串的輸入定義適當(dāng)?shù)恼埱蟠笮∠拗撇⑹褂?HTTP 響應(yīng)狀態(tài) 413（請求實(shí)體太大）來拒絕超過該限制的請求
在拒絕服務(wù)（DoS）攻擊中，攻擊者在大多數(shù)情況下會推送大量消息，請求服務(wù)器或網(wǎng)絡(luò)建立由無效返回地址組成的請求。如果沒有采取適當(dāng)?shù)陌踩婪洞胧@種攻擊能夠使 RESTful API 處于無法運(yùn)行的狀態(tài)。最近，無論 API 是否公開，其他人（包括攻擊者）都可以訪問它。
隨著這些 API DoS 攻擊變得變得越來越普遍，并且隨著組織越來越多地依賴 API 來滿足其業(yè)務(wù)需求，安全專業(yè)人員應(yīng)該開始積極計(jì)劃應(yīng)對此類攻擊。即使禁用用于應(yīng)用程序身份驗(yàn)證的 API 密鑰（或訪問令牌），也可以通過標(biāo)準(zhǔn)瀏覽器請求輕松地重新獲取密鑰。
因此，使當(dāng)前訪問令牌失效不是一個(gè)長期的解決方案。如果 DoS 攻擊可以追溯到某個(gè)特定的 IP 地址，那么將該 IP 地址列入黑名單也不是長久之計(jì)，因?yàn)楣粽呖梢院苋菀椎孬@取一個(gè)新的 IP 地址。
這就是為什么需要多種訪問控制方法的原因。對于非敏感信息，使用 API 密鑰可能就足夠了。然而，為更好地防止 DoS 攻擊，需要使用 HTTPS 和更健壯的身份驗(yàn)證機(jī)制，包括 OAuth 、相互（雙向）TLS（傳輸層安全性）身份驗(yàn)證或 SAML （安全斷言標(biāo)記語言）令牌。
為防止可能會導(dǎo)致 DDoS 攻擊或其他 API 服務(wù)濫用的大量 API 請求，請?jiān)诮o定時(shí)間間隔內(nèi)對每個(gè) API 的請求數(shù)量施加限制（也稱為峰值阻止）。當(dāng)超過此速率時(shí)，至少暫時(shí)阻止來自該 API 密鑰的訪問，并返回 429（請求過多）HTTP 錯(cuò)誤碼。
如果我們開始構(gòu)建新的 REST API 了，請先檢查下 Web 服務(wù)是否具有一些面向安全性的特性。
這些特殊的問題可能使攻擊者繞過或控制 Web 程序使用的身份驗(yàn)證方法。身份驗(yàn)證丟失或不足可能會導(dǎo)致攻擊，從而破壞 JSON Web 令牌、API 密鑰、密碼等。
攻擊的目的通常是控制多個(gè)帳戶，更不用說攻擊者獲得與被攻擊用戶同等的權(quán)限。只有經(jīng)過身份驗(yàn)證的用戶才可以訪問這些 API。
使用 OpenID/OAuth 令牌、PKI 和 API 密鑰可以很好地滿足 API 授權(quán)和身份驗(yàn)證需求。最好不要通過未經(jīng)綁定的連接發(fā)送憑據(jù)，也不要在 Web URL 中顯示會話 ID。
由于在傳輸中或靜態(tài)時(shí)缺乏加密而導(dǎo)致的敏感數(shù)據(jù)暴露可能會導(dǎo)致攻擊。當(dāng)應(yīng)用程序無法正確保護(hù)敏感數(shù)據(jù)時(shí)，就會發(fā)生敏感數(shù)據(jù)泄漏。這些信息可能是私人健康信息、信用卡信息、會話令牌、密碼等，而且包含越多的信息越容易受到攻擊。敏感數(shù)據(jù)需要很高的安全性，除了在與瀏覽器進(jìn)行交換時(shí)采取非常規(guī)的安全做法外，還包括靜態(tài)或傳輸中的加密。
為了避免敏感數(shù)據(jù)泄露，必須使用 SSL。
今天，我們可以通過 Let’s Encrypt 得到一個(gè)免費(fèi)證書。SSL 和 TLS 在消除基本 API 漏洞方面經(jīng)驗(yàn)豐富，幾乎不費(fèi)吹灰之力。
要想獲得一份有關(guān)實(shí)施效果的出色報(bào)告，請使用 Qualys SSL 服務(wù)測試，測試你的 URL。這是我們的測試結(jié)果：
訪問控制，在某些情況下稱為授權(quán)，是一個(gè) Web 軟件允許某些人而不是所有人訪問它的功能和內(nèi)容的方式。缺少訪問控制或訪問控制不足可能會使攻擊者可以控制其他用戶賬戶、變更訪問權(quán)限、變更數(shù)據(jù)等。
當(dāng)開發(fā)人員未能正確地配置操作級的可訪問性時(shí)，公司應(yīng)用程序訪問就容易受到攻擊，從而導(dǎo)致訪問漏洞。拒絕訪問是破壞訪問控制的最常見后果，而利用訪問控制是攻擊者的主要手段。
由于某些框架中缺少訪問控制，因此可以通過手動或自動化的方式來檢測訪問控制。如果在可靠的無服務(wù)器或服務(wù)器端 API 中實(shí)現(xiàn)了訪問控制，則訪問控制通常是有效的，因?yàn)楣粽邔o法更改訪問控制元數(shù)據(jù)。
這是一種基于操作客戶端和服務(wù)器之間交換的參數(shù)來修改應(yīng)用程序數(shù)據(jù)（例如，用戶憑據(jù)和權(quán)限、產(chǎn)品價(jià)格和數(shù)量等）的攻擊。通常，這些信息存儲在 cookie、隱藏表單字段或 URL 查詢字符串中，用于增強(qiáng)應(yīng)用程序的功能和控制。
當(dāng)有害的網(wǎng)站、程序、即時(shí)消息、博客或電子郵件使用戶的 Internet 瀏覽器在授權(quán)的網(wǎng)站上執(zhí)行不必要的操作時(shí)，就會發(fā)生這種情況。它允許攻擊者在被攻擊用戶不知情的情況下，使用目標(biāo)的 Web 瀏覽器使目標(biāo)系統(tǒng)執(zhí)行某個(gè)功能，直到未經(jīng)授權(quán)的事務(wù)被執(zhí)行為止。
攻擊能否成功取決于完整性和邏輯驗(yàn)證機(jī)制的錯(cuò)誤，利用該機(jī)制可能還會導(dǎo)致其他攻擊，包括 XSS、SQL 注入、文件包含和路徑泄漏等攻擊。
我們應(yīng)該仔細(xì)地校驗(yàn)接收到的 URL 參數(shù)，以確保該數(shù)據(jù)能代表來自用戶的有效請求。無效請求可用于直接攻擊 API 或攻擊 API 背后的應(yīng)用程序和系統(tǒng)。將校驗(yàn)器放在應(yīng)用程序上，并嘗試對發(fā)送到 REST API 的請求使用 API 簽名。還可以為 API 創(chuàng)建自動化安全測試，以確保沒有參數(shù)篡改來影響我們的 REST API。
它是指攻擊者秘密地更改、攔截或中繼兩個(gè)交互系統(tǒng)之間的通信，并攔截它們之間傳遞的私有和機(jī)密數(shù)據(jù)。MITM 攻擊分為兩個(gè)階段：攔截和解密。
API 中缺少傳輸層安全性（Transport Layer Security，TLS）實(shí)際上等同于向黑客發(fā)出公開邀請。傳輸層加密是安全 API 中最基本的“必備條件”之一。除非使用 TLS，否則遭受普遍存在的“中間人”攻擊的風(fēng)險(xiǎn)仍然很高。在 API 中同時(shí)使用 SSL 和 TLS 很有必要，尤其是要使用公開 API時(shí)。
在開發(fā) REST API 時(shí)，必須從一開始就注意安全性。可以考慮使用內(nèi)置了許多安全特性的現(xiàn)有 API 框架。在 Rest Case 中，我們使用的是 SugoiJS API 框架，除測試和安全指導(dǎo)之外，我們還為其代碼庫做出了貢獻(xiàn)。通過這種方式，安全性被統(tǒng)一地內(nèi)置，并且開發(fā)人員可以更專注于應(yīng)用程序的邏輯。
在這之后，不要忘記分配資源來測試 API 的安全性。一定要測試本文中所提到的所有安全威脅。
原文鏈接：Top 7 REST API Security Threats
如何快速建立自己的專屬AI大模型？.png)
角度探討-API-設(shè)計(jì).png)
該從靜態(tài)-API-令牌遷移到-OAuth-2.0.png)
微信截圖_17267303945266.png)