1.打開軟件，點擊New Scanhtml
2.在website url中輸入被掃描的網址，點擊nextjava
3.在scanning profile中選擇測試的漏洞類型，默認選擇default（默認）web
在scan setting中選擇爬行設置，默認選擇default（默認），點nextsql
4.此頁面也是選擇默認，點擊next數據庫
5.Login頁面，建議選擇第一項，且進行登陸，只有登陸後掃描測試纔會更深刻不然不少登陸狀況不會被掃描到，保存登陸腳本後點擊next瀏覽器
6.finish頁面直接點擊finish便可安全
7.點擊finish後直接進入漏洞掃描過程服務器
7.1顯示三個信息。session
Taget Information：包含目標站點 工具
1、是否應答、2、WebServer的banner、3、操做系統、4、Web容器、5、程序語言
Statistics：對掃描的各類信息統計，包含
1、掃描的總時間、2、HTTP請求數量、3、平均掃描時間、4、掃描重複次數
Progress：掃描進度信息的提示，包含
1、是否掃描完成，100.00%表示已完成，2、端口掃描是否完成 3、蜘蛛爬行是否完成（文件數量、目錄數量、變量數量）、4、腳本信息 5、內部模塊
8.掃描測試完成後，數據分析以下
9.保存測試結果及導出測試報告
10.漏洞分析及驗證（工具也會出錯，防止awvs誤報）
10.1 sql注入漏洞分析驗證
（1）火狐瀏覽器安裝插件hackbar quantum，安裝插件後重啓瀏覽器按F9啓動插件
（2）sql注入分析，以下圖（漏洞描述及攻擊影響）
（3）關注項
view http headers
view html response
10.2 驗證漏洞真實性
1、URL安全測試
（1）適用範圍： URL中含有參數，也就是經過GET方式傳遞的HTTP請求
（2）什麼叫GET方式？
HTTP 定義了與服務器交互的不一樣方法，最基本的方法是 GET 和 POST。
GET方式在客戶端經過URL提交數據，數據在URL中能夠看到，例如在平常中訂購服務：
http：//www.cnblogs.com/javame/index.htm？servId=2
POST方式，數據放置在HTML HEADER內提交，數據在URL中看不到
GET只能傳輸比較少的數據，安全性較低，POST傳輸數據較多，安全性也比GET高
（3）測試關注點：
1） URL 參數檢查：
A： 對URL中參數信息檢查是否正確
如：URL中的訂單號、金額容許顯示出來的話，須要驗證其是否正確
B： 對於一些重要的參數信息，不該該在URL中顯示出來
如：用戶登錄時登陸名、密碼是否被顯示出來了 ，
2） URL參數值篡改
修改URL中的數據，看程序是否能識別：
如：對於如下URL，修改其中planId，看是程序是否能夠識別：
http：//www.cnblogs.com/javame/index.htm？planId=878
又如：對於URL中包含金額參數的，修改金額看是否可以提交成功（可能致使用戶把2元金額改爲1元金額能提交），還有修改訂單號等重要信息看是否會報錯
3） URL中參數修改進行XSS注入：
什麼是XSS？
XSS的全稱是Cross Site Script（跨站點腳本）
XSS的原理很簡單，即進行腳本注入，URL執行時即把此腳本進行了執行，通常都是JavaScript腳本。
如「http://www.cnblogs.com/javame/index.asp?IDClass=2&ClassName=abc」
改爲「http://www.cnblogs.com/javame/index.asp?IDClass=2&ClassName=abc<script>alert("hello")</script>」
看看有沒彈出對話框顯示hello，有的話就有跨站漏洞。
在URL中進行XSS注入，也就是把URL中的參數改爲JS腳本。
4） URL參數中進行SQL 注入
什麼是SQL注入？
SQL注入全稱是SQL Injection ，當應用程序使用輸入內容來構造動態sql語句以訪問數據庫時，會發生sql注入攻擊，如查詢、插入數據時。
測試方法： URL中寫入SQL注入語句，看是否被執行
如：www.cnblogs.com/javame這個網站中，選擇登錄
設置用戶名爲 admin ' or '1'='1 密碼爲任意數字 ，點擊登陸就能夠登錄。
通常狀況下要進行SQL注入攻擊，須要對數據庫類型、表名、判斷邏輯、查詢語句等比較清楚纔可以寫出有效的SQL注入語句。
2、表單提交安全測試
適用範圍：有表單提交的地方、有HTTP請求的地方（包括GET、POST請求）
測試關注點：
1） 表單中注入XSS腳本
什麼是XSS？這已在上一節中說明。URL中須要檢測XSS注入，表單中更須要驗證
測試方法：即在表單填寫框中直接注入JS腳本
如在表單中輸入XSS腳本，程序是不該該讓腳本執行的
2） 表單中注入SQL 腳本
與URL中參數進行SQL注入相似，就是在表單中寫入SQL注入腳本提交看是否會有問題
4、Session測試
（1）Session是客戶端與服務器端創建的會話，老是放在服務器上的，服務器會爲每次會話創建一個sessionId，每一個客戶會跟一個sessionID對應。
並非關閉瀏覽器就結束了本次會話，一般是用戶執行「退出」操做或者會話超時時纔會結束。
（2）測試關注點：
1）Session互竄
Session互竄便是用戶A的操做被用戶B執行了。
驗證Session互竄，其原理仍是基於權限控制，如某筆訂單隻能是A進行操做，或者只能是A才能看到的頁面，可是B的session竄進來卻可以得到A的訂單詳情等。
Session互竄方法：
多TAB瀏覽器，在兩個TAB頁中都保留的是用戶A的session記錄，而後在其中一個TAB頁執行退出操做，登錄用戶B，此時兩個TAB頁都是B的session，而後在另外一個A的頁面執行操做，查看是否能成功。預期結果：有權限控制的操做，B不能執行A頁面的操做，應該報錯，沒有權限控制的操做，B執行了A頁面操做後，數據記錄是B的而不是A的。
2）Session超時
基於Session原理，須要驗證系統session是否有超時機制，還須要驗證session超時後功能是否還能繼續走下去。
測試方法：
1、打開一個頁面，等着10分鐘session超時時間到了，而後對頁面進行操做，查看效果。
2、多TAB瀏覽器，在兩個TAB頁中都保留的是用戶A的session記錄，而後在其中一個TAB頁執行退出操做，立刻在另一個頁面進行要驗證的操做，查看是能繼續到下一步仍是到登陸頁面。