軟件測試中的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的之類語句，能將你的數據庫內容刪個精光!我這一招還沒實驗在inte.net網站上，不知這樣的網站有沒有，有多少個。反正我負責的那個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的文章不存在。黑客利用這點就可以慢慢得試用后臺管理員的用戶和密碼。

　　測試：

　　測試存不存在SQL INJETION很簡單如果參數為整數型的就在URL上分別提交http://www.xxx.com/news.asp?id=1and 1=1　和http://www.xxx.com/news.asp?id=1and 1=2

　　如果第一次返回正確內容，第二次返回不同頁面或者不同容內的話表明news.asp文件存在SQL INJETION。如何利用就不多說了，畢竟我們都不是為了入侵。

　　● 對文件操作相關的模塊的漏洞在測試

　　原理：

　　如一上傳文件功能的程序upload.asp如果程序員只注重其功能上的需求沒有考慮到用戶不按常規操作的問題。如上傳一個網頁木馬程序上去，整個網站甚至整個服務器的架構和源碼都暴露而且還有一定的權限。

　　測試：

　　試上傳asp,php,jsp,cgi等網頁的文件看是否成功。

　　補充：

　　還有像　http://www.xxx.com/download/filespath.asp?path=../abc.zip

　　下載功能的軟件如果

　　http://www.xxx.com/download/filespath.asp?path=../conn.asp

　　很可能下載到這些asp的源碼數據庫位置及用戶密碼都可能暴露。

　　其它還有很多，就不一一舉例了。

　　● COOKIES的欺騙

　　原理：

　　COOKIES是WEB程序的重要部分，COOKIES有利有弊。利在于不太占用服務器的資源，弊在于放在客戶端非常容易被人修改加以利用。所以一般論壇前臺登陸用COOKIES后臺是用SESSION，因為前臺登陸比較頻繁，用SESSION效率很低。但如論壇程序管理員用戶在前臺也有一定的權限，如果對COOKIES驗證不嚴的話，嚴重影響了WEB程序的正常工作。如前期的LEADBBS，只有后臺對COOKIES驗證嚴格，前臺的位置只是從COOKIES讀取用戶的ID，對用戶是否合法根本沒有驗證。

　　測試：

　　推薦使用MYBROWER瀏覽器，可即時顯示及修改COOKIES。嘗試一下修改里面的對應位置。

　　● 本地提交表單的漏洞

　　原理：

　　Action只接愛表單的提交，所以表單是客戶WEB程序的接口。先舉一個例子，一個投票系統，分A，B，C，D各項的VALUE是100,80,60,40。

　　但是如果先把些頁面以HTML形式保存在本地硬盤里。然后修改其VALUE，再向其ACTION提交，ACTION會不會接受呢?

　　測試：

　　如一投票系統，把投票的頁面保存在本地硬盤，用記事本打開，找到對應項的VALUE值，對其修改，然后提交。

　　強制后臺瀏覽：繞過登陸頁面，直接提交系統文件夾或文件頁面。不完善的系統如果缺少index.html就可能被繞過登陸驗證頁面。在系統文件夾中保留一些公司機密內容也會造成不可估計的損失。

　　跨站腳本攻擊：基本上這個我只是在論壇——各種形式的論壇里看到過，具體的一個例子，比如這段代碼可以被填在任何輸入框里 “ SCRIPT>alert("攻擊!");

　　堆棧溢出攻擊：完全的不了解，只是在某個網站上看到，可以對現在的2000、XP、2003進行攻擊，非?？植?，MS應該打了補丁了吧? 

原文轉自：http://www.kjueaiud.com