【翻譯】使用OpenAPI規範進行安全的API設計

API安全性是網絡安全的重中之重。諸如雲原生應用程序,無服務器,微服務,單頁面應用程序以及移動和物聯網設備等新興趨勢和技術已致使API的激增。應用程序組件再也不是在單個進程中在一臺機器上彼此通訊的內部對象,而是經過網絡相互通訊的API。
這顯着增長了攻擊面。此外,經過發現和攻擊後端API,攻擊者一般能夠繞過前端控件,直接訪問敏感數據和關鍵內部組件。這致使了API攻擊的激增。每週,新聞中都會報道新的API漏洞。OWASP如今有專門針對API的十大漏洞的單獨列表。而Gartner估計,到2022,API都將成爲頭號攻擊向量。
爲了解決這個問題,公司愈來愈多地轉向積極安全 模式。他們定義了預期的API行爲,確保定義足夠嚴格和詳細,以使其有意義,測試實現以符合該定義,而後在使用API期間強制執行該定義。API預期範圍以外的任何調用以及API預期返回範圍以外的任何響應都將被自動拒絕。

與傳統應用程序不一樣,API實際上具備一種在標準的機器可讀模型中定義其預期輸入和輸出的方法。具體來講,對於當今最流行的API類型(REST API),此合同格式爲OpenAPI。它最初是爲文檔目的而建立的Swagger標準,後來被Linux基金會下的OpenAPI Initiative採納。當今市場上的大多數開發和API工具要麼本機使用OpenAPI,要麼以該格式支持導入和導出。
讓咱們看一下OpenAPI規範的特定部分及其在安全性中的做用。
注意: 咱們將在此處的示例中使用YAML格式和OpenAPI版本3,可是JSON與該格式同樣好,而且能夠在版本2(也稱爲Swagger)中找到相似的方式來指定API行爲。前端

路徑

API路徑是API定義中最基本的部分。它們與服務器URL和基本路徑一塊兒,記錄了API客戶端應調用的URL:

在OpenAPI規範中,路徑是必填的。完整記錄服務器公開的全部API和API路徑可防止攻擊者發起路徑遍歷攻擊或查找影子端點:暫存,非生產性和舊式端點。數據庫

有效載荷

請求和響應均可能在正文中包含數據。REST API一般使用JSON做爲交換數據的格式。儘管不是強制性的,但仍是強烈建議您嚴格描述此類請求和響應的模式:

咱們還應該將有效負載的類型明確指定爲對象,並將其additionalProperties值設置爲false。這些阻止將其餘屬性插入到調用中。
這些額外的步驟可防止攻擊者將其得到的全部屬性盲目地保存到數據庫,並沒有意中覆蓋敏感字段時,進行批量分配攻擊。最近,流行的容器註冊表系統Harbor發生了這種API漏洞,攻擊者能夠經過在API調用中僅包含」has_admin_role」:true來更改本身的我的資料詳細信息,從而使本身成爲管理員。後端

認證與受權

身份驗證很重要,OpenAPI能夠定義您的API應該具備的安全方案(基本,承載,API密鑰,OAuth2,OpenID Connect等):

而後將其應用於任何級別(整個API或僅特定操做):

您也能夠在上面的示例中看到,該標準本機支持範圍。
不用說,身份驗證和受權對於API安全性極爲重要。如此多的API被黑客入侵的緣由是: 它們原本是「內部的」,而且開發人員從未想到攻擊者會找到進入網絡並調用它們的方法。身份驗證的設計沒有遵循安全規範。安全

傳輸

在這個時代,應該始終加密流量並使用HTTPS而不是HTTP。
HTTP的使用會使得網站容易受到中間人攻擊,在這種中間人攻擊中,流量將被攔截,而且攻擊者冒充合法的API使用者。服務器

工具

咱們將在這裏簡要介紹的另外一個方面是工具支持。本文並非對工具的評論,所以咱們僅提供一些指導。您能夠自行選擇如Eolinker安全網關或者其餘的安全工具使用。
API安全規範只有在實際使用它的狀況下才有用,而且根據生命週期的階段,其用法也有所不一樣。

API防火牆和API網關能夠基於合同(在外部(南北)和內部(東西方)級別)實施「積極安全性」,以下圖所示:
網絡

結論

本文整理了大部分可能會出現的API攻擊方式,可是也請意識到,OpenAPI仍然是一個不斷髮展的標準,而且它對API安全性的覆蓋也在不斷髮展。
幸運的是,OpenAPI容許您使用本身的自定義對象和屬性對其進行擴展。您能夠本身執行此操做,也可使用您選擇的API安全網關或API管理工具提供的自定義擴展名進行操做。隨着API攻擊的增長,確保您受到保護的最有效方法是使用「積極安全性」模型,在整個API生命週期中使用定義明確,通過測試和強制執行的規範。
翻譯:Eolinker——國內3萬+企業在用的API管理和網關工具
微服務

相關文章
相關標籤/搜索