如何將OWASP Top 10應用到無伺服器中以增加安全性 陳峻編譯
【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】