如何保護無服務器應用？

Dan Swinhoe 陳琳華

攻擊者有多種方法來攻擊無服務器應用，但是本文中的這些最佳實踐將有助于阻止這些攻擊。

無服務器應用亦稱為云函數，可執行非常具體的任務且存在時間僅為數秒鐘。這使得它們在充分利用云環境和降低成本方面更加高效。

與任何新技術一樣，這種新范式的安全隱患尚未得到充分探索或理解。PureSec的首席技術官兼聯合創始人Ory Segal稱：“許多人仍然認為無服務器是神奇的，保護代碼的安全可交由他人負責，但事實遠非如此。”不過，我們也許可以通過強化無服務器應用和使用安全最佳實踐來降低數據泄露的概率。

如何攻擊無服務器函數

當然，服務器仍然存在，但函數是抽象的且不依賴于任何一個基礎設施。事實上，服務器上有函數的源代碼，并且至少有一個托管的臨時容器正在執行函數。這意味著應該認真考慮它們的安全性。

Segal指出，“無服務器函數只是幾個簡單的代碼片段，當某個事件觸發時云提供商將執行這些代碼片段。因此與任何其他軟件一樣，它們也會遇到應用程序層漏洞。”

關于無服務器架構中最常見的安全風險的研究發現，GitHub上五分之一的無服務器應用存在嚴重的安全漏洞。不過到目前為止，還沒有關于無服務器函數遭到破壞的重大攻擊報告。盡管如此，安全研究社區卻對此非常感興趣，其中一些人認為有針對性的攻擊正在發生，只是沒有被發現而已。

Mozilla的安全工程師Andrew Krug在去年早些時候的黑帽大會上表示：“人們正在尋找無服務器函數的漏洞，特別是在開源領域，很容易就找到代碼中漏洞在哪里。”

2018年7月，PureSec在其所支持的IBM Cloud Functions產品的開源無服務器計算平臺Apache Openwhisk中發現了一個漏洞。該漏洞允許攻擊者覆蓋源代碼并更改函數邏輯。為此Apache基金會還專門發布了一個補丁。

PureSec最近還演示了一種攻擊。該攻擊利用無服務器中的自動擴展函數將單個易受攻擊的函數轉變為大規模的加密貨幣挖掘礦場。在測試中，該攻擊可使挖礦函數擴展至平臺的最大并發限制。這種攻擊可能會導致在賬期結束時出現大量費用。由于加密貨幣挖礦會導致受害者消耗額外的計算資源，該報告估算這筆費用每月多達12萬美元。

“最常見的攻擊方法是事件數據注入。在這過程中，攻擊者會注入惡意數據，然后在事件觸發期間被函數使用，”PureSec的Segal說。“此類惡意數據可能會濫用應用程序層漏洞，例如SQL注入、命令注入、本地文件包含、數據泄漏等。此類攻擊將操縱函數的業務邏輯。”

在2018年7月的倫敦OWASP AppSec大會上，Checkmarx的Shimi Eshkenazi和Amit Ashbel則演示了一種代碼注入攻擊，它可在同一應用程序中“交叉污染”函數，克服了持久性問題。在演示過程中，該團隊展示了他們能夠通過代碼注入訪問函數代碼，并下載該函數代碼，在對其進行修改后再通過原始病毒函數感染其他的函數。

Eshkenazi說：“你將會陷入無限循環的交叉感染中，而這將導致所有其他函數失控。擺脫這種情況的唯一方法是將所有函數恢復到原始來源。記住是所有函數，不能遺漏其中的任何一個。”

無服務器計算有哪些安全優勢？

盡管可能存在風險，但無服務器函數仍擁有一些安全優勢，主要在于它們是孤立的、短時的和只讀的，并且通常只有很少或是沒有特權升級。與其他類型的代碼相比，將它們做為攻擊目標具有更大的難度。與單體應用程序相比，函數通常沒有什么職責和訪問數據，因此直接破壞范圍更小。

Checkmarx的網絡安全推廣官Amit Ashbel在OWASP AppSec大會上表示：“函數在它們自己的環境中運行這一事實減少了潛在的破壞，并且由于沒有任何東西存儲在上面，所以函數在運行后會被移動、刪除和丟棄。這兩個特點也都阻止了注入的東西被存儲起來。如果你注入的東西（在函數結束后）被刪除，那么這一函數仍然是新的和干凈的。（它們）應該更加安全。”

函數由主要云提供商作為服務提供這一事實也提供了額外的安全性。雖然實際函數的編碼和配置是由用戶決定的，但是AWS和Azure之類的產品將負責確保底層硬件的安全性和補丁，同時函數本身也將定期更新，這些提供商的規模意味著拒絕服務攻擊將更加容易被應對。

與錯誤配置的S3存儲桶會導致許多重大數據泄漏事件一樣，錯誤配置的無服務器應用也可能會導致出現數據泄漏等問題。“Lambda的默認值很好。這里面的問題在于流行的無服務器框架引入的默認值，它們往往會導致IAM（身份和訪問管理）權限完全敞開，”Mozilla的Krug說。

如何保護無服務器函數

無服務器技術目前仍處于初期階段，這一特點也反映在圍繞著該技術的安全實踐當中。Serverless.com的調查發現，調試、監控和測試是無服務器應用的最大挑戰;而PureSec的調查發現，35%的企業并沒有安全指南或工具以保護無服務器代碼。在該研究中，有48%的企業對其無服務器應用的安全可見性的水平并不滿意。當一家企業擁有50多個職能部門時，這一數字會急劇上升，這表明存在大規模安全問題。

Segal指出，“傳統的應用層保護，例如Web應用防火墻和端點保護解決方案，不適用于無服務器架構，并且由于缺乏底層基礎設施或網絡/操作系統無法訪問而無法部署。目前無服務器的安全測試方法和工具仍幾乎沒有。”

盡管如此，企業還是可以遵循一些最佳實踐來改善其無服務器應用和函數的安全狀態。以下是可以遵循的五大應用安全最佳實踐：

1、在設計和開發時就考慮到安全性，并使用威脅建模來了解自己面臨的風險。執行靜態代碼分析和滲透測試以檢測漏洞。使用安全API驗證事件數據輸入。該安全API可以清理或驗證用戶輸入，并將流入的HTTP / HTTPS流量掃描至無服務器應用。

2、確保身份與訪問管理（IAM）的角色和權限被正確配置，以便函數只能被需要訪問它們的東西訪問。只授予函數提供執行任務所需的權限。如果只需要讀取函數，請確保其權限是只讀的。

3、盡可能不將敏感數據放入函數的源代碼中。確保所有數據都已加密。同時，要確保身份驗證方法是有效的，并盡可能使用FaaS提供商的東西。此外，還要進行定期評估。Checkmarx的Eshkenazi說：“如果你不在服務器上的代碼中編寫敏感數據，那就同樣不應該在無服務器代碼中編寫敏感數據，因為它們可能被泄露和受到攻擊。”

4、清楚如何正確開發無服務器應用。糟糕的自動擴展函數可能會拖累資源。Auth0的Webtask.io函數即服務平臺（FaaS）的首席架構師Tomasz Janczuk表示，平臺遭受拒絕服務攻擊的情況很常見，這些攻擊實際上通常是由用戶錯誤而導致。這些例子中包括設計效率低下的函數，這些函數會試圖分配大量內存，嘗試將大量文件寫入文件系統，或者通過無休止的循環來阻塞CPU。

5、確保對無服務器應用擁有細致入微的安全可見性和深刻的洞察力。監控非常重要，尤其是在增加函數的數量時。監視API身份驗證嘗試，對函數配置、權限或觸發器的修改行為，以及執行超時等。“無論應用程序是傳統的、容器化的，還是無服務器的，都必須不斷監控整個交付堆棧的安全性，”Synopsys的Black Duck高級技術推廣人員Tim Mackey說。“隨著應用程序被分解至以無服務器模式部署的函數中，這些應用程序的潛在攻擊面將會增加，每個函數都應被視為一個不同的可交付成果，并進行全面的安全審查。”