一、 環境準備

測試通常給的是PDF文件，動輒幾百頁，看起來很費勁，看文件的時間可能比解決問題的時間還長。。。所以作為需要解決問題的我們來說，最好安裝AppScan，請測試人員提供型別為AppScan Scan File的檔案。（圖片模糊掉了URL，不影響問題分析）
 

二、 如何分析AppScan掃描出的安全性問題
AppScan掃描出的問題會一般按照嚴重程度分高，危，參三種類型，高危屬於必須要解決的問題；低危一般屬於config配置，或IIS配置問題；低的問題，一般也可能是高，低的衍生問題，高危問題造成的衍生問題特別多，故解決問題時，建議從高至低看，並且先易後難，最常見的就是SQL盲注，以SQL盲注為例分析：
當收到測試的測試檔案後，雙擊開啟，以疫苗資審為例：

三、 高危常見問題解決方案
1. SQL盲注：
主要就是通過注入SQL的關鍵字，來破壞原有的查詢，導致頁面報錯
a. 看看幾種常見的盲注方式：

b. 解決方案
思路：過濾關鍵字，在global.asax檔案中的Application_BeginRequest方法中校驗敏感字元/字母組合，具體參考網址http://www.jb51.net/article/34671.htm，
具體檔案在連結地址的SqlChecker.cs中，專案具有共性，也有特性，所以，SqlChecker.cs中的StrKeyWord,StrRegex視實際情況而定。
實際解決：從上面的幾種注入分析看，都含有+字元，最簡單最暴力的方法就是過濾掉+字元，如果這樣與程式碼衝突的話，可以按照攻擊的方式過濾：如過濾掉+and+，+or+，’+and+’ 等等。。。
2. SQL注入
a. 看看幾種常用的SQL注入方式

b. 解決方案
思路：SQL注入與SQL盲注實際的攻入方式不同，但是解決思路都是通過過濾特殊字元，只是過濾的字元稍有差異。
實際解決：從以上幾種注入可以看出都含有%27%3B，開始解析%27%3B是什麼字元，發現注入sql的是 這個字元，在vs裡面過濾掉 這個字元即可。
備註：SQL注入的方式很多，這只是其中的一種，還有其它的種類，比如下圖，要具體問題具體分析：

3. 基於跨站點的編制
思路與1,2相同，解決方法也是根據測試的結果過濾掉特殊字元。

4. 已解密的登入請求

解決方案：安裝SSL協議，或其它安全加密協議。

5. ASP.NET表單認證旁路
思路：這個問題看起來很高大上，高大上到上網查都沒查到解決方案，看著這個報錯也是想了很久。。。。現在我們看下這個問題的相關資訊
a. 首先是問題資訊：原始響應與測試響應對比，測試響應的Cookie中少了ASP.NET_SessionId，就是測試響應除去了cookie”ASP.NET_SessionId”(變體標識675)，故猜測可能禁止修改客戶端修改此cookie就可以了，在global檔案中加了句程式碼，開始測試。

b. a的方法測試結果是問題仍然存在，於是看了下修訂建議,判斷此建議並不可行，因為四川九個系統都部署在一個伺服器上，如果是環境問題造成的漏洞，那應該是九個報告都有。。。但是，這個問題僅僅出現在兩份報告裡面。

c. 最後看”請求/響應”頁（第一幅圖），將GET 後面的地址放到瀏覽器中測試，地址如下：

這個地址路徑在專案中並不存在，所以理論上應該報404的錯誤，但是開啟F12檢視，發現實際的狀態是200，這說明有可能是StatusCode錯誤造成的問題，如果是這個問題的話，只需要在跳轉的介面中將狀態修改成404即可。基於這樣的寫法，我們開始找跳轉的地方，發現是在Application_Error方法中（第二幅圖），於是去設定跳轉介面的StatusCode：HttpContext.Current.Response.StatusCode = 404;（第三幅圖），再次測試，問題解決。



實際解決：在跳轉的最終頁面設定StatusCode。
四、 低危常見問題
1. 檢測到隱藏目錄
這個問題是AppScan直接請求專案中存在的資料夾名稱，觀察專案反饋。反饋分為幾種，不作說明，只要配置IIS，並且程式碼做管控就可以了。方法如下：
a.1首先是IIS配置：



a.2 相應頁面程式碼設定，請注意這裡的無許可權設定，StatusCode也是404，不要設定成403。

2. 啟用了Mircrsoft Asp.Net除錯
設定webconfig中節點：compilation debug=”false”

3. 已解密的_ViewStatus引數
增加節點machineKey

4. 自動填寫未對密碼欄位禁用的HTML屬性
對密碼欄位增加屬性：autocomplete="off"

5. 發現電子郵件地址模式
刪除專案所有註釋中涉及到的郵件地址
五、 如何問題歸類
專案中加了check SQL盲注的程式碼後，確實SQL盲注，SQL注入，SQL旁路注入，跨站點指令碼編制都沒有了，但是出現了這麼多新的問題（圖一），WHY？？？？

（圖一）
仔細分析每個錯誤，如下幾個問題，報的錯都是一樣的，所以這些應該是一類的問題，只要解決一個地方，就可以消除這些錯誤。
從四個紅色框中的內容，尤其是最下面的一段script指令碼（專案開發中自定義指令碼）可以發現程式碼已經檢測到這個請求是有問題的，也將當前頁面跳轉，但是StatusCode仍然是200，這顯然是錯誤的，所以修改StatusCode狀態為400，或404即可。

（圖二）

（圖三）

（圖四）

（圖五）
修改之後測試結果如下：狀態是404，問題消除。

六、 處理問題注意點
a. 首先看報告中的修訂建議，如果沒有明確的建議，則看請求/響應部分，目前看來，所有的問題在這裡都能找到原因和答案。
b. 設定跳轉時，請設定StatusCode，不管是global中的跳轉還是程式碼裡面由於某種校驗失敗而執行的跳轉(非常重要)
c. 不要過分糾結某個問題和標題，AppScan同一個問題會造成很多的衍生問題，注意看請求/響應中的請求地址，響應狀態和推理，屬於同類問題的一種解決方法即可