軟件測試中Web安全測試概述及WEB的多多少少
1. web應用安全與系統安全
能取得某個系統的完全使用權是黑客的終極目標，而且這也是危害性最大的漏洞，因此操作系統，數據庫，底層網絡設備，各種系統配置和管理方面的安全是最被重視的，也是黑客們最為覬覦的。
web 應用的漏洞則不然，要想單獨通過web漏洞來獲得相關系統的完全使用權是相當困難的。但是web應用漏洞卻是傳播性最大的，而且數量最多的，一個有點惡意的人，都能非常容易的利用web應用漏洞造成破壞。一個好奇的兒童，一個心懷不滿的雇員，都能有意無意利用web應用漏洞。某公司的調查數據說，超過 70%的攻擊其實都是利用了web應用漏洞。
簡單地說，系統漏洞會帶來少而深的攻擊，web漏洞則會帶來多而淺的攻擊。漏洞的風險通常都是以廣播度×危害度而言，不能簡單地看能危害多深。試想一個網站三天兩頭地被人利用web漏洞騷擾，造成商業數據丟失，業務中斷，聲譽受損，不比被人直接做掉強。因此，web應用的安全在國外已經相當重視，有專門的組織，公司在專門研究和提供服務。如果對web安全有興趣，可以去owasp和wasc的網站上找資料。
2. web應用漏洞
現在業界對于web應用漏洞的總結和分類太多，不同的公司都會提一套漏洞的列表，還沒有形成業界的標準。其中大家對于xss，sql injection都是耳熟能詳，但是國內好多人一提web安全，也只能想到這類注入的漏洞。 如果撇開web服務器的配置管理等其他外圍因素，單純從web應用的代碼出發，我覺得web應用的漏洞可以分為四類。代碼遠程執行漏洞，功能邏輯漏洞，泄密漏洞和日志漏洞。
xss，ldap injection，sql injection等各種injection，可疑文件上傳，緩沖區溢出，這些漏洞全都是因為輸入中有代碼，而且這些代碼通過某些方式在某處以某些權限被執行。這類漏洞是大家知道最清楚的。
而功能邏輯漏洞則是指業務流程，認證授權方面的邏輯代碼有問題。試想一個普通用戶可以看其他用戶的工資，使用管理員的權限�；蛘咭粋�流程本來要走審批這一個過程，但是居然不審批也行。這都是邏輯代碼有問題，產生了安全問題。這類安全問題國內的還不太重視，但是在owasp上已經有了相關的文檔。
泄密漏洞是指由于異常沒有處理或者其他原因造成了系統信息的泄漏。比如說我就發現過，有程序員把測試帳號寫在網頁的注釋或者腳本里。日志漏洞這個就屬于比較高級的了，可能很多web應用本身都不記日志的，但是關鍵操作一定要保證日志的真實有效。我原來發現過一個系統記錄的日志中的用戶帳號居然是來自request里面的隱藏值，換句話說，用戶改掉這個值再干操作，就再也無跡可查了。
3. 業界現狀
安全市場三大產品：防火墻，入侵檢測系統和防病毒軟件。安全市場三大服務，安全培訓，安全評估，系統整合。上網搜搜web應用安全，國內基本上沒有這個職位�，F在國內市場上對web應用安全的總體重視度不夠。有一些大型互聯網公司和專做web應用的公司可能內部會有一些人在搞這塊，安全公司基本上都是系統安全和web安全混淆的。web應用安全單獨在市場上占的份額還不多。今年奧運會，很多網站在講安全，但是是否是注重了web應用安全，這點很難講，呵呵。
在國外，web應用安全的市場相對成熟了，有不少現成的產品。比較有名的是ibm的app scan，hp的web inspect。這兩個工具的思想都是在軟件開發的生命周期內對web應用的風險進行控制，核心功能是黑盒漏洞探測。其實原理很簡單，就是自動播放很多含有測試用例的http請求，根據http的響應來提取特征，進行漏洞識別。另外其他有些專門的工具也可以針對某一個漏洞進行測試，例如sql injection，xss等。但是由于原理局限，黑盒測試工具速度快，范圍廣，但是誤報率和漏報率都還比較高。所以人工測試是必要地補充，而代理工具是web安全測試中必不可少的一部分。 webscarab，paros，charles這些代理工具都能讓測試人員突破web ui的限制，去自由地建立測試用例。在自動測試和人工測試的基礎上，有一些公司，會專門測試web應用的漏洞，進而提供相關服務。
對web應用漏洞發現的另外一個思路是源代碼審計。通過對代碼進行分析，提取特征，發現代碼里的風險點。商業化比較好的是fortify。當然人工審計代碼也是可行的。所以國外也有一些小公司，專門提供源代碼審計的服務。另外，在最近兩年的web安全會議上，基本上發表的論文也都是關于源代碼審計的。
Web安全測試知多少
1. 數據驗證流程：一個好的web系統應該在IE端，server端，DB端都應該進行驗證。但有不少程序偷工減料，script驗證完了，就不管了;app server對數據長度和類型的驗證與db server的不一樣，這些都會引發問題。有興趣的可參看一下script代碼，設計一些case，這可是你作為一個高級測試人員的優秀之處哦。我曾修改了頁面端的script代碼，然后提交了一個form，引發了一個系統的重大漏洞后門
2. 數據驗證類型： 如果web server端提交sql語句時，不對提交的sql語句驗證，那么一個黑客就可暗喜了。他可將提交的sql語句分割，后面加一個delete all或drop database的之類語句，能將你的數據庫內容刪個精光!我這一招還沒實驗在internet網站上，不知這樣的網站有沒有，有多少個。反正我負責的那個web系統曾經發現這樣的問題。
3. 網絡加密，數據庫加密不用說了吧。
WEB軟件最常碰到的BUG為：
1、SQL INJETION
2、對文件操作相關的模塊的漏洞
3、COOKIES的欺騙
4、本地提交的漏洞
●SQL INJETION的測試方法
原理：
如有一新聞管理系統用文件news.asp再用參數讀取數據庫里的新聞譬如
http://www.xxx.com/news.asp?id=1這一類網站程序
如果直接用
rs.open "select * from news where id=" &
cstr(request("id")),conn,1,1
數據庫進行查詢的話即上面的URL所讀取的文章是這樣讀取的
select * from news where id=1
懂得SQL語言的就知道這條語言的意思是在news讀取id為1的文章內容。
但是在SQL SERVER里select是支持子查詢和多句執行的。如果這樣提交URL的話
http://www.xxx.com/news.asp?id=1and 1=(select count(*) from admin
where left(name,1)=a)
SQL語句就變成了
select * news where id=1 and 1=(select count(*)
from admin where left(name,1)=a)
意思是admin表里如果存在字段字為name里左邊第一個字符是a的就查詢news表里id為1的內容，news表里id為1是有內容的，從邏輯上的角度來說就是1&P。只要P為真，表達式就為真，頁面會返回一個正確的頁面。如果為假頁面就會報錯或者會提示該id的文章不存在。黑客利用這點就可以慢慢得試用后臺管理員的用戶和密碼。
文章來源于領測軟件測試網 http://www.anti-gravitydesign.com/
