AppScan，即 AppScan standard edition。其安裝在 Windows 操做系統上，能夠對網站等 Web 應用進行自動化的應用安全掃描和測試。
Rational AppScan（簡稱 AppScan）實際上是一個產品家族，包括衆多的應用安全掃描產品，從開發階段的源代碼掃描的 AppScan source edition，到針對 Web 應用進行快速掃描的 AppScan standard edition，以及進行安全管理和彙總整合的 AppScan enterprise Edition 等。咱們常常說的 AppScan 就是指的桌面版本的 AppScan，即 AppScan standard edition。其安裝在 Windows 操做系統上，能夠對網站等 Web 應用進行自動化的應用安全掃描和測試。
AppScan 三個核心要素
AppScan 是對網站等 Web 應用進行安全攻擊來檢查網站是否存在安全漏洞；既然是攻擊，須要有明確的攻擊對象。對網站來講，一個網站存在的頁面，可能成千上萬。每一個頁面也均可能存在多個字段（參數），好比一個登錄界面，至少要輸入用戶名和密碼吧，這就是一個頁面存在兩個字段，你提交了用戶名密碼等登錄信息，網站總要有地方接受而且檢查是否正確吧，這就可能存在一個新的檢查頁面。這裏的
每一個頁面的每一個參數均可能存在安全漏洞，全部都是被攻擊對象，都須要來檢查。
這就存在一個問題，咱們來負責來檢查一個網站的安全性，這個網站有多少個頁面，有多少個參數，頁面之間如何跳轉，咱們可能並不明確，如何知道這些信息？看起來很複雜，盤根錯節；那就更須要找到那個線索，提綱挈領；想想，訪問一個網站的時候，咱們須要知道的最重要的信息是哪一個？網站主頁地址吧？從網站地址開始，不少其餘頻道，其餘頁面均可以連接過去，對不對，那麼
可不能夠有種技術，告訴了它網站的入口地址，而後它「順藤摸瓜」，找出其餘的網頁和頁面參數？OK，這就是「爬蟲」技術，具體說，是「網站爬蟲」，其利用了網頁的請求都是用 http 協議發送的，發送和返回的內容都是統一的語言 HTML，那麼對 HTML 語言進行分析，找到裏面的參數和連接，紀錄並繼續發送之，最終，找到了這個網站的衆多的頁面和目錄。這個能力 AppScan 就提供了，這裏的術語叫「探索」，explorer，就是去發現，去分析，瞭解未知的，並記錄之。
在使用 AppScan 的時候，要配置的第一個就是要檢查的網站的地址，配置了之後，AppScan 就會利用「探索」技術去發現這個網站存在多少個目錄，多少個頁面，頁面中有哪些參數等，簡單說，瞭解了你的網站的結構。
「探索」瞭解了，測試的目標和範圍就大體肯定了，而後呢，利用「軍火庫」，發送導彈，進行安全攻擊，這個過程就是「測試」；針對發現的每一個頁面的每一個參數，進行安全檢查，檢查的彈藥就來自 AppScan 的掃描規則庫，其相似殺毒軟件的病毒庫，具體能夠檢查的安全攻擊類型都在裏面作好了，咱們去使用便可。
那麼什麼是「徹底測試呢」，徹底測試就是把上面的兩個步驟整合起來，「探索」+「測試」；在安全測試過程當中，能夠先只進行探索，不進行測試，目的是瞭解被測的網站結構，評估範圍；而後選擇「繼續僅測試」，只對前面探索過的頁面進行測試，不對新發現的頁面進行測試。「徹底測試」就是把兩個步驟結合在一塊兒，一邊探索，一邊測試。
AppScan 工做原理小結以下：
- 經過搜索（爬行）發現整個 Web 應用結構
- 根據分析，發送修改的 HTTP Request 進行攻擊嘗試（掃描規則庫）
- 經過對於 Respone 的分析驗證是否存在安全漏
AppScan 掃描原理：掃描規則庫 + 爬行 + 測試
步驟 1：探索（又叫爬行，爬網）
步驟 2：測試（針對找到的頁面，生成測試，進行安全攻擊）
因此，簡言之，AppScan 的核心是提供一個掃描規則庫，而後利用自動化的「探索」技術獲得衆多的頁面和頁面參數，進而對這些頁面和頁面參數進行安全性測試。
「掃描規則庫」，「探索」，「測試」就構成了 AppScan 的核心三要素。而在安全掃描過程當中，如何進行優化，就要結合這三個要素，看哪些部分須要優化，應該如何優化。
AppScan 結果文件
同時，對於 AppScan 標準版來講，掃描的配置和結果信息都保存爲後綴名爲 Scan 文件，Scan 文件裏面主要包括的內容以下：
- 掃描配置信息：掃描配置信息，如掃描的目標網站地址，錄製的登錄過程腳本等，選擇的掃描設置等都保存在 Scan 文件中。
- 全部訪問到頁面信息：針對每一個發現的頁面，即便沒有進行測試，在探索過程也會訪問該頁面並紀錄 http request/response 信息；因此若是探索的頁面訪問的時候返回的頁面內容比較多，頁面比較大，那麼即便只作了探索根本沒有掃描，整個 Scan 文件也會很大。
- 測試階段，記錄測試成功的測試變體和頁面訪問信息：針對每一個頁面都會發送屢次測試（測試變體），每次測試都會有 Request/response 信息，這些信息若是測試經過，即發現了一個安全問題，則會把該測試變體對應得 request/response 都會紀錄下來，保存在 .scan 文件中；因爲 AppScan 的掃描測試用例庫全面，對於每種安全威脅漏洞，都會發送多個安全測試變體（Variant）進行測試，好比對於 XSS 問題，AppScan 發送了 100 個變體，其中 30 個執行失敗，70 個變體執行成功，則會紀錄 70 次執行成功的具體變體信息，以及每一個變體對應的 Request/Response 信息。這就是一個很大的數據量。這些信息保存之後，就能夠在不鏈接在網站的狀況下進行結果分析，快速顯示當時測試的頁面快照等。
咱們以
http://demo.testfire.net/bank/customize.aspx 爲例，以下就有 74 個變體都發現了 Customize 頁面的 Lang 參數存在跨站點腳本執行（XSS）類型的安全漏洞：
因此針對 AppScan 標準版來講，因爲須要保存的信息比較多，結果文件是會比較大的，最根本的方法仍是有針對性地進行掃描和測試，使用排除頁面等排除冗餘頁面，把一個大的系統分解爲多個小的掃描任務等。
大型網站技術特色分析
AppScan 掃描的對象是網站等 Web 應用，而網站規模的大小和使用的技術，都須要針對性的進行掃描設置，咱們遇到的不少問題，都是在掃描規模比較大的網站時候遇到的，如一個網站頁面數目超過 2000 個，須要執行的掃描用例是 50，000 個，在掃描這樣的網站時候，默認狀況下 AppScan 的掃描 scan 文件可能超過 100M 了，掃描效率就可能比較慢，須要長時間的掃描運行時間。
下面，咱們就來分析大型網站中存在的一些可能影響 AppScan 掃描的技術特色。
網站頁面多，頁面參數多，則 AppScan 須要發送的測試用例多
什麼叫大型網站，顧名思義，網站規模大，提供內容多；具體說是頁面不少，內容很全。好比
www.sina.com.cn，好比 http://music.10086.cn/，網站中都有多個頻道，包括上萬個頁面。並且除了頁面多，可能還有一個特色 --- 頁面參數多，即要填寫的地方多，和用戶的交互多；好比一個網站若是都是靜態頁面（.html、.jpg 等），沒有讓用戶輸入的地方，那麼能夠利用，能夠做爲攻擊點的地方也就很少。若是頁面處處都是有輸入有查詢，要求用戶來參與的，你輸入的越多，可能泄露的信息也越多，可能被別人利用的攻擊點也就越多，因此和頁面參數也是有關係的。
AppScan 產生測試用例的時候，也是根據每一個參數來產生的，簡單說，若是一個參數，對應了 200 個安全攻擊測試用例，那麼一個登錄界面至少就對應 400 個了，爲何？登錄界面至少有用戶名（username）和密碼（password）兩個字段吧？每一個字段 200 個攻擊用例。
這個簡單吧，還能夠更復雜：若是遇到下面的兩個地址，那要掃描多少次呢？
http://www.Test.com/focus/satisfy/file.jsp?id=1 http://www.Test.com/focus/satisfy/file.jsp?id=2
上面的兩個地址有相似的，「?」號之前的 URL 地址徹底同樣，「?」號後面帶的參數不一樣，這種能夠認爲是重複頁面，那麼對於重複頁面，是否要重複測試呢？
這取決於「冗餘路徑設置」，默認的是最多測試 5 次；即，這種類型 URL 出現的前 5 次，那麼就是要測試 1000 個攻擊用例了。
若是再繼續修改下：遇到下面的 URL 呢
http://www.Test.com/focus/satisfy/file.jsp?id=&Item=open http://www.Test.com/focus/satisfy/file.jsp?id=2&Item=close
每一個 URL 裏面都有 2 個參數，測試的次數就更多了。想象下，若是這個網頁裏面的參數若是是 10 個，或者更多的呢？好比不少網站提交註冊信息的時候，要填寫的欄位就不少，要進行的安全測試用例也就隨之不斷增長…
這是網站規模的影響，還有一個問題，就出在「每一個參數，發送 200 個安全測試用例」這個假設上。這個假設的前提來源於哪裏？來源於咱們選擇的掃描規則庫。即你關心那些安全威脅，這個須要在測試策略裏面選擇。一樣來參照殺毒軟件，你會用殺毒軟件來查找一些專用的病毒嗎，好比 CIH、木馬；應用安全掃描也是同樣的道理，若是有明確的安全指標或者安全規則範圍，那麼就選擇之。這些可能來源於企業的規範，來源於政府的法律法規。就要根據你的理解，在這裏選擇。
在實際工做中，咱們也很難在最開始的階段，就把掃描規範制定下來，按照項目經理們的口頭禪「漸進明細」，「滾動式規劃」，在實踐中，更多時候也是摸着石頭過河，選擇了一個掃描策略，而後根據結果分析，看是否須要調整，不斷優化。好比選擇默認的「缺省值」掃描策略，對網站進行掃描，發現其「敏感信息」裏面會去檢查頁面上是否含有 Email 地址，是否含有信用卡號碼等，若是咱們以爲這些信息，顯示在頁面上是正常的業務須要（好比這樣的連接：
<a href="mailto:admin@www.test.com">有問題請聯繫 admin@www.test.com</a>），咱們就能夠取消掉這些規則，因此掃描規則也很大程度上影響着咱們的掃描效率。
網站採用多種混合的技術，須要不一樣的掃描設置
一些大型網站，每每是一個統一的入口，在裏面提供不一樣的內容，而這些內容可能來源於不一樣的技術。如咱們熟悉的門戶網站，裏面就有「財經」、「體育」、「娛樂」等多個頻道；每一個頻道的內容，多是採用不一樣的技術，對應不一樣的服務器。如一個網站的「論壇」頻道，就有不少相似的頁面：
http://www.Test.com/bbs/showthread.php?id=1 Http://www.Test.com/bbs/showthread.php?id=2 Http://www.Test.com/bbs/showthread.php?id=3
這裏的 showthread.php 頁面存在屢次，每次都是參數值不一樣，訪問後發現這些頁面除了文本內容外，其餘的頁面結構等都相同，則這些頁面只須要選擇幾個典型的掃描便可，沒有必要所有掃描。
而同時，在另外的一些頻道，存在另外類型的頁面：
http://www.Test.com/default.aspx?content=inside_community.htm http://www.Test.com/default.aspx?content=inside_press.htm http://www.Test.com/default.aspx?content=inside_executives.htm
這些動態頁面，也是網址相同，參數相同，可是具備不一樣的參數值，訪問時候發現每種類型的參數值都指向了徹底不一樣的頁面，則須要每種參數值都要測試到。這種狀況常常存在跳轉頁面中。
而這兩個頻道中，第一種狀況，能夠選擇典型的頁面掃描之，而第二種狀況則須要進行徹底的掃描，每種參數值都須要考慮到。這就須要不一樣的掃描設置。
同時，可能你們也注意到了，第一種狀況下的是 php 頁面，而第二種狀況下的則是 aspx 頁面，對應不一樣的開發技術，這也可能須要不一樣的掃描設置。
因此，總結下，AppScan 的掃描受到以下因素的影響：
- 網站規模（頁面個數，頁面參數）
- 掃描策略的選擇
- 掃描設置
而對於大型的網站，咱們常常須要從幾個方面來優化配置
- 選擇合適的，最小化的掃描規則
- 分解掃描任務，把一個大的掃描任務分解爲多個小的掃描任務
- 根據頁面特色，設置能夠過濾的相似頁面（冗餘頁面）