DevSecOps測(cè)試介紹

把Sec塞進(jìn)DevOps不只是技術(shù)與工具變更那么簡(jiǎn)單，更重要的是思維方式和內(nèi)部流程的轉(zhuǎn)變，推進(jìn)DevSecOps的關(guān)鍵原則是：別給人添麻煩。

《Gartner 2017研究報(bào)告：DevSecOps應(yīng)當(dāng)做好的十件事》和《Gartner 2019研究報(bào)告：DevSecOps應(yīng)當(dāng)做好的十二件事》兩篇研究報(bào)告中都對(duì)成功實(shí)施DevSecOps進(jìn)行了研究。兩篇報(bào)告一致認(rèn)為實(shí)施DevSecOps的關(guān)鍵挑戰(zhàn)和第一要素是：“安全測(cè)試工具和安全控制過(guò)程能夠很好的適應(yīng)開(kāi)發(fā)人員，而不是背道而馳”。安全團(tuán)隊(duì)想要將安全測(cè)試或安全控制成功的融入在DevOps中的前提是：

不要試圖改變程序員和測(cè)試人員的工作方法，也不要去增加他們額外的工作負(fù)擔(dān)。

否則你將破壞DevOps的協(xié)作性和敏捷性，注定會(huì)成為眾矢之的，最終無(wú)法落地。由于破壞DevOps的協(xié)作性和敏捷性而失敗的慘痛案例筆者身邊就有好幾個(gè)。

應(yīng)用安全測(cè)試在CI/CD軟件開(kāi)發(fā)周期中的集成點(diǎn)

WEB應(yīng)用安全測(cè)試目前在市場(chǎng)上有眾多的解決方案，其中最老牌、應(yīng)用最為廣泛的應(yīng)屬SAST和DAST這兩類的測(cè)試工具，通過(guò)在源代碼 (SAST) 或公開(kāi)對(duì)外接口 (DAST) 上運(yùn)行安全掃描，可以在應(yīng)用上線之前識(shí)別并糾正許多漏洞。

然而隨著 DevSecOps 被廣泛接納，Gartner 在 2017 年的研究報(bào)告中明確提倡用 Interactive Application Security Testing (IAST) 替換 SAST 和 DAST，原文如下：

考慮交互式應(yīng)用安全測(cè)試 (IAST) 替代傳統(tǒng)的靜態(tài)應(yīng)用安全測(cè)試（SAST）和動(dòng)態(tài)應(yīng)用安全測(cè)試 (DAST) 是可行的，我們建議這么做。IAST 是在DAST基礎(chǔ)上的一種改進(jìn)形式，測(cè)試過(guò)程更加可視化，包括內(nèi)部和外部的。IAST 綜合了 DAST 和 SAST 的優(yōu)勢(shì)，在確保測(cè)試代碼覆蓋率的基礎(chǔ)上盡可能的做到了減少誤報(bào)。

接下來(lái)筆者分析一下 Gartner 為何如此推崇在 DevSecOps 中采用 IAST 來(lái)替換 SAST 和 DAST。

1、SAST 因效率差、誤報(bào)率高無(wú)法敏捷的融入到 DevOps 中

首先我們對(duì) SAST 實(shí)現(xiàn)原理進(jìn)行簡(jiǎn)單分析，SAST 一般實(shí)現(xiàn)都是在不運(yùn)行代碼的情況下通過(guò)詞法分析、語(yǔ)法分析、控制流、數(shù)據(jù)流分析等技術(shù)對(duì)源代碼進(jìn)行掃描，并利用復(fù)雜的檢查規(guī)則匹配發(fā)現(xiàn)與定位缺陷，最后生成結(jié)果。

雖然 SAST 目前可以集成到開(kāi)發(fā)者IDE環(huán)境并融入到 DevOps 中，但 SAST 往往需要比較長(zhǎng)的掃描分析時(shí)間，實(shí)時(shí)性比較差，同時(shí)誤報(bào)率也比較高，需要投入大量的安全團(tuán)隊(duì)的資源來(lái)去除這些誤報(bào)。

除此之外，SAST 針對(duì)應(yīng)用程序引用的第三方開(kāi)源組件、開(kāi)源框架也無(wú)法有效識(shí)別已知存在安全風(fēng)險(xiǎn)。

總之，SAST 實(shí)際應(yīng)用在 DevSecOps 環(huán)境中并不輕松，除非你擁有非常充裕并且經(jīng)驗(yàn)豐富的安全團(tuán)隊(duì)對(duì)其進(jìn)行不斷的優(yōu)化、開(kāi)發(fā)與維護(hù)。

2、DAST因適應(yīng)場(chǎng)景有限及嚴(yán)重影響正常業(yè)務(wù)功能測(cè)試而無(wú)法融入到DevOps中

DAST 是目前應(yīng)用最為廣泛的 WEB 應(yīng)用安全測(cè)試工具，市面上有些廠商把 DAST 經(jīng)過(guò)改造偷換概念自稱 IAST。IAST 產(chǎn)品魚龍混雜，筆者身邊就有因?yàn)檫x用了此類產(chǎn)品導(dǎo)致無(wú)法無(wú)縫融入 DevOps 的情況，為大家避免再次踩坑本文會(huì)花較大篇幅用于討論 DAST 相關(guān)技術(shù)。

DAST 的原理相對(duì)比較簡(jiǎn)單，一般分為以下幾個(gè)階段：首先 DAST 利用爬蟲技術(shù)獲取盡可能全的應(yīng)用URL后進(jìn)行去重，然后分析和提取外部可能的輸入點(diǎn)；其次針對(duì)每個(gè)URL中的輸入點(diǎn)替換成不同漏洞類型的 Payload，實(shí)質(zhì)上是篡改原始數(shù)據(jù)報(bào)文輪番地毯式向WEB應(yīng)用重放 HTTP/HTTPS 報(bào)文，最終 DAST 收到WEB應(yīng)用的響應(yīng)報(bào)文對(duì)其分析來(lái)判斷漏洞是否存在。

由于爬蟲技術(shù)的天生缺陷，DAST 面臨著諸多的挑戰(zhàn)。首當(dāng)其沖的是爬蟲無(wú)法爬取應(yīng)用完整 URL 的問(wèn)題。如：當(dāng)應(yīng)用具有 AJAX、Token、驗(yàn)證碼、獨(dú)立 API 等情況，或者應(yīng)用執(zhí)行必須依賴上步執(zhí)行結(jié)果邏輯的場(chǎng)景，比如在面對(duì)密碼重置、交易支付等場(chǎng)景應(yīng)用時(shí)均無(wú)法進(jìn)行有效的覆蓋。為了解決 DAST 爬蟲技術(shù)的缺陷開(kāi)始對(duì)其進(jìn)行改造，通常將 WEB/APP 客戶端訪問(wèn)應(yīng)用時(shí)的流量進(jìn)行代理，方法有通過(guò)瀏覽器配置代理、*** 流量代理等方式。對(duì)于非加密環(huán)境還可以通過(guò)交換機(jī)流量鏡像、應(yīng)用訪問(wèn)日志導(dǎo)入、在應(yīng)用服務(wù)器上部署客戶端獲取流量等幾種彌補(bǔ)方案，通過(guò)以上補(bǔ)救方案后 DAST 就可以規(guī)避一些爬蟲技術(shù)的缺陷。

分析完 DAST 爬蟲缺陷我們?cè)賮?lái)分析查找輸入點(diǎn)和 Payload 替換階段的缺陷。

如今在互聯(lián)網(wǎng)上的交易類 WEB/APP 應(yīng)用為了保證數(shù)據(jù)的保密性和完整性必須在傳輸過(guò)程中對(duì)數(shù)據(jù)采用加密、加簽的方法，然而這對(duì) DAST 這類安全測(cè)試工具幾乎是毀滅性打擊。

根本原因在于 DAST 無(wú)法得知其測(cè)試應(yīng)用所采用的加密算法與密鑰，不能還原成明文，只看到一堆亂碼密文無(wú)從獲取有效的輸入點(diǎn)，替換 Payload 就更無(wú)從談起了。對(duì)于應(yīng)用只有加簽的場(chǎng)景對(duì)于 DAST 來(lái)說(shuō)即使獲取了有效的輸入點(diǎn)，篡改原始報(bào)文替換 Payload 重放數(shù)據(jù)報(bào)文也不會(huì)被應(yīng)用接受或處理。

那么假設(shè) DAST 在面對(duì)沒(méi)有采用加密、加簽等場(chǎng)景的 WEB 應(yīng)用時(shí)，是否可以無(wú)縫融入 DevOps 實(shí)現(xiàn) DevSecOps 測(cè)試階段的自動(dòng)化安全測(cè)試呢？各位看官,且聽(tīng)我慢慢道來(lái)。

首先我們假設(shè) DAST 已經(jīng)通過(guò)了良好的改造不再利用 DAST 爬蟲技術(shù)來(lái)獲取WEB應(yīng)用的 URL（改良后有些廠商自稱IAST~_~，且稱之為偽 IAST），而是通過(guò)各種流量收集方式解決了獲取應(yīng)用 URL 的問(wèn)題。那么接著 DAST 開(kāi)始進(jìn)入篡改原始報(bào)文，將輸入點(diǎn)的值替換成 Payload，并重放數(shù)據(jù)報(bào)文的過(guò)程，然而 DAST 不能提前預(yù)知 URL 的輸入點(diǎn)會(huì)存在什么類型的安全漏洞因此只能將所有不同漏洞類型的 Payload 全數(shù)依次替換后重放數(shù)據(jù)報(bào)文。

這會(huì)造成什么后果？服務(wù)器流量被放大 20 倍，加資源勉強(qiáng)解決了，但掃描速度變得巨慢，我等也敢怒不敢言。因重放數(shù)據(jù)導(dǎo)致重復(fù)提交數(shù)據(jù)，使得自動(dòng)化功能測(cè)試失敗（產(chǎn)生了臟數(shù)據(jù)、功能異常等問(wèn)題），測(cè)試小姐姐跳腳了，這下忍無(wú)可忍了。情急之下靈光一現(xiàn)：采用延時(shí)檢測(cè)或定時(shí)計(jì)劃?rùn)z測(cè)功能，把漏洞檢測(cè)時(shí)間放在小姐姐測(cè)試結(jié)束后進(jìn)行，不就 OK 了？！于是，嘴角一上揚(yáng)微微一笑開(kāi)始配置晚上 12 點(diǎn)后開(kāi)始檢測(cè)。

第二天早上迫不及待登錄 DAST（偽IAST）系統(tǒng)查看掃描結(jié)果，顯示屏和大腦一片空白，漏洞呢？原來(lái)應(yīng)用系統(tǒng)登錄會(huì)話超時(shí)、有些功能需要一次性Token，有些需要短信驗(yàn)證，有些接口只能特定的IP才能訪問(wèn)，有些需要回答一個(gè)隨機(jī)問(wèn)題后才能進(jìn)入下個(gè)階段……，這些都無(wú)解?。。?！

看形式只能使出必殺技，劍走偏鋒。喊上研發(fā)部門開(kāi)會(huì)，為能使 DAST（偽IAST）正常工作，提出讓研發(fā)同步維護(hù)兩個(gè)版本，除正常功能外還需要再增加一個(gè)版本。這個(gè)版本要求不能有加密、會(huì)話不過(guò)期、沒(méi)有驗(yàn)證碼、沒(méi)有一次性 Token、沒(méi)有簽名、沒(méi)有……話還沒(méi)說(shuō)完研發(fā)老大拍案而起怒懟：老子 996 為了趕項(xiàng)目進(jìn)度，你 MMP 還要來(lái)添堵，想讓我們 120 嗎？

最終結(jié)局可想而知，領(lǐng)導(dǎo)叫停 DAST（偽IAST）在功能測(cè)試階段的應(yīng)用，美好的安全測(cè)試向左移，安全無(wú)縫融入到 DevOps，DevSecOps 測(cè)試階段的自動(dòng)化安全測(cè)試夢(mèng)想就這樣被破滅了。當(dāng)然并不能說(shuō) DAST（偽IAST）一無(wú)是處，DAST（偽IAST）只是不太適用在DevSecOps測(cè)試階段的自動(dòng)化安全測(cè)試或一些加密、加簽的一些復(fù)雜應(yīng)用而已。

3、被動(dòng)型IAST是DevSecOps測(cè)試階段實(shí)現(xiàn)自動(dòng)化安全測(cè)試的最佳工具

首先讓我們來(lái)看一下Gartner對(duì)IAST的定義：

交互式應(yīng)用程序安全測(cè)試（IAST）結(jié)合了靜態(tài)應(yīng)用程序安全測(cè)試（SAST）和動(dòng)態(tài)應(yīng)用程序安全測(cè)試（DAST）技術(shù)。這旨在通過(guò)SAST和DAST技術(shù)的交互，提高應(yīng)用程序安全測(cè)試的準(zhǔn)確性。IAST 將 SAST 和 DAST 中優(yōu)勢(shì)部分集成到了一個(gè)解決方案中。這種方法可以非常容易確認(rèn)漏洞是否真實(shí)存在，并確定其在應(yīng)用程序代碼中的漏洞代碼位置。

看到這里大家終于明白為什么說(shuō)改良后的DAST是偽IAST了吧。根據(jù)Gartner的定義，IAST需要結(jié)合SAST和DAST兩者的技術(shù)優(yōu)勢(shì)，最終檢測(cè)出的漏洞詳情應(yīng)非常容易確認(rèn)是否真實(shí)存在，同時(shí)需要定位到存在安全風(fēng)險(xiǎn)的代碼位置。

IAST 漏洞詳情中都會(huì)包括漏洞形成的應(yīng)用內(nèi)部數(shù)據(jù)流的詳細(xì)傳播過(guò)程，以及漏洞存在的代碼位置，這都是為了能讓安全人員更方便的確認(rèn)漏洞的真實(shí)性，讓開(kāi)發(fā)人員更容易理解漏洞的形成原因，同時(shí)使得開(kāi)發(fā)人員自主的去修復(fù)漏洞更加容易。

目前市面上 IAST 根據(jù)實(shí)現(xiàn)原理不同可以兩類，主動(dòng)型 IAST 和被動(dòng)型 IAST。這兩類工具的共同點(diǎn)是對(duì)應(yīng)用開(kāi)發(fā)語(yǔ)言關(guān)聯(lián)性非常緊密，均需要部署 Agent。Agent 會(huì)將可能引起安全風(fēng)險(xiǎn)的底層函數(shù)進(jìn)行 hook。

主動(dòng)型 IAST 結(jié)合了 DAST 的功能，篡改原始報(bào)文替換 Payload 進(jìn)行數(shù)據(jù)報(bào)文重放，并在底層函數(shù) hook 點(diǎn)實(shí)時(shí)監(jiān)聽(tīng)，當(dāng)監(jiān)聽(tīng)到 Payload 進(jìn)入函數(shù) hook 點(diǎn)則判斷漏洞存在。

主動(dòng)型IAST的優(yōu)勢(shì)是幾乎不存在誤報(bào)，檢測(cè)速度快于 DAST，但和 DAST一樣沒(méi)有辦法適用于有加密、加簽、一次性 Token 等復(fù)雜應(yīng)用場(chǎng)景，同時(shí)還存在產(chǎn)生臟數(shù)據(jù)、破壞功能測(cè)試結(jié)果等問(wèn)題。因此主動(dòng)型 IAST 也不能無(wú)縫融入到 DevOps，實(shí)現(xiàn) DevSecOps 測(cè)試階段自動(dòng)化安全測(cè)試。

最后來(lái)看看被動(dòng)型 IAST，被動(dòng)型 IAST 在漏洞檢測(cè)過(guò)程中始終保護(hù)靜默監(jiān)聽(tīng)，不會(huì)主動(dòng)去重放報(bào)文。被動(dòng)型 IAST 可以比 SAST、DAST 檢測(cè)更多的通用漏洞，因?yàn)?Agent 可以查看應(yīng)用的所有代碼、應(yīng)用程序運(yùn)行時(shí)控制流、應(yīng)用程序數(shù)據(jù)流信息、環(huán)境配置信息、HTTP 請(qǐng)求和響應(yīng)、使用的框架和其他組件、后端連接信息、數(shù)據(jù)庫(kù)連接等等。那么被動(dòng)型 IAST 是如何檢測(cè)漏洞的呢？

被動(dòng)型 IAST 判斷漏洞的主要原理實(shí)際上也并不復(fù)雜：被動(dòng)型 IAST 認(rèn)為外部傳入的輸入?yún)?shù)在沒(méi)有經(jīng)過(guò)安全過(guò)濾的前提下，又傳播到了一個(gè)可能引起安全漏洞的風(fēng)險(xiǎn)函數(shù)，則會(huì)判定為漏洞存在，當(dāng)然在實(shí)際商用產(chǎn)品中會(huì)加入很多其他邏輯。

原理

被動(dòng)型IAST并不關(guān)心也不需要關(guān)心應(yīng)用外部傳入的輸入?yún)?shù)是否加密，天然支持具有加密傳輸?shù)膱?chǎng)景。

其次我們可以看到：被動(dòng)型 IAST 檢測(cè)過(guò)程不需要重放數(shù)據(jù)報(bào)文，也就天然支持具有加簽、一次性Token、短信驗(yàn)證、生物驗(yàn)證等等復(fù)雜應(yīng)用場(chǎng)景，同時(shí)不會(huì)影響正常的業(yè)務(wù)功能測(cè)試。

被動(dòng)型 IAST 另外一個(gè)特色是檢測(cè)效率奇高，精準(zhǔn)實(shí)時(shí)的漏洞檢測(cè)，可與功能操作同步完成安全測(cè)試。

最后，被動(dòng)型 IAST 不僅可以解決應(yīng)用通用漏洞檢測(cè)問(wèn)題，還能對(duì)應(yīng)用引入的開(kāi)源組件進(jìn)行風(fēng)險(xiǎn)管理，這一點(diǎn)對(duì)應(yīng)用開(kāi)發(fā)安全來(lái)說(shuō)也特別的重要。

當(dāng)然 IAST 并非沒(méi)有缺陷，IAST 主要問(wèn)題在于不同語(yǔ)言開(kāi)發(fā)的 WEB 應(yīng)用需要有不同類型的 Agent，特別是研發(fā)被動(dòng)型 IAST 技術(shù)難度和投入都非常巨大，這也是為什么被動(dòng)型 IAST 商用產(chǎn)品寥寥無(wú)幾的重要原因。

另外 IAST 沒(méi)有爬蟲技術(shù)也不主動(dòng)重放數(shù)據(jù)報(bào)文，因此無(wú)法檢測(cè)沒(méi)有安裝 Agent 的 WEB 應(yīng)用，對(duì)于需要進(jìn)行遠(yuǎn)程漏洞掃描的場(chǎng)景 IAST 無(wú)法適用。

總結(jié)一下

被動(dòng)型 IAST 可以適用于任何加密、加簽、一次性資源等復(fù)雜場(chǎng)景的應(yīng)用，同時(shí)檢測(cè)過(guò)程安全無(wú)危害，是 DevSecOps 測(cè)試階段實(shí)現(xiàn)自動(dòng)化安全測(cè)試的最佳工具。

最后讓我們回顧一下Gartner報(bào)告中對(duì)DevSecOps的概述：

將安全性集成到 DevOps 中以交付 DevSecOps 需要改變思維方式，流程和技術(shù)。安全和風(fēng)險(xiǎn)管理領(lǐng)導(dǎo)者必須堅(jiān)持 DevOps 的協(xié)作、敏捷性，以便安全測(cè)試在開(kāi)發(fā)中實(shí)現(xiàn)無(wú)縫集成，從而使DevSecOps中的 ‘安全’ 透明。

所以在實(shí)際推進(jìn)DevSecOps時(shí)應(yīng)始終堅(jiān)持“協(xié)作、敏捷、透明”，另外并不只是技術(shù)與工具變更，更重要的是思維方式和內(nèi)部流程的轉(zhuǎn)變才能真正達(dá)到預(yù)期。