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

無服務(wù)器模型

無服務(wù)器計(jì)算，有時(shí)也被稱為“功能即服務(wù)”(Function as a Service，F(xiàn)aaS)，它能夠讓您編寫出一些能夠獨(dú)立運(yùn)行的自包含函數(shù)。其基本模型如下：

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

FaaS架構(gòu)最大的創(chuàng)新之處在于：將一些安全責(zé)任從您的后端轉(zhuǎn)向了您對(duì)應(yīng)的FaaS平臺(tái)提供商處。你們各自的責(zé)任分工如下圖所示：

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

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

新的風(fēng)險(xiǎn)

無服務(wù)器計(jì)算模型會(huì)帶來新的風(fēng)險(xiǎn)，而傳統(tǒng)的工具并不能保證有效地處置這些風(fēng)險(xiǎn)及其擴(kuò)展。被業(yè)界常用的OWASP top 10是保護(hù)各種應(yīng)用程序的絕佳參考框架，當(dāng)然它所針對(duì)的攻擊，主要是基于運(yùn)行在服務(wù)器上的應(yīng)用程序，同時(shí)您的責(zé)任不僅限于自己的代碼，而且會(huì)包括整個(gè)運(yùn)行平臺(tái)。

各種風(fēng)險(xiǎn)總是有著相似之處。攻擊者要么試圖將惡意數(shù)據(jù)注入到您應(yīng)用程序本身的代碼里(如：SQL/數(shù)據(jù)庫注入攻擊)，要么直接將數(shù)據(jù)注入某個(gè)函數(shù)之中。而這些函數(shù)往往是被賦予了過多的權(quán)限，或是沒有實(shí)施足夠的強(qiáng)認(rèn)證。和其他類型的代碼一樣，函數(shù)的脆弱性取決于那些易攻擊的組件、不當(dāng)?shù)脑O(shè)計(jì)。

各種API、隊(duì)列中的事件、甚至是存儲(chǔ)系統(tǒng)中的事件所觸發(fā)的某些函數(shù)，都會(huì)給無服務(wù)器體系結(jié)構(gòu)增加新的風(fēng)險(xiǎn)。因此，這就會(huì)造成了：無服務(wù)器應(yīng)用程序的執(zhí)行流程不夠清晰，而攻擊面則較為復(fù)雜和多樣。同時(shí)，現(xiàn)有的安全工具尚未適應(yīng)函數(shù)的多種按需輸入的特性。各種靜態(tài)、動(dòng)態(tài)和交互式的應(yīng)用安全測(cè)試(Static/Dynamic/ Interactive Application Security Testing，SAST/DAST/IAST)，常被大家運(yùn)用在對(duì)于一些公認(rèn)的、經(jīng)典的HTTP接口的測(cè)試中。

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

作為分析安全性的一個(gè)視角，讓我們來看看如何將OWASP top 10應(yīng)用到無服務(wù)器的計(jì)算中。

1. 注入

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

2. 失效的身份認(rèn)證

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

3. 敏感數(shù)據(jù)泄漏

無服務(wù)器應(yīng)用程序也可能會(huì)暴露一些受到薄弱保護(hù)的敏感數(shù)據(jù)。因此，我們?cè)诒Ｗo(hù)無服務(wù)器應(yīng)用程序的安全性時(shí)，可能面對(duì)的一種挑戰(zhàn)是：由于需要確保敏感數(shù)據(jù)對(duì)于多種函數(shù)是可用的，因此我們必須在橫跨多個(gè)函數(shù)的情況下，共享不同的API密鑰、加密密鑰、或?qū)ν獠糠?wù)的信任憑證，而它們的安全性顯然難以得到保證。雖然，如今一些云服務(wù)供應(yīng)商能夠通過提供“密鑰庫(key vault)”系統(tǒng)，并實(shí)現(xiàn)在整個(gè)應(yīng)用程序的范圍內(nèi)共享密鑰，但是此概念尚屬新潮，且不一定能被廣大開發(fā)團(tuán)隊(duì)所理解。

4. 外部實(shí)體(XXE)

在許多無服務(wù)器應(yīng)用程序的構(gòu)建中，它們使用的是比XML更簡單的數(shù)據(jù)格式(如JSON)，因此，對(duì)于新的應(yīng)用程序而言，OWASP top 10在此的風(fēng)險(xiǎn)倒沒有那么顯著。

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

與OWASP top 10的其他項(xiàng)相比，這兩點(diǎn)威脅在無服務(wù)器計(jì)算中，比傳統(tǒng)應(yīng)用更為突出。一個(gè)典型的無服務(wù)器應(yīng)用程序，一般是由一“串”函數(shù)所構(gòu)成。某個(gè)函數(shù)的一個(gè)輸入數(shù)據(jù)，往往會(huì)與若干外部數(shù)據(jù)的存儲(chǔ)進(jìn)行交互，進(jìn)而產(chǎn)生相應(yīng)的輸出。這就是前面我們提到過的模型圖。如果我們?cè)贔aaS平臺(tái)上去構(gòu)建一個(gè)完整的應(yīng)用程序，那么它的流程圖就應(yīng)該是如下所示：

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

6. 跨站腳本

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

7. 不安全的反序列化

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

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

在這一項(xiàng)上，無服務(wù)器與傳統(tǒng)應(yīng)用的做法相同，即：只有了解您的應(yīng)用程序會(huì)依賴到哪些軟件包，才能更好地管理各種潛在的風(fēng)險(xiǎn)。

9. 不足的日志記錄和監(jiān)控

該項(xiàng)位居OWASP top 10末位的原因是因?yàn)椋何覀兺ǔ６紩?huì)構(gòu)建一套記錄系統(tǒng)，來跟蹤控制所有的代碼。隨著無服務(wù)器平臺(tái)、和云平臺(tái)的普及，您完全可以依賴云平臺(tái)本身的各種日志函數(shù)服務(wù)。當(dāng)然，目前業(yè)界尚未對(duì)云平臺(tái)(更別提無服務(wù)器了)的日志“落地”形成最佳實(shí)踐。因此，您既可以依靠云平臺(tái)所提供的日志工具，也可以自己動(dòng)手，為應(yīng)用程序構(gòu)建和定制日志記錄。當(dāng)然，無論是哪一種方式，普遍的日志分析工具都還尚未達(dá)到云感知(cloud-aware)式日志記錄的水平。

原文標(biāo)題：Serverless and the OWASP Top 10 ，作者：Matthew Gast

【51CTO譯稿，合作站點(diǎn)轉(zhuǎn)載請(qǐng)注明原文譯者和出處為51CTO.com】