一、全球面臨軟件安全危機
我們即將處於一個軟件定義一切的時代，這是 “一個最好的時代，也是一個最壞的時代”。
無論是生活中離不開的通訊、支付、娛樂、餐飲、出行，以及醫療，還是國防領域中的火箭、導彈、衛星等，都離不開軟件技術。然而，軟件技術在促進社會發展的同時，也可能因爲漏洞問題危害人們的個人隱私信息、財產安全甚至生命安全，這類案例不勝枚舉。
- 2010年，大型社交網站rockyou.com被曝存在SQL注入漏洞，黑客利用此漏洞獲取到3200萬用戶記錄（包括E-mail、姓名及明文形式的密碼）。
- 2015年，英國電話和寬帶供應商TalkTalk被一名15歲的黑客利用SQL注入漏洞進行攻擊，四百萬TalkTalk客戶的姓名、地址、出生日期、和信用卡/銀行詳細信息被黑客竊取。
- 2018年，臺灣一男子利用花旗銀行信用卡業務系統漏洞，刷卡消費達6300餘萬元（新臺幣約合人民幣1345萬元），花旗銀行已通過司法途徑，向該名客戶求償。
軟件技術的發展與應用伴隨着巨大的安全危機，解決軟件漏洞問題是軟件開發從業者和安全從業者們迫在眉睫的任務。
二、什麼是Web應用安全測試技術？
爲了發現軟件的漏洞和缺陷，確保Web應用程序在交付之前和交付之後都是安全的，就需要利用Web應用安全測試技術識別Web應用程序中架構的薄弱點和漏洞，並且必須趕在網絡黑客找到和利用它們之前。
Web應用安全測試技術經過多年的發展，目前業界常用的技術主要分爲3大類別。
DAST：動態應用程序安全測試（Dynamic Application Security Testing）技術在測試或運行階段分析應用程序的動態運行狀態。它模擬黑客行爲對應用程序進行動態攻擊，分析應用程序的反應，從而確定該Web應用是否易受攻擊。
SAST：靜態應用程序安全測試（Static Application Security Testing）技術通常在編碼階段分析應用程序的源代碼或二進制文件的語法、結構、過程、接口等來發現程序代碼存在的安全漏洞。
IAST：交互式應用程序安全測試（Interactive Application Security Testing）是2012年Gartner公司提出的一種新的應用程序安全測試方案，通過代理、VPN或者在服務端部署Agent程序，收集、監控Web應用程序運行時函數執行、數據傳輸，並與掃描器端進行實時交互，高效、準確的識別安全缺陷及漏洞，同時可準確確定漏洞所在的代碼文件、行數、函數及參數。IAST相當於是DAST和SAST結合的一種互相關聯運行時安全檢測技術。
本文主要分析這3種技術的實現原理、優劣勢對比以及應用場景。
三、DAST
DAST是一種黑盒測試技術，是目前應用最廣泛、使用最簡單的一種Web應用安全測試方法，安全工程師常用的工具如AWVS、AppScan等就是基於DAST原理的產品。
1. 實現原理
1）通過爬蟲發現整個 Web 應用結構，爬蟲會發現被測Web程序有多少個目錄，多少個頁面，頁面中有哪些參數；
2）根據爬蟲的分析結果，對發現的頁面和參數發送修改的 HTTP Request 進行攻擊嘗試（掃描規則庫）；
3）通過對於 Response 的分析驗證是否存在安全漏洞。
2. DAST優劣勢分析
DAST這種測試方法主要測試Web應用程序的功能點，測試人員無需具備編程能力，無需瞭解應用程序的內部邏輯結構，不區分測試對象的實現語言，採用攻擊特徵庫來做漏洞發現與驗證，能發現大部分的高風險問題，因此是業界Web安全測試使用非常普遍的一種安全測試方案。DAST除了可以掃描應用程序本身之外，還可以掃描發現第三方開源組件、第三方框架的漏洞。
從工作原理也可以分析出，DAST一方面需要爬蟲儘可能的把應用程序的結構爬取完整，另一方面需要對被測應用程序發送漏洞攻擊包。現在很多的應用程序含有AJAX頁面、CSRF Token頁面、驗證碼頁面、API孤鏈、POST表單請求或者是設置了防重放攻擊策略，這些頁面無法被網絡爬蟲發現，因此DAST技術無法對這些頁面進行安全測試。DAST技術對業務分支覆蓋不全，即使爬到一個表單，要提交內容，服務端對內容做判斷，是手機號碼則進入業務1，不是手機號碼進入業務2，爬蟲不可能知道這裏要填手機號碼，所以業務分支1永遠不會檢測到。
另外DAST必鬚髮送漏洞攻擊包來進行安全測試，這就需要有安全專家不斷更新漏洞掃描插件，而且這種測試方式會對業務測試造成一定的影響，安全測試的髒數據會污染業務測試的數據。
DAST的測試對象爲HTTP/HTTPS的Web應用程序，對於IOS/Android上的APP也無能爲力。
DAST發現漏洞後會定位漏洞的URL，無法定位漏洞的具體代碼行數和產生漏洞的原因，需要比較長的時間來進行漏洞定位和原因分析，這使得DAST不太適合在DevOps的開發環境中使用。
四、SAST
超過50%的安全漏洞是由錯誤的編碼產生的，開發人員一般安全開發意識和安全開發技能不足，更加關注業務功能的實現。想從源頭上治理漏洞就需要制定代碼檢測機制，SAST是一種在開發階段對源代碼進行安全測試發現安全漏洞的測試方案。
1. 實現原理
1） 首先通過調用語言的編譯器或者解釋器把前端的語言代碼（如JAVA，C/C++源代碼）轉換成一種中間代碼，將其源代碼之間的調用關係、執行環境、上下文等分析清楚。
2）語義分析：分析程序中不安全的函數，方法的使用的安全問題。
3）數據流分析：跟蹤，記錄並分析程序中的數據傳遞過程所產生的安全問題。
4）控制流分析：分析程序特定時間，狀態下執行操作指令的安全問題。
5）配置分析：分析項目配置文件中的敏感信息和配置缺失的安全問題。
6）結構分析：分析程序上下文環境，結構中的安全問題。
7）結合2）-6）的結果，匹配所有規則庫中的漏洞特徵，一旦發現漏洞就抓取出來。
8）最後形成包含詳細漏洞信息的漏洞檢測報告，包括漏洞的具體代碼行數以及漏洞修復的建議。
2. SAST優劣勢分析
SAST需要從語義上理解程序的代碼、依賴關係、配置文件。優勢是代碼具有高度可視性，能夠檢測更豐富的問題，包括漏洞及代碼規範等問題。測試對象比DAST豐富，除Web應用程序之外還能夠檢測APP的漏洞，不需要用戶界面，可通過IDE插件形式與集成開發環境（如Eclipse、IntelliJ IDEA）結合，實時檢測代碼漏洞問題，漏洞發現更及時，修復成本更低。
另一方面SAST不僅需要區分不同的開發語言（PHP、C＃、ASP、.NET、Java、Python等），還需要支持使用的Web程序框架，如果SAST工具不支持某個應用程序的開發語言和框架，那麼測試時就會遇到障礙。DAST支持測試任何語言和框架開發的HTTP/HTTPS應用程序。
傳統的SAST掃描時間很慢，如果是用SAST去掃描代碼倉庫，需要數小時甚至數天才能完成，這在日益自動化的持續集成和持續交付（CI/CD）環境中效果不佳。
還有一點是SAST的誤報，業界商業級的SAST工具誤報率普遍在30%以上，誤報會降低工具的實用性，可能需要花費更多的時間來清除誤報而不是修復漏洞。
SAST只對源代碼進行檢測，而不會分析整個應用程序，這迫使企業需要購買單獨的軟件組合分析工具（SCA），即使是SCA也只是識別公開的漏洞；開源、第三方API或框架中的未知漏洞超出了SAST和SCA的範圍。
五、IAST
IAST交互式應用安全測試技術是最近幾年比較火熱的應用安全測試新技術，曾被Gartner諮詢公司列爲網絡安全領域的Top 10技術之一。IAST融合了DAST和SAST的優勢，漏洞檢出率極高、誤報率極低，同時可以定位到API接口和代碼片段。
1. 實現原理
IAST的實現模式較多，常見的有代理模式、VPN、流量鏡像、插樁模式，本文介紹最具代表性的2種模式，代理模式和插樁模式。
代理模式，在PC端瀏覽器或者移動端APP設置代理，通過代理拿到功能測試的流量，利用功能測試流量模擬多種漏洞檢測方式對被測服務器進行安全測試。
插樁模式，插樁模式是在保證目標程序原有邏輯完整的情況下，在特定的位置插入探針，在應用程序運行時，通過探針獲取請求、代碼數據流、代碼控制流等，基於請求、代碼、數據流、控制流綜合分析判斷漏洞。插樁模式具體實現有2種模式，Active 插樁和Passive 插樁。
- 代理模式實現原理
a. 功能測試人員在瀏覽器或者APP中設置代理，將IAST設備地址填入；
b. 功能測試人員開始功能測試，測試流量經過IAST設備，IAST設備將流量複製一份，並且改造成安全測試的流量；
c. IAST設備利用改造後的流量對被測業務發起安全測試，根據返回的數據包判斷漏洞信息。
插樁需要在服務器中部署Agent，不同的語言不同的容器要不同的Agent，這對有些用戶來說是不可接受的。而代理模式不需要服務器中部署Agent，只是測試人員要配置代理，安全測試會產生一定的髒數據，漏洞的詳情無法定位到代碼片段，適合想用IAST技術又不接受在服務器中部署Agent的用戶使用。
2. Active插樁實現原理
a. 被測試服務器中安裝IAST插樁 Agent；
b. DAST Scanner發起掃描測試；
c. IAST插樁 Agent追蹤被測試應用程序在掃描期間的反應附加測試，覆蓋率和上下文，將有關信息發送給Management Server，Management Server展示安全測試結果。
Active 插樁模式需要在被測試應用程序中部署插樁 Agent，使用時需要外部掃描器去觸發這個Agent。一個組件產生惡意攻擊流量，另一個組件在被測應用程序中監測應用程序的反應，由此來進行漏洞定位和降低誤報。
Active 插樁模式更像是一種改進版的DAST技術，目前最新的AWVS、AppScan已經採用了Active 插樁模式。AWVS集成了“AcuSensor”模塊，通過在源代碼中部署傳感器來增強定期動態掃描。AcuSensor能夠在AWVS掃描期間檢查Web應用程序執行時的源代碼，在後端抓取應用程序，提供100％爬行覆蓋率，查找並測試在黑盒掃描期間未發現的隱藏輸入。AppScan則是集成了“Glass Box”服務模塊，這使得AppScan支持 Web 2.0、JavaScript 和 AJAX 框架。
Active 插樁模式解決了傳統DAST漏報和無法精確定位漏洞位置的問題，需要先做掃描，掃描觸發漏洞需要一定的時間，而且掃描會對業務測試產生影響。在雙向HTTPS加密、CSRF Token頁面、防攻擊重放等場景下Active 插樁模式依然無法進行安全測試。
3. Passive 插樁實現原理
a. 被測試服務器中安裝插樁 Agent；
b. 插樁 Agent在應用程序運行時獲取請求和代碼數據流、代碼控制流；
c. 插樁Agent將獲取的信息發送給Management Sever，Management Sever展示安全測試結果。
Passive 插樁在程序運行時監視應用並分析代碼，它不會主動對Web應用程序執行攻擊，而是純粹被動地分析檢測代碼。這實際上是一個巨大的優勢，因爲它不會影響同時運行的其他測試活動，並且只需要業務測試（手動或自動）來觸發安全測試，有測試流量過來就可以實時的進行漏洞檢測。
插樁模式的關鍵是Agent，Agent需要根據不同語言進行開發，但是功能基本相同：
- 獲取請求數據和返回數據；
- 代碼執行中的參數傳遞；
- 數據庫查詢（如ODBC）；
- 目錄查詢（如LDAP），文件系統權限；
- 監聽內存中特定的值，識別受污染的輸入；
- 第三方庫的使用;
- 對外部應用程序和服務的調用；
- 特定代碼的執行等。
2. IAST優劣勢分析
IAST代理模式的優劣勢，在上文已提到，這裏不再贅述。
IAST插樁模式的技術基於請求、代碼、數據流、控制流綜合分析判斷漏洞，漏洞測試準確性高，誤報率極低。由於IAST插樁模式可獲取更多的應用程序信息，因此發現的安全漏洞既可定位到代碼行，還可以得到完整的請求和響應信息，完整的數據流和堆棧信息，便於定位、修復和驗證安全漏洞。支持測試AJAX頁面、CSRF Token頁面、驗證碼頁面、API孤鏈、POST表單請求等環境。
IAST插樁模式在完成應用程序功能測試的同時即可以實時完成安全測試，且不會受軟件複雜度的影響，適用於各種複雜度的軟件產品。不但可以檢測應用程序本身的安全弱點，還可以檢測應用程序中依賴的第三方軟件的版本信息和包含的公開漏洞。整個過程無需安全專家介入，無需額外安全測試時間投入，不會對現有開發流程造成任何影響，符合敏捷開發和DevOps模式下軟件產品快速迭代、快速交付的要求。
IAST插樁模式的核心技術在於探針，探針需要根據不同的語言進行開發，它只能在具有虛擬運行時環境的語言上執行，例如Java，C＃，Python和NodeJS。它不支持C，C ++和Golang等語言。其次，由於agent與真實webserver集成，穩定性非常重要，每次更新需要重啓webserver，部署成本較大。業務邏輯漏洞也是IAST插樁模式無法解決的問題。
六、三種技術的應用場景分析
上文分析了DAST、SAST、IAST三種技術的具體實現原理和各自的優劣勢，技術本身沒有優劣之分，不同的技術能夠解決不同場景下的問題，需要安全工程師能夠因地制宜地選擇對應的技術解決對應的問題。
DAST技術比較適合用於線上運行環境的監控，研發階段代碼檢測適合使用SAST技術，QA階段適合使用IAST技術。
七、實際應用
筆者所在的安全廠商已實現上述三大應用安全測試技術的創新性落地。
軟件開發階段，與程序員對話的源碼安全審計主要基於SAST技術打造， SAST工具對用戶的困擾主要來自於誤報，通過數據流調用分析、變量關聯分析、機器學習等多重手段極大地降低了誤報率，減少工具對安全測試工作的困擾，改善用戶體驗，降低工具的使用成本。
軟件測試階段，基於IAST技術打造，支持代理、VPN、流量信使、流量鏡像、爬蟲、導入日誌、Passive插樁共7種流量收集模式，真正結合了DAST、SAST、IAST三種技術的優勢；漏洞檢測率極高，包括水平越權、垂直越權等標準IAST技術無法檢測的邏輯漏洞，誤報率幾乎爲0；漏洞詳情直接定位請求、數據流、代碼片段，修復漏洞更容易；採用Passive 插樁技術，無需重放請求，不會形成髒數據，可覆蓋加密、防重放、簽名等任意場景；近實時檢測漏洞，漏洞檢測隨着應用程序運行實時進行。
應用上線運營階段，採用DAST技術打造資產風險監控系統，在大量企業客戶中被用來對線上業務環境進行監控。從攻擊者視角對企業進行資產探測，全面發現企業的資產暴露面和應用程序的漏洞，保障線上運營環境的安全；並且，部署模式緊跟業務的使用模式，支持在互聯網環境、企業IDC、私有云、公有云、混合雲等多種場景下部署使用。