【51CTO.com快譯】引言：本文和您討論如何將OWASP Top 10應用到無服務器的應用程序中，以降低風險、并增加安全性。

無服務器模型

無服務器計算，有時也被稱為“功能即服務”(Function as a Service，FaaS)，它能夠讓您編寫出一些能夠獨立運行的自包含函數。其基本模型如下：

也就是說，您的函數(Function)接收到一些輸入后，根據各種輸入、存儲、以及獲取到的狀態進行計算，然后產生相應的輸出。當然，普通的代碼也能如此運作，那么它們的新穎之處又體現在哪里呢?

FaaS架構最大的創新之處在于：將一些安全責任從您的后端轉向了您對應的FaaS平臺提供商處。你們各自的責任分工如下圖所示：

藍色部分是您應用程序的“轄區”，而黃色部分則屬于FaaS平臺。這顯然起到了極大的減負效果，即您只需編寫某個函數，而由他人來負責剩下的繁瑣工作，包括：找到運行它的各種服務器;保持這些服務器的更新;當服務器被攻擊時，執行清理;當負載過高時自動增加服務器;判斷一臺服務器上能夠運行多少個函數;按需重新分配負載;為各個函數及其支持的所有服務之間構建通信網絡。

當然，這種轉變也會帶來安全之上的繁瑣，即：您現在必須重點關注、并保護您自己的程序代碼。也就是說，由于不同的開發人員可以將某個函數與其他函數相關聯，而那些未經嚴格“消毒”的輸入數據很可能就來自于某些攻擊者，因此您的各種函數需要有一定的自保能力。而事實上，向無服務器應用程序提供的輸入數據會更加廣泛。除了那些定義良好的函數鏈之外，您可能還需要應對REST over HTTP、不同類型的消息隊列、和每一次發布所引入的可擴展協議。

新的風險

無服務器計算模型會帶來新的風險，而傳統的工具并不能保證有效地處置這些風險及其擴展。被業界常用的OWASP top 10是保護各種應用程序的絕佳參考框架，當然它所針對的攻擊，主要是基于運行在服務器上的應用程序，同時您的責任不僅限于自己的代碼，而且會包括整個運行平臺。

各種風險總是有著相似之處。攻擊者要么試圖將惡意數據注入到您應用程序本身的代碼里(如：SQL/數據庫注入攻擊)，要么直接將數據注入某個函數之中。而這些函數往往是被賦予了過多的權限，或是沒有實施足夠的強認證。和其他類型的代碼一樣，函數的脆弱性取決于那些易攻擊的組件、不當的設計。

各種API、隊列中的事件、甚至是存儲系統中的事件所觸發的某些函數，都會給無服務器體系結構增加新的風險。因此，這就會造成了：無服務器應用程序的執行流程不夠清晰，而攻擊面則較為復雜和多樣。同時，現有的安全工具尚未適應函數的多種按需輸入的特性。各種靜態、動態和交互式的應用安全測試(Static/Dynamic/ Interactive Application Security Testing，SAST/DAST/IAST)，常被大家運用在對于一些公認的、經典的HTTP接口的測試中。

其實，當各種事件能夠相互觸發、和調用彼此的各種無服務器函數時，使用分析工具來對每一種處理流程進行安全分析變成了所謂的NP-hard難題(譯者注：非確定性多項式的數論難題，如著名的推銷員旅行問題)。

作為分析安全性的一個視角，讓我們來看看如何將OWASP top 10應用到無服務器的計算中。

1. 注入

通常，攻擊者會向應用程序發送不可信的數據，通過在無服務器架構里運行，并過于頻繁地調用其函數，以達到對應用程序的攻擊效果。從概念上說，雖然使用API​​網關能夠明確地處置對于某個函數的請求，但是無服務器平臺卻能允許存儲事件(如：新建、或修改某些文件、或數據庫的字段)、或消息隊列去直接啟動它們所請求的函數。可見，由于任何一種事件的觸發，都可能包含攻擊者的輸入代碼，因此，注入攻擊是無服務器計算的一個首要安全問題。

2. 失效的身份認證

根據前面提到的漏洞，認證失效在無服務器函數中的“曝光率”則更高。傳統應用程序的認證授權機制，通常能夠作用到整個應用之中。例如：在應用程序中的所有函數，都統一使用一個令牌。即使是在微服務的環境中，我們也能通過統一的認證架構來對應用程序、及其所有函數進行控制訪問。而當微服務被進一步分解成為具有更多函數模塊的納服務(nanoservice)時，它們就有了自己的一套訪問控制機制。因此，當用戶經由多個服務、去訪問某個API端點、并寫入存儲的時候，該訪問鏈上的每個環節，都會需要具有自己的認證機制。

3. 敏感數據泄漏

無服務器應用程序也可能會暴露一些受到薄弱保護的敏感數據。因此，我們在保護無服務器應用程序的安全性時，可能面對的一種挑戰是：由于需要確保敏感數據對于多種函數是可用的，因此我們必須在橫跨多個函數的情況下，共享不同的API密鑰、加密密鑰、或對外部服務的信任憑證，而它們的安全性顯然難以得到保證。雖然，如今一些云服務供應商能夠通過提供“密鑰庫(key vault)”系統，并實現在整個應用程序的范圍內共享密鑰，但是此概念尚屬新潮，且不一定能被廣大開發團隊所理解。

4. 外部實體(XXE)

在許多無服務器應用程序的構建中，它們使用的是比XML更簡單的數據格式(如JSON)，因此，對于新的應用程序而言，OWASP top 10在此的風險倒沒有那么顯著。

5. 失效的訪問控制 和 6 安全配置錯誤

與OWASP top 10的其他項相比，這兩點威脅在無服務器計算中，比傳統應用更為突出。一個典型的無服務器應用程序，一般是由一“串”函數所構成。某個函數的一個輸入數據，往往會與若干外部數據的存儲進行交互，進而產生相應的輸出。這就是前面我們提到過的模型圖。如果我們在FaaS平臺上去構建一個完整的應用程序，那么它的流程圖就應該是如下所示：

可見，由于每一種函數與所有的服務之間都存在著交互關系，因此要想根據安全部署的原則，正確地為每一個方面配置出函數，是非常困難的!幾年前，Rapid7(譯者注：全球領先的安全風險信息解決方案提供商)曾發文聲稱他們發現了近2000個開放的S3 buckets，而且每個都可能包含有某個函數鏈的輸出(請參見：https://blog.rapid7.com/2013/03/27/open-s3-buckets/)。這就意味著攻擊者可以潛入到某個函數之中，獲取其輸出數據。顯然，您需要通過限制每個函數的使用權限，并配置為最低權限，以完成各種復雜的任務。

6. 跨站腳本

由于普通攻擊者的目標仍然是那些最終用戶、和他們的瀏覽器，因此就算是建立在無服務器的平臺上，那些基于Web的應用程序仍然可能遭受到XSS攻擊(請參見https://blog.tcell.io/2017/08/why-is-cross-site-scripting-so-hard)。因此，我們在無服務器上的部署、實施應用程序時，不可擅自修改、或未經測試地予以發布，以免帶來XSS攻擊的隱患。

7. 不安全的反序列化

和XXE(外部實體)攻擊類似，反序列化攻擊是通過在有效載荷中嵌入代碼，以實施攻擊。由于無服務器的函數可以按照任意順序被調用，而且我們也無法“消毒”用戶的輸入，因此我們應當在無服務器的應用中，采取更加廣泛的數據“消毒”方式，畢竟任何函數都無法信任它的任意輸入。

8. 使用含有已知漏洞的組件

在這一項上，無服務器與傳統應用的做法相同，即：只有了解您的應用程序會依賴到哪些軟件包，才能更好地管理各種潛在的風險。

9. 不足的日志記錄和監控

該項位居OWASP top 10末位的原因是因為：我們通常都會構建一套記錄系統，來跟蹤控制所有的代碼。隨著無服務器平臺、和云平臺的普及，您完全可以依賴云平臺本身的各種日志函數服務。當然，目前業界尚未對云平臺(更別提無服務器了)的日志“落地”形成最佳實踐。因此，您既可以依靠云平臺所提供的日志工具，也可以自己動手，為應用程序構建和定制日志記錄。當然，無論是哪一種方式，普遍的日志分析工具都還尚未達到云感知(cloud-aware)式日志記錄的水平。

原文標題：Serverless and the OWASP Top 10 ，作者：Matthew Gast

【51CTO譯稿，合作站點轉載請注明原文譯者和出處為51CTO.com】