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的文章不存在。黑客利用這點就可以慢慢得試用後台管理員的用戶和密碼。
測試：
測試存不存在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就可能被繞過登陸驗證頁麵。在係統文件夾中保留一些公司機密內容也會造成不可估計的損失。
跨站腳本攻擊：基本上這個我隻是在論壇——各種形式的論壇裏看到過，具體的一個例子，比如這段代碼可以被填在任何輸入框裏 “”，如果未對一些字符，如 “
‘進行轉換，就會自動執行這個腳本。百度快照所提供的網頁都自動將代碼執行了。不信大家搜一點JS的代碼，看看你能不能看到。
堆棧溢出攻擊：完全的不了解，隻是在某個網站上看到，可以對現在的2000、XP、2003進行攻擊，非常恐怖，MS應該打了補丁了吧？
關於安全的東西一向不好給大家講太多細節什麼的，我這裏給想研究的同學們 列一下幾種首先應該關注的漏洞類型，以及粗略的介紹，想詳細了解的自己去google吧，或者隨便去找個網站。
● XSS
XSS全稱Cross Site Scripting，中文叫做跨站腳本，起因是外部輸入被瀏覽器當作腳本來執行。按照漏洞觸發點的不同，分為3類： 1.存儲型XSS 2.反射型XSS 3.DOM型XSS。
??URL Open Redirect
顧名思義，沒有限製跳轉目標的URL Redirect就是Open URL Redirect。
● CSRF
CSRF的英文全稱是Cross Site Request Forgery，字麵上的意思是跨站點偽造請求。 ??強迫/誘使受害者的瀏覽器向一個易受攻擊的Web應用程序發送請求，最後達到攻擊者所需要的操作行為。
● SQL Injection
通過往客戶端傳遞給服務器端的參數中插入SQL代碼，達到影響服務器端SQL語句端執行的目的。
● Command Injection
通過控製輸入插入額外的shell指令 ，PHP代碼出現此類問題較多，Java中通過Runtime.exec(“sh command”)執行shell命令。
● File Inclusion
”require/include/require_once/include_once ” 的參數有外部輸入，外部輸入可以控製包含的文件或者路徑， 這是PHP特有的一類問題。
● Unauthorized file read/write
攻擊者通過控製URL參數或者POST參數，進而控製服務器端讀取文件的路徑或者文件名，達到惡意讀取文件的目的。
● File Uploading
字麵意思….文件上傳是一類非常普遍的問題。
● Buffer Overflow
通過往程序的緩衝區寫超出其長度的內容，造成緩衝區的溢出，從而破壞程序的堆棧，使程序轉而執行其它指令，以達到攻擊的目的。
網絡安全應具有以下五個方麵的特征：
保密性：信息不泄露給非授權用戶、實體或過程，或供其利用的特性
完整性：數據未經授權不能進行改變的特性。即信息在存儲或傳輸過程中保持不被修改、不被破壞和丟失的特性
可用性：可被授權實體訪問並按需求使用的特性。即當需要時能否存取所需的信息。例如網絡環境下拒絕服務、破壞網絡和有關係統的正常運行等都屬於對可用性的攻擊
可控性：對信息的傳播及內容具有控製能力
可審查性：出現的安全問題時提供依據與手段
1 產品安全
1.1 通信之間信息的安全
這個是我們測試人員需要做的，我們有很多種方法，而且，必須通過各種手段，才能保證信息的安全。
1.1.1 信道安全
使用網絡截包工具（這些工具網上很多，在上海的公安局檢測中心，我們用的是一個叫sniffer show的工具，但是上網沒找到。不過有sniffer，這個就很夠用了）
使用sniffer，安裝在主機上，以root用戶運行，就能很輕鬆的獲取它和其他機器的通訊數據。然後查看數據詳情，就可以清晰的看到常用的一些TAG，很容易看明白，哪些是賬號，哪些是密碼，其他數據又是什麼等等。
如果數據沒有加密，你會很容易的知道用戶名，密碼，這樣就很不安全了。我忽然想起來我玩遊戲的賬號是怎麼丟的了，是不是也是這樣呢？