交互式應用安全測試（Interactive application security testing IAST）

一、IAST介紹 

交互式應用安全測試（Interactive application security testing IAST）是一個在應用和API中自動化識別和診斷軟件漏洞的技術。如果從名字的縮寫來看，插樁（Instrumented）式應用安全測試或許是一個更好的說法。IAST不是一個掃描器，IAST持續地從內部監控你應用中的漏洞，在整個開發生命週期中，IAST通過你在開發和測試中使用的工具（比如說DAST、漏洞掃描等），實時地提供報警。

IAST最顯著的特性是它使用插樁來收集安全信息，直接從運行中的代碼發現代碼風險問題（代碼漏洞、不規範的編碼方式等），不是源代碼掃描（SAST），也不是HTTP 掃描(DAST)。但那並不意味着你要等到產品上線時才使用它，恰恰相反，你可在IDE中，當開始編寫和測試第一行代碼時，就使用IAST。

瞭解IAST在完整的應用安全技術策略中的位置非常重要，有兩個主要自動化應用安全的方法，你都要考慮到：

1. 在開發時阻止漏洞。IAST自動地發現應用和API的漏洞，這樣可以在開發過程早期就進行修復，成本不會那麼高。IAST在檢測速度，精確度，流程上都比傳統的SAST和DAST有優勢，某些IAST還包括開源軟件安全分析功能。
2. 在生產階段檢測攻擊和阻止漏洞利用。RASP在運行時阻止漏洞被利用，而不是像Web 應用防火牆（WAF）那樣通過檢查網絡流量來阻止攻擊。RASP並不僅在精確度和擴展性上優於傳統的Web防護方法，還能適配各種業務系統架構（因爲其注入單元是最小的進程單元）（注：RASP也使用插樁的方法，和IAST所使用的底層技術基本一樣，區別僅在於RASP更關注運行時的0Day防護，IAST除了具備漏洞攔截能力之外更關注漏洞源頭的溯源和定位）

IAST技術在2010年出現，許多最大的金融、技術和醫療保健公司已經採用了IAST技術。在本文中，我們將探索如何把IAST集成到整個軟件生命週期中，實現最經濟的漏洞檢測。

參考鏈接：

https://www.youtube.com/watch?v=J5XV41Lt2RQ
https://www.contrastsecurity.com/glossary/interactive-application-security-testing
https://www.contrastsecurity.com/search-results?term=IAST&type=BLOG_POST&type=LISTING_PAGE

 

二、我們爲什麼需要IAST

問題很簡單，我們在應用安全方面，有大量的問題。但應對這些問題的安全專家有限，全世界幾乎有2000萬的開發人員。傳統的工具要求安全專家和應用一起工作（安全深度介入開發過程），訓練工具，解釋結果。這些工具80%的費用是有效使用工具的“人的費用“，沒有真正的自動化。

痛點一：工具困境

“工具困境”是指你爲工作準備的工具都不是很好用，因此，你不得不運行一系列工具，希望能得到一個好的結果。

在安全領域十餘年來，業內一直在嘗試這種“混合”的方法，但確實沒什麼作用。想像一下，使用SAST，DAST，還有SCA工具的結果去檢測CSRF漏洞的情形：

• 靜態分析：靜態分析工具僅僅能嘗試檢測沒有被token檢查保護的數據流，不管他們是狀態變更還是通過XHR訪問。結果或者是花費大量時間的誤報，或者是危險的漏報。
• 動態分析：DAST工具能夠標記不包含CSRF令牌的表單，但無法知道是否他們在狀態變更，因此，結果結果或者是花費大量時間的誤報，或者是危險的漏報。
• 開源軟件分析：SCA工具只能標記含有已知漏洞的庫，將會錯失所有沒有被安全專家暴露和發佈的安全漏洞。

運行所有這些工具，浪費時間和寶貴的安全技能。但更重要的是，很難關聯安全測試結果。靜態工具能夠報告源代碼行數，動態工具報告HTTP請求，開源工具報告庫版本號，沒有好的方法來關聯這些報告。最好的關聯工具減少15%-35%發現結果。因此，如果你有兩個工具，每份報告了200個發現結果（對於靜態工具，一個保守的估計），你會得到縮減後的340個結果。總之，僅僅合併噪音和不精確的報告是不經濟的。

痛點二：傳統的應用安全工具和現代軟件不兼容

現代軟件開發速度更快，正在加速發展。許多項目按周、天，甚至小時的頻率來部署代碼。不幸的是，像SAST、DAST、模糊測試、人工滲透測試、人工代碼檢查無法跟上現代軟件的速度和規模。

綜合來看，傳統應用安全工具的最大挑戰，IAST都可以具備比較好的解決方案：

• 精確性：傳統工具的最大問題是精確度。SAST和DAST產生大量的誤報（不是真實的漏洞）和漏報（錯失真正的漏洞）。工具不精確的時候，安全專家必須執行手動步驟來解決問題，這個流程耗費大量時間，導致軟件開發的很大瓶頸。相比傳統工具，IAST有一個巨大的信息優勢，精確度的提高意味着開發人員能夠直接使用結果，不需要安全專家介入，從而大幅度加快流程。
• 兼容適配性：現代應用中大量使用到API封裝，同時基於複雜的框架進行二次開發，程序從從複雜的路由和數據結構中解析出結果（如XML，JSON，序列化對象）。在缺少大量的規則定製的情況喜愛，SAST無法跟蹤這些路徑，DAST無法模擬測試要求的複雜流量，IAST對這些問題具有很好的免疫力，因爲它只觀察運行時的複雜應用和API。
• 速度：現代軟件方法，像敏捷和DevOps，進展得非常快。目標是在開發者和上線之間完全自動化。然而傳統的工具花費許多小時去執行一個完全的分析（甚至不考慮使用專家分診，去除誤報）。當一個開發人員在他們的IDE環境中編譯和測試代碼時，IAST提供及時的反饋。IAST還能和QA一起運行測試，如果發現安全問題，能夠馬上停止編譯。
• 擴展性：安全工具必須能夠使用多個規則，持續分析應用的整個組成。傳統的掃描按順序運行，無法擴展到整個企業。IAST是一個針對應用安全，完全分佈式和持續的方法，意味你所有的應用和API能夠被持續並行訪問，因此你的安全也就能一直保持在最新的狀態。
• 流程兼容：IAST位於已經存在的開發工具和流程的頂端，不需要額外的步驟。做正常開發和測試時，IAST在後臺運行，因爲IAST非常精確，能在不瞭解漏洞的情況下發現它們，不需要專家，任何人都可以使用IAST做安全測試，生成乾淨的代碼。

 

三、IAST的概念邊界及其技術棧

交互式應用安全測試使用軟件插樁收集安全信息，並直接從運行中的代碼發現問題，以實現自動化識別和診斷在應用和API中的軟件漏洞。

1. 運行時代碼級別的上下文感知能力。IAST可以訪問代碼本身（能夠在每行代碼執行SAST），而且IAST可以訪問HTTP流量（能夠在每一次請求和響應時，執行類DAST的分析）。因此，IAST的規則是SAST和DAST的一個功能合集。
2. 業務代碼安全測試。IAST能夠自動化地分析應用和API中的自有業務代碼，找出以前沒有發現的0Day漏洞，能夠識別很寬範圍的漏洞，包括並不限於OWASP Top 10，還有其他更復雜的漏洞。
3. 開源軟件安全測試。IAST也能用來測試開源庫和框架的安全性。首先，IAST能識別困擾開源軟件的已知漏洞（如CVE發佈），其次，IAST能識別開源軟件中以前未知的（潛在）漏洞。
4. 風險數據泄露鏈路追蹤。IAST利用其API和應用拓樸追蹤能力，可以從敏感數據泄露現場，反向追溯出沿途的應用和API鏈路拓樸，最終定位到某一行業務代碼中。本質上說，風險數據泄露也屬於一種特殊的漏洞，和反序列化/代碼執行這類漏洞的區別僅在於觸發點和風險行爲模式不同。

除了在獨立場景中發揮作用之外，在實際的應用安全體系建設中，IAST可以和其他工具和防護手段有效配合。下圖顯示IAST在NIST的Cybersecurity Framework中的位置，IAST完全集中在應用安全這一行，除了檢測和識別漏洞，某些IAST實施能幫助識別和分析應用。 

使用基於插樁的方法來提供安全能力並不限於應用層。安全專家已經認識到，我們可以不再只從外部來檢測漏洞，外部的視角並不能提供足夠的上下文信息精準地識別漏洞，從內部做漏洞檢測更容易更精確。這種基於插樁（和基於掃描的安全測試對比）的安全測試趨勢，正在從網絡嚮應用全棧中擴展。

下表詳細介紹了現代網絡應用程序堆棧的各層及其基於插樁的安全解決方案。

LAYER	INSTRUMENTATION	EXAMPLE PRODUCTS	TESTING
Application	IAST	Contrast Seeker	Tests the security of applications and APIs by instrumenting software
Container	Container Security	Twistlock Aqua Anchore Sysdig	Tests the container security by instrumenting the container
Operating System	Endpoint	Carbon > Black ThreatStack Tanium	Tests operating system security by instrumenting the OS
Network	Network Security	ZScaler Tenable	Tests network security by instrumenting the network stack.

如您所見，IAST是一種針對應用程序層的基於插樁的安全方法，許多針對其他堆棧層的安全產品也認識到了基於插樁方法的優勢。在所有層面上，直接訪問比從外部角度測試安全性具有巨大優勢。

由於IAST將安全性直接構建到軟件堆棧中，應用程序可以安全地部署在任何環境中，包括雲、PAAS、VM和數據中心。

參考鏈接：

https://dzone.com/refcardz/introduction-to-iast

 

四、IAST的工作原理

IAST探針如何工作

通常，IAST使用類似APM工具的技術，使用安全探針對插樁的應用和API進行調試排錯，探針從運行的應用中直接檢查安全相關的事件，並傳遞給分析引擎，引擎重新組裝這些事件，識別出代碼執行中的漏洞特徵。

當一個應用或者API被加載到內存中，應用中的插樁是動態執行的。插樁本身很安全，並被廣泛應用到日誌、性能測試、及其他目的。許多常見的框架已經在運行時使用隱藏的插樁技術，很可能你已經在應用和API中使用過某種形式的插樁。

現代應用常常在運行時組裝，使用依賴注入、動態加載、反向控制等其他技術。因爲這個原因，源代碼分析只能提供一個局部觀察，驗證安全最好的方法是直接檢查運行時應用，IAST支持這種直接的檢測。

IAST安全探針能夠從應用中實際地提取任何信息。在許多方面，IAST是SAST和DAST的一個合集，包括代碼和HTTP流量的分析，但IAST在它的分析中考慮到更多類型的信息，包括：

• 代碼。IAST能訪問所有和應用一起部署的源代碼和二進制代碼。代碼探針對應用中每一行代碼做二進制的靜態分析，包括庫和框架。
• HTTP流量。IAST能夠看到HTTP請求和響應，使用和DAST非常類似的技術，發現和這些流量相關的漏洞。
• 庫和框架。IAST能看到部署的每一個庫和框架，分析應用和API如何使用它們。不僅IAST能夠根據已知漏洞（CVE）來評估庫，也能識別部分或整體隱藏在庫裏面的未知漏洞。重要的是，因爲IAST能精確知道庫裏面的哪一部分被應用真正調用，它能夠過濾掉從未被調用的和庫相關的漏洞。
• 應用程序狀態（敏感參數檢查）。IAST能夠檢查程序執行時的應用狀態。例如，IAST能看到調用安全方法時使用的參數來發現弱點，如傳遞“DES”參數給加密密碼構造函數。
• 污點數據流追蹤。從開始進入應用的時候開始，IAST就追蹤不信任的輸入數據。這是識別最重要的漏洞種類（注入類漏洞、指令注入類漏洞）的關鍵。這個技術，有時稱之爲“污點追蹤”，跟蹤真實數據在應用中的流動，非常精確。
• 敏感控制流監控。IAST瞭解應用的控制流，能夠識別出應用行爲中漏洞的特徵。例如如果一個應用要求在每個web服務中，採用service()方法檢查訪問控制，這個特徵將很容易被IAST發現。要實現這個需求，往往需要產品支持自定義規則配置，用戶可根據企業自身的實際業務情況配置針對性的敏感類/方法規則。
• 後端連接檢查。IAST能夠檢查圍繞着後端連接的所有細節，如數據庫、操作系統調用、目錄、隊列、套接字、電子郵件和其他系統。IAST使用這個信息識別出架構缺陷、安全缺陷、以及應用/API拓樸信息。
• 配置檢查。IAST能訪問應用、框架、應用服務器、和平臺的配置，保證正確的安全配置。IAST甚至能查詢應用組件的運行時配置，如XML解析器。（注：某些平臺，如.NET，重度依賴配置來實現安全）

IAST常常使用多個不同的信息源來證實一個漏洞，例如，當一個暴露的端點，是non-XHR，或者狀態正在改變，或者沒有包含token檢查，就可以確定是一個CSRF（跨站請求僞造）漏洞。IAST能夠訪問HTTP請求，分析是否一個交易修改了文件或寫到存儲設備裏，評估是否一個控制流包含一個token檢查。通過在漏洞分析中，使用所有這三種類型的數據，IAST得出準確的結果，不會漏報也不會誤報。

 

五、IAST場景化解決方案

對企業組織，IAST是一個能夠橫跨整個應用和API組件集，建立持續安全測試的有效方法。使用IAST，組織能在所有的應用組件中，持續並行地執行應用安全測試。

場景一：保護企業的應用組件集

許多組織僅僅測試應用組件集中的一小部分，一些組織只測試重要的應用，其他組織的策略是測試所有面向外部的應用。更可能的是，你主要的網站沒有受到攻擊，而是合作伙伴的網站、一個複雜的移動API、或內網的業務應用受到攻擊。這就是爲什麼保護所有應用和API，甚至非webAPI的重要性。

對許多外部和麪向公共的應用，許多組織保留安全測試。事實上內部應用和外部應用的概念，取決於工作安全邊界。不幸的是，由防火牆和其他網絡安全設備建立起來的邊界，已經變得千瘡百孔，意義不大。例如，一臺員工工作站，被攻擊者變成內部的跳板，邊界變得無關緊要，企業需要測試你的整個應用組件集，包括內部應用。

場景二：在CI/CD管道中的IAST

記住，IAST不像一個掃描器，IAST有效地變成了應用的一部分，它能在應用運行的任何地方運行，包括開發人員的IDE，本地測試服務器，QA機器等。作爲CI/CD構建的一部分，IAST可以運行在容器中，在雲中，你代碼運行的任何地方。在整個軟件生命週期中，你軟件運行的任何地方，你都可以使用IAST。

下圖描述了一個簡單開發管道，使用IAST持續的發現漏洞。

• 使用IAST，確保開發人員提交”清潔”的代碼

在開發中，我們的目標是賦能開發人員發現和修復他們自己的漏洞，提交清潔的代碼。但我們必須避免拖累他們或給出誤報結果，避免浪費研發人員的時間。

開發人員使用IAST，在開發環境中，當生成和測試代碼時，實時地做安全分析。開發人員必須要做的是把IAST代理增加到本地的服務器環境中，一旦IAST安裝好了，開發人員可以做日常的工作和測試，自動或者手動，不用再做一次安全測試。開發人員通過他們使用的安全工具，如Eclipse，IDEA，VisualStudio，Slack，Hipchat，Chrome，JIRA，VSTS等，實時地收到安全漏洞通知。同時IAST可以提供精確的代碼行，完整的HTTP請求，完整的數據和控制流，開發者的工作變得容易，他們能夠修復代碼，使用相同HTTP請求來再測試，驗證問題是否解決，最後提交清潔代碼。

• 在部署前，使用IAST提供強大保證

IAST也可以用在QA、測試、CI/CD階段，保證開發階段沒有漏洞。

不管是用來做自動化測試的測試服務器，還是CI/CD構建流程的一部分，只要把IAST代理添加到用來做QA的服務器中就可以實現目的。對於完全組裝的應用，在QA中使用IAST是一個有效的最後檢查手段，因爲它會被配置和部署。

同時，IAST可以配置成自動化生成缺陷跟蹤ticker，或停止軟件構建。

• 使用IAST保證API安全

傳統的靜態和動態工具不擅長測試API安全，這些工具無法處理複雜協議（JSON，XML，二進制，或其他payload），或者架構中用來構建API的複雜數據流和控制流。

大多數API使用軟件框架，包含自動化payload解析，對象映射（object mapping，註釋等手段把數據發送到合適的方法。因爲IAST從API內部收集安全信息，和常見web應用工作方式一樣，能夠很容易識別API漏洞。

• 易於集成和安裝 

另一方面，IAST安裝的過程非常簡單，一個典型的IAST方案通常包括兩部分，

• IAST代理
• IAST控制檯

第一步是在你的環境中增加IAST代理，方法和增加一個庫一樣只需要設置環境變量即可，當你使用應用時，IAST代理自動在後臺做安全測試，重要的是，你不需要攻擊應用就可以得到安全測試結果。IAST能被任何人使用，甚至剛開始做開發工作的新人。

IAST控制檯讓你管理整個應用組件集的安全，並行地處理和管理安全策略，配置安全控制，和其他常見開發工具集成，實現漏洞通知等。

場景三：在生產環境部署IAST提高對傳統應用的持續保證

在生產環境做安全測試並不是一個很好的主意。理想情況下，你應該在上線之前很久就修復任何安全問題。然而，常常有許多不再主動開發的傳統應用，同時還有一些只存在於生產環境的第三方產品，我們仍然需要持續保證這些應用沒有漏洞。我們也希望知道，是否有新的漏洞會影響這些應用。

雖然沒有開發和測試環境中使用的這麼普遍，IAST也能有效的使用在生產環境。因爲IAST不要求源代碼。能夠在任何可以安裝IAST代理的應用中使用，但也要考慮到IAST的性能問題。雖然速度很快，在開發和測試環境中沒有被注意到，在生產中，即使幾微秒也無法接受。

場景四：使用IAST測試開源軟件中已知漏洞

雖然開源軟件漏洞常常看起來像洪水猛獸，但事實也許比看到的更嚴重。目前有幾百萬個開源庫，但只有有限的安全專家在測試他們。

IAST根據CVE庫，能自動地分析開源軟件漏洞。因爲IAST能持續運行並行地遍歷整個應用的組件，可以在幾分鐘內檢測新引入庫中的增量問題，而傳統的開源軟件掃描器需要重新掃描整個企業。

除此之外，IAST能精確地告訴你，在開源軟件庫中到底調用了哪些代碼，以及具體在哪些地方被調用。據統計，平均72%的庫只包含在應用程序的編譯依賴中，從來沒有被應用程序真正調用。IAST能節省您升級不真正帶來風險的庫的工作。

場景五：使用IAST來持續審計和合規

IAST工具支持很寬範圍的安全標準，包括：

• PCI DSS
• HIPPA
• NIST 800-53
• OWASP Top 10
• OWASP ASVS
• DISA AppSec STIG

IAST工具能生成報告，證明應用被完全安全測試過，沒有漏洞被發現。因爲這些報告任何時候都能生成，能顯著的加快審計和合規流程。

場景六：使用IAST加強安全編碼指南

IAST不僅支持漏洞規則，同時也支持代碼編碼規範相關的規則，它可以加強你組織自身的安全編碼指南。你可以生成“正向”的規則，如“每個API必須調用AccessController.isAuthorized()方法來授權“。IAST能加強這些規則，給與開發人員即時反饋，告訴開發人員組織是如何實現安全的。

隨着時間推移，組織能使用這個能力，從負面的“阻止漏洞模型”向正向的“使用企業安全控制”模型轉變。

場景七：使用IAST提升企業向DevOps轉型速度

軟件開發項目向DevOps轉變過程中，構建和測試軟件的流程加速了，使得SAST和DAST越來越難以使用。IAST格外適合DevOps，因爲它賦能開發者得到及時和精準的反饋，不要求任何額外的流程步驟就可以發現和修復他們自己的安全漏洞。這就最小化了安全工作對開發的影響，明顯減少了下游的安全工作。

使用IAST，你和以往一樣構建、測試、部署代碼，唯一的區別是IAST在後臺運行，確保你不會引入任何危險的代碼或庫漏洞。

如上圖所示，IAST擴展性好，非常容易的在幾百上千個應用上，並行地持續執行應用安全測試。 

參考鏈接：

https://dzone.com/refcardz/introduction-to-iast

 

六、評估IAST解決方案時的考量因素

相關部門

在IAST解決方案選型的過程中，你要考慮多個不同的部門：

• 安全部門。安全部門很顯然在漏洞管理中扮演着一個重要的角色。在整個組織的應用和API組件中，IAST是一個主要的漏洞提供者，應用得好，IAST能夠幫助開發在早期消除大多數漏洞，不需要安全部門的介入。
• 開發團隊。開發團隊有很大的責任，保證應用和API沒有漏洞。開發團隊經常有使用安全工具的噩夢經歷，也許會懷疑IAST能力，因此關鍵是確保他們理解IAST的優點，得到他們的支持。
• DevOps。DevOps團隊一個重要的工作是推動軟件快速上線。這和靜態及動態掃描都不兼容，因爲他們要花費很長時間來掃描，要求大量工作去消除誤報。IAST能幫助DevOps團隊把自己的安全做好，提供完全自動化的方法，在安全上很自信地推動代碼上線。
• 管理團隊。對應用安全的自信能夠幫助管理層做出數字化轉型的決定，向DevOps轉移，或向雲上轉移，同時保證IAST作爲被企業內所有人認可的應用安全測試技術，能幫助業務轉型。

技術考慮

• 語言支持。不同的廠商支持不同的語言，因此你要保證IAST支持你重要的應用和API正在使用的語言。
• 框架支持。應用框架和語言同樣重要，除非IAST支持你正在使用的框架，否則在檢測漏洞方面不會有效。
• 精確度。你會想使用一個包含一系列真實漏洞的應用，來評估精確度。仔細測試IAST的識別能力，沒有誤報。使用OWASP Benchmark看到操作詳情，來衡量應用安全測試工具的好壞。
• 擴展性。考慮到應用組件集的數量，包括API，內部應用和產品。是否IAST能夠擴展到持續分析所有的應用？達到這個水平需要多少人來支持。
• 規則集覆蓋。尋找一個寬泛的規則集，覆蓋你關心的攻擊。包括CVE。
• 可見性。IAST有它自己的儀表盤嗎？或僅僅是依賴缺陷跟蹤系統。輸出什麼樣的報警，通知、報告？有IDE和CI/CD插件支持嗎？
• 安裝。大多數IAST產品安裝簡單，不要求流程變更。安全可以自動化嗎，是否可以被增加到容器和鏡像裏面，可以自動地支持新的應用？
• 配置。是否IAST要求複雜的配置，來實現精確的分析？常見的安全控制和規則是否容易地添加到IAST裏面？
• 管理和更新。是否有統一管理的方法更新IAST規則和功能？軟件更新是自動化的嗎？IAST包含企業級特性，如LDAP集成、強認證、企業級訪問控制、數據傳輸和保存加密、完整的安全日誌等？
• 集成。IAST提供插件，能夠和常見的安全及DevOps工具及管道集成嗎？對收集到的數據有完整的API嗎？這個API也包含管理員操作的功能嗎？

IAST能夠快速評估，因爲在一個非常短的時間內，你就會知道它是否能在你的應用上工作。你可以只在幾個應用上部署IAST，運行測試，得出評估結果。