AppScan 安全漏洞扫描策略
使用 AppScan 進行掃描
針對大型網站的掃描，我們按照戴明環 PDCA 的方法論來進行規劃和討論，建議 AppScan 使用步驟：計劃（Plan）、執行（Do）、檢查（check）、分析（Analysis and Action）。
下面我們針對每個階段，進行具體的闡述。
?
準備階段
AppScan 安裝環境要求和檢查
為了保證更好的掃描效果，安裝 AppScan 的硬件建議配置如下：
表 1. Rational AppScan 安裝配置要求
| 1 2 3 4 | 處理器 Pentium P4，2.4?GHz 內存???????????2?GB RAM 磁盤空間??? ??30?GB 網絡???????????1?NIC?100?Mbps（具有已配置的 TCP/IP 的網絡通信）? |
其中，處理器和內存建議越大越好，而磁盤空間，建議系統盤（一般是 C 盤）磁盤空間至少保留 10G，如果系統盤磁盤空間比較少，可以考慮把用戶文件等保存在其他盤；如默認的用戶文件是：C:\Documents and Settings\Administrator\My Documents\AppScan；可以修改為其他路徑。該路徑可以在菜單欄中依次選擇工具 - 選項 - 一般 - 文件位置部分修改。
磁盤要求：修改臨時文件路徑
有時候大家會發現，已經把上面的地址都修改到了其他盤，但是在掃描過程中，還是會發現 C 盤的空間快速被消耗，分析原因，是因為很多臨時文件都保存在 C 盤，AppScan 中有一個隱藏的參數 APPSCAN_TEMP 來設置臨時文件位置。在掃描過程中，如果系統盤空間比較下，可以通過修改系統變量來修改到其他硬盤空間。
臨時文件位置說明：描述正常操作期間 AppScan 將其臨時文件保存到的位置。缺省情況下，AppScan 將其臨時文件存儲在以下位置：
C:\Documents and Settings\All Users\Application Data\IBM\Rational AppScan\temp
如果需要修改此缺省位置，請按照要求編輯環境變量 APPSCAN_TEMP 的路徑。（訪問環境變量的方法是，右鍵單擊我的電腦，然后依次選擇屬性 > 高級 > 環境變量。）
?
注意：在新位置的路徑中絕不能有任何 Unicode 字符。
修改 AppScan 中的臨時文件：
?
計劃階段
在計劃階段，首先明確幾個問題：
掃描策略的選擇
試想，我們現在要掃描的是某個移動公司的網站系統，該網站系統提供多個內容頻道，還可以連接到多個其他移動公司網站和業務網站，我們本次安全測試重點關心的是門戶網站本身和其上面的網上營業廳業務。這就是一個比較明確的測試目標對象。
然后，確定掃描策略，我們主要關心該網站是否存在跨站點腳本執行和 SQL 注入的問題，則在掃描規則中，我們就可以選擇這兩種類型的規則，其他規則都排除。
具體的掃描規則定制，可以在掃描配置 - 測試 - 測試策略中選擇：
?
在測試策略中，有多種不同的分組模式，最經常使用的是“嚴重性”，“類型”，“侵入式”、“WASC 威脅分類”等標準，根據不同分組選擇的掃描策略，最后組成一個共同的策略集合。
根據我們這次掃描的目標，關心的是跨站點腳本執行和 SQL 注入的問題，而且不考慮“基礎結構”級別的安全問題。則就可以首先選擇一個默認的掃描策略，然后全部置空，再選擇
跨站點腳本執行和 SQL 注入，最后再去除這兩種掃描策略中和基礎結果相關的安全問題。
方法如下：
- 選擇缺省的掃描策略，或者把當前的掃描策略，切換到按照“類型”分類，取消掉“基礎結構”和“應用程序”兩種類型。 ?說明：則把掃描策略置空，沒有選擇任何的掃描策略，指所有分布類型選擇“類型”分類，是因為類型分類里面含有的類型，只有兩種類型，可以快速全部都取消掉。
?
- 分組類型，切換到“WASC 威脅分類”，選擇“SQL 注入”和“跨站點腳本編制”。
?
?
- 分組類型，切換到“類型”，發現這時候“基礎結構”和“應用程序”兩種類型的掃描策略都是選擇上的模式，而且是虛線，說明這兩種類型下均有部分掃描策略被選擇了。
?
- 我們不關心“基礎結構”級別的安全問題，所以在這里取消“基礎結構”。
?
?
- 分組類型，切換到“侵入式”類型，下面有“非侵入式”和“侵入式”兩種分類。取消“基礎結構”級別的測試。
侵入式的測試用例，往往因為有比較強的副作用，可能對系統造成傷害，所以一般掃描生產系統的時候，很少選擇。我們可以查看一個 SQL 注入類型的侵入式安全問題，在“輸入以查找”輸入框中輸入“SQL”，然后回車查詢?？梢钥吹綔y試變體的描述“將參數值設置為 Declare/Case SQL 注入攻擊（嘗試關閉 DB 服務器）”，則掃描過程中，會使用該測試用例去執行嘗試關閉數據庫的命令，如果該測試用例執行通過，則就關閉了數據庫，則整個系統就癱瘓！所以，要很慎重的選擇“侵入式的測試用例”。
其他的在“類型”中，“應用程序”類型表示該問題的存在是因為應用程序不嚴謹，代碼存在安全問題而造成的，修改方法就是修改原代碼；而“基礎結構”類型，則表示該問題是配置問題，建議修改系統配置或者安裝最新的補丁（經常是中間件或數據庫補丁）。
了解被測試網站
在對網站進行測試之前，我們經常需要先大概了解下這個網站，比如該網站使用了哪些技術，提供什么類型的業務（功能），網站規模等。這些都和我們的掃描設置相關。如下圖，就是我們經常使用的一個調查表，了解被測試系統的基本特點。
表 2. 記錄被測網站特點
其中，用戶經常迷惑的是 URL 數量，有些時候，用戶很難評估出一個系統的大概頁面數量，而按照 AppScan 的工作原理，掃描是針對頁面的每個參數的，如果頁面越多，參數越多，則掃描要運行的時間也就越長，掃描保存成的接過文件也是越大，更需要進行分解。如果一個掃描任務，本身的已訪問 URL 數超過 5000，評估的要運行的安全測試用例數超過 50，000，則建議進行掃描配置的分析，并根據分析結果，決定是否需要進一步的任務分解和分工。
那么，如果可以了解到網站具體有哪些頁面呢？這里我們就可以利用 AppScan 的探索（頁面爬行）能力。
在掃描配置里面設置了主 URL 以后，工作菜單中中依次選擇掃描 - 僅探索。對網站進行探索。一般會讓探索工具運行 10 到 30 分鐘，看該網站具體存在哪些頁面，哪些參數等。這個就可以切換到“應用程序數據”視圖來查看。
我們一般關心這幾個視圖：
- 已訪問的 URL()：AppScan 已經探索到并且進行了分析的頁面
- 已過濾掉的 URL()：AppScan 已經發現，同時根據掃描配置，認為不需要進行安全掃描的頁面。
- 中斷鏈接 URL()：AppScan 發現了，但是無法訪問到或者訪問出錯的頁面，如 404 頁面不存在，或者 500 服務器錯誤等。
偽靜態頁面
可以選擇左邊“我的應用程序數據”中的 URL 樹下的每一個節點，察看該節點已訪問的 URL，已過濾掉的 URL 等。
如在已訪問的 URL() 中，我們發現大量類似如下結構的 HTML 頁面：
| 1 2 3 | http://www.Test.com//focus/satisfy/file5.html http://www.Test.com//focus/satisfy/file6.html http://www.Test.com/m-zone/news/dgdd/quanbu/bylb/file5.html |
其共同特征，都是以 html 為后綴名，最后的文件名格式都是?file+ 數字格式；這種類型的頁面經常存在新聞，論壇等。如果訪問這些頁面，發現頁面結構相同，差異的都是里面的文本內容，如提供不同的新聞內容等，這些頁面就是所謂的“偽靜態頁面”，其實是網站發布系統動態產生的，由于結果相似，在安全掃描中，沒有必要針對這些頁面每次都進行掃描。如針對每個目錄下面存在的 file+ 數字格式的頁面，我們就可以設置正則表達式來過濾，比如，在掃描配置 - 排除路徑和文件中
?
排除所有該類型的頁面；.*file\d+.html
增加“例外”，對該類型的頁面只掃描 file1.html 和 file20.html
經常存在的其他類似頁面，還有 news1.html、content200.html 等類型，采用方法類似。
業務類型的“冗余路徑”
和“偽靜態頁面”對應的有另外一種動態頁面，這些頁面按照默認的掃描規則，會被自動過濾，但是根據真實的業務場景，這些頁面確實不能被過濾的，如訪問 demo.testfire.net 時候在“已過濾 URL”內會顯示有如下的 URL 地址，過濾原因都是“路徑限制”：
| 1 2 3 | 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 |
選擇 URL 地址，鼠標右鍵“在瀏覽器中顯示”，會發現這里顯示的頁面內容完全不一樣，和上面的“偽靜態頁面”正好相反，這些參數相同，參數值不同的動態頁面，是真正的業務頁面，是不能過濾掉；如果過濾，則會很多后續的業務頁面無法發現。那這些頁面為什么會被過濾了呢？按照什么樣的規則被過濾掉的？
在 AppScan 中，默認情況下是有一個“冗余路徑限制”（在“掃描配置 - 探索選型 - 冗余路徑限制”），默認對于冗余的頁面，最多掃描 5 次，關鍵的問題是，什么頁面被 Appscan 認為是冗余頁面呢 ?
簡單說：
| 1 | http://www.Test.com/default.aspx?content=inside_community.htmhttp://www.Test.com/default.aspx?content=inside_press.htm |
Appscan 是根據“?”號來分隔的，如果 ? 號前面的內容都相同，則就被認為是冗余頁面，所以上面的頁面就是冗余頁面了。
遇到這樣情況的頁面，最多被訪問 5 次。而這 5 次，具體是使用了哪些參數，是隨機的，具體訪問到的頁面也會在“應用程序數據”視圖的“已訪問的 URL”中查看：
| 1 | http://www.Test.com/default.aspx?content=business.htmhttp://www.Test.com/default.aspx?content=business_lending.htmhttp://www.Test.com/default.aspx?content=inside_contact.htm |
可是，在本例中 content 參數值不同的時候，其實根據業務邏輯，不應該算作“冗余頁面的”，而按照配置，也會被自動過濾了，遇到這種情況，就需要考慮增加“冗余路徑限制”，如設置為 20 或者 50。以可以更多次訪問這些頁面。
這些情況經常存在于跳轉參數等情況。
順便備注下，“冗余路徑限制”，功能設置的目的是為了處理類似論壇 BBS 等頁面，只有文本內容不同，頁面架構完全相同的頁面：如
| 1 2 3 | http://www.Test.com/showthread.php?id=1 http://www.Test.com/showthread.php?id=2 http://www.Test.com/showthread.php?id=3 |
而我們在測試 demo.testfire.net 時候會發現每次的安全測試結果都可能有差別，一個很大的原因就是每次訪問的頁面是不同的，就是這個設置的影響。
分析重復的“腳本參數”
在上面的步驟中，分析了“偽靜態頁面”，對其應該通過“排除路徑或者文件名”的方法設置排除規則；而對于“業務類型的冗余路徑”，則需要通過增加“冗余路徑顯示”個數等的方法進行擴充，以掃描到這些 URL。我們在這個步驟來分析另外一種參數，腳本參數。
在“我的應用程序數據”樹狀結構下，鼠標選擇目錄以后，在右邊視圖中選擇“腳本參數”，然后查看是否存在不同頁面（URL) 存在相同或者類似參數的情況：如下圖，在不同 URL 中，都存在 kbKey 參數，默認的參數值是“請輸入您要搜索的問題”：
?
訪問這些 URL，發現每個頁面內都包含了一個搜索功能，這就是為什么在不同頁面都發現了該參數。而從業務角度，這些搜索頁面在一個 URL 中進行測試以后，沒有必要在另外一個頁面也進行測試。而且該參數值的變化，可以認為是冗余頁面，沒有必要進行下一步的重新探索和測試。這可以通過上圖中，選擇該參數后，鼠標右鍵，選擇“添加到‘參數和 Cookie’選項卡中的列表”來實現。選擇后彈出下面的頁面：
?
?
?
在該頁面中，點擊“其他選項－冗余調整”，取消選擇任何一個選擇框，則表示無論是否含有該參數，無論該參數值是否發生變化，都不認為是新頁面，沒有必要重新測試，而且不應該因為該參數的變化去影響其他參數的測試。
我們知道，AppScan 中的測試，是針對頁面的每個參數進行的，而且一個參數值的變化會要求重新測試其他的參數，所以該設置，可以大大減少測試用例數。
?
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 | 選框?? 選中時 ... 只要添加或除去此參數?/cookie，便再次探索 URL。?? 在探索階段，如果兩個 URL 的唯一區別在于一個包括此參數，而另一個不包括此參數，那么將其視為不同 URL，并且對兩者都進行探索。 例如，如果是以下兩個 URL，兩者都將進行探索： ...page.jsp ...page.jsp?thisParam=Value 如果您取消選中此復選框，那么在此情況下，將僅發送一個請求，而其他請求將被廢棄。 只要此參數?/cookie 的值更改，便再次探索 URL。?? 在探索階段，如果兩個 URL 的唯一區別在于此參數?/cookie 的值，那么將其視為不同 URL，并且對兩者都進行探索。 例如，如果是以下兩個 URL，兩者都將進行探索： ...page.jsp?thisParam=Value1 ...page.jsp?thisParam=Value2 如果您取消選中此復選框，那么在此情況下，將僅發送一個請求，而其他請求將被廢棄。 只要添加或除去此參數?/cookie，便重復所有相鄰參數 在測試階段，如果兩個 URL 的唯一區別在已添加或除去了此參數，那么將其視為不同 URL，并且再次測試相鄰參數。 ?/cookie測試 例如，如果是以下兩個 URL，將為相鄰參數生成兩組完整的測試，每個 URL 一組。 ...page.jsp?adjacentParam=<test_this> ...page.jsp?adjacentParam=<test_this>&thisParam=Value 如果您取消選中此復選框，將為相鄰參數僅生成一組測試。 只要此參數?/cookie 的值更改，便重復所有相鄰參數????? 在測試階段，如果兩個 URL 的唯一區別在于此參數?/cookie 的值，那么將其視為不同 URL，并且再次測試相鄰參數。 /cookie測試 例如，如果是以下兩個 URL，將為相鄰參數生成兩組完整的測試，每個 URL 一組。 ????? ...page.jsp?adjacentParam=<test_this>&thisParam=Value1 ?? ...page.jsp?adjacentParam=<test_this>&thisParam=Value2 如果您取消選中此復選框，將為相鄰參數僅生成一組測試。 |
查看每個目錄頁面個數
如果一個掃描任務，本身的已訪問 URL 數超過 5000，評估的要運行的安全測試用例數超過 20，000，則建議進行掃描配置的分析，并根據分析結果，決定是否需要進一步的任務分解和分工。
我們在“我的應用程序數據”樹狀結構下，鼠標選擇目錄以后，在右邊視圖中選擇“已訪問的 URL()”，記錄 URL 數目，如果該目錄 URL 數目比較大（超過 500）則可以考慮為該目錄單獨建立一個掃描任務，只掃描該目錄下面的鏈接。
執行階段
根據在“計劃階段”確定的掃描策略，和進行的掃描設置，重新進行探索（掃描菜單依次選擇：重新掃描 - 重新探索）；后繼續分析頁面數和測試用例數目，如果控制頁面數 5000 個以內，測試用例數 20，000 個以內，則可以直接進行掃描；如果沒有，建議繼續分析，優化掃描配置。
分階段測試
AppScan 的掃描過程分為“探索”和“測試”兩個階段，默認情況下，使用的是完全掃描模式，即是邊探索邊測試的。如果網站比較大，建議考慮先探索后測試的模式。
如當 URL 達到 5000，需要進行的測試達到 50000 的時候，可以暫停掃描，手工停止探索，選擇“繼續僅測試”。對已經發現和分析的頁面進行測試，測試完畢，再來選擇“繼續僅探索”，即：
繼續僅探索 --- 繼續僅測試—繼續僅探索 - 僅測試的一個循環過程。
在這個過程，一個階段結束以后，建議查看下 .Scan 文件的大小，如果大小超過了 500M，則建議考慮任務分解，可以根據目錄把一個掃描任務分解為多個，或者根據掃描策略來進行分解。
該方法是利用了 AppScan 掃描過程中，探索測試可以分離，而且支持掃描過程中斷后繼續掃描的特性。
按照業務分解掃描任務
在實際工作中，我們掃描的一個大型網站，往往包含多個頻道，而每個頻道可能需要的掃描配置都不同，這些配置甚至互相沖突。如一個網站的提供了 BBS 論壇功能：
| 1 2 | http://www.Test.com/WWW.TEST.COM/showthread?channel=1&thread=1001 http://www.Test.com/WWW.TEST.COM/showthread?channel=30&thread=2001 |
對于這樣的頁面，訪問后發現頁面結構相同，只是文本內容不同，則應該使用“冗余路徑限制”參數，控制掃描次數，沒有必要多次掃描。
同時，該網站的一個服務頻道存在如下的頁面：
| 1 2 | http://www.Test.com/default.aspx?content=inside_executives.htm http://www.Test.com/default.aspx?content=privacy.htm |
即上面提到的業務類型的“冗余路徑”，應該多次掃描，配置上要求增大“冗余路徑限制”參數。
在這種情況下，就很有必要根據業務分別建立掃描任務，每個任務采用不同的掃描配置。
檢查階段
在掃描執行過程中，需要檢查，看是否存在下面的情況：
- 提示網絡連接不上，或者提示部分頁面無法打開。則檢查是否是掃描速度過快，服務器不能承受不了，根據情況修改掃描配置 - 連接 - 通信和代理，增加“超時”數，并考慮減少“并發線程數”，以允許更長時間的等待頁面影響并減少對服務器的訪問連接數。
- 發現掃描出的安全問題，包含我們不關心的安全隱患，則取消掉這些規則。如發現了一個安全隱患，類型是“SQL 注入文件寫入（需要用戶驗證）”，該問題是需要用戶根據提示來檢查的，并且是針對 SQL 數據庫的，如果我們使用的數據庫不是 SQL 數據庫，或用戶確認后沒有發現線索，則就可以在掃描配置 - 測試 - 測試策略中取消選擇該策略。
- 執行“計劃階段”的檢查，看是否還存在“偽靜態頁面”，“業務類型的冗余路徑”等，如果存在，則調整掃描配置。
分析階段
在分析階段，結合業務特點，檢查是否掃描范圍，分析掃描結果，并針對掃描出來的問題，進行分析，產生多種類型的報告等。
掃描結果檢查
掃描結束后，建議切換到“應用程序數據”視圖中，對頁面進行分析，檢查是否核心頁面都被測試到了。重點檢查如下部分：
報告分析
我們需要對報告進行對比分析或者報告匯總合并，方法如下：
案例分析
工作中遇到一個案例，使用 AppScan 掃描掃描了 3*24 小時，掃描的 scan 文件已經達到 9G；掃描還在持續進行中，總體進度完成了 30%，可以想象掃描速度已經很緩慢，還需要多長時間才可以完成掃描？掃描完成以后如此大的結果文件是否可以成功打開和修改保存 ?
按照我的經驗，如果掃描結果文件大于 1G，那就很有必要立即停止掃描，進行配置分析。我們的分析過程如下：
| 1 2 | http://www.Test.com//focus/satisfy/file5.html http://www.Test.com//focus/satisfy/file6.html |
在掃描配置 - 排除路徑和文件中：
排除所有該類型的頁面；.*file\d+.html
增加“例外”，對該類型的頁面只掃描 file1.html 和 file20.html
6.同時，發現了 swf 文件，應該不準備掃描 Flash，所以在“排除文件類型”中，設置根據后綴名排除 swf 文件。
7.發現
| 1 | http://www.Test.com/service |
目錄下存在大量如下類型的頁面，都是 menu 參數值不同，訪問以后發現出現的是頁面中有不同的超鏈接：
| 1 2 3 | http://www.Test.com/service/Business.do?menu=Query http://www.Test.com/service/Business.do?menu=Open http://www.Test.com/service/Business.do?menu=Service |
確認該頁面是業務類型的“冗余路徑”，應該全面掃描，則需要把“冗余路徑設置”調整為比較大的參數，同時該頻道是網上營業廳頻道，也要求用戶先登錄。所以針對該目錄建立一個單獨的掃描任務，只掃描該目錄和其下子目錄。
8.分析發現 index.jsp 在多個目錄下出現，而且每次出現都有兩種格式，即沒有參數和有固定的三個參數，每次的參數值都相同。如：
| 1 2 3 | http://www.Test.com//rdwd/jfmz/jifen/index.htmlhttp://www.Test.com//rdwd/jfmz/jifen/index.html?queryType=common&applyArea=010 ????&kbKey=?請輸入您要搜索的問題http://www.Test.com//rdwd/txl/rdwdznyd/index.htmlhttp://www.Test.com//rdwd/txl/rdwdznyd/index.html?queryType=common&applyArea=010 ????&kbKey=?請輸入您要搜索的問題 |
訪問上面的頁面，發現內容相同，則說明是否帶這三個參數不會影響探索發現更多的頁面，則可以設置這三個參數每次是否出現，是否有不同值都可以認為是同一個頁面。
設置方法：掃描配置中依次選擇“參數和 Cookie”來實現。然后增加 queryType，applyArea，kbKey 三個參數，均設置為“是否有參數”、“參數是否變化”不影響測試的模式。
9.切換到“應用程序視圖”，分析“中斷鏈接”，發現一些頁面存在“范圍內容超過最大容量的”的情況，在 IE 瀏覽器中直接訪問，發現這些頁面存在死循環，頁面內容無限遞增。則在掃描配置 - 排除路徑和文件中排除這些頁面。
10.根據以上設置，建立了兩個掃描任務，均掃描“SQL 注入”和“跨站點腳本編制”。重新探索后，頁面總數減少到 4000 多，測試用例數減少到接近 50，000，兩個掃描任務均在 8 個小時內完成。
總結
以上是生活随笔為你收集整理的AppScan 安全漏洞扫描策略的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： RPA-艺赛旗iS-RPA Studio
- 下一篇： [转]用Eclipse进行可视化Java