WEB的安全性測試主要從以下方面考慮：
1.SQL Injection(SQL注入)
(1)如何進行SQL注入測試?
首先找到帶有參數傳遞的URL頁面,如 搜索頁面,登錄頁面,提交評論頁面等等.
注1:對 于未明顯標識在URL中傳遞參數的,可以通過查看HTML源代碼中的"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://duck/index.asp?username=admin'
or 1='1&pwd=11，SQL語句會變成以下：sql=select * from user where? username='admin' or 1='1' and password='11'
' 與admin前面的'組成了一個查詢條件,即username='admin',接下來的語句將按下一個查詢條件來執行.
接 下來是OR查詢條件,OR是一個邏輯運 算符，在判斷多個條件的時候，只要一個成立，則等式就成立，后面的AND就不再時行判斷了，也就是 說我們繞過了密碼驗證，我們只用用戶名就可以登錄.
如 輸入http://duck/index.asp?username=admin'--&pwd=11，SQL語 句會變成以下sql=select * from? user where name='admin' --' and pasword='11',
'與admin前面的'組成了一個查 詢條件,即username='admin',接下來的語句將按下一個查詢條件來執行
接下來是"--"查詢條件,“--”是忽略或注釋,上 述通過連接符注釋掉后面的密碼驗證(注:對ACCESS數據庫無 效).
最后,驗證是否能入侵成功或是出錯的信息是否包含關于數據庫服務器
的相關信息;如果 能說明存在SQL安 全漏洞.
試想,如果網站存在SQL注入的危險,對于有經驗的惡意用戶還可能猜出數據庫表和表結構,并對數據庫表進行增\刪\改的操
作,這樣造成的后果是非常嚴重的.
(2)如何預防SQL注入?
從應用程序的角度來講,我們要做以下三項工作:
轉義敏感字符及字符串(SQL的敏感字符包括“exec”,”xp_”,”sp_”,”declare”,”Union”,”cmd”,”+”,”//”,”..”,”;”,”‘”,”--”,”%”,”0x”,”><=!-*/()|”,和”空格”).
屏蔽出錯信息：阻止攻擊者知道攻擊的結果
在服務端正式處理之前提交數據的合法性(合法性檢查主要包括三 項:數據類型,數據長度,敏感字符的校驗)進行檢查等。最根本的解決手段,在確認客 戶端的輸入合法之前,服務端拒絕進行關鍵性的處理操作.
從測試人員的角度來講,在程序開發前(即需求階段),我們就應該有意識的將安全性檢查應用到需求測試中,例如對一個表單需求進行檢查時,我們一般檢驗以下幾項安全性問題:
需求中應說明表單中某一FIELD的類型,長度,以及取值范圍(主要作用就是禁止輸入敏感字符)
需求中應說明如果超出表單規定的類型,長度,以及取值范圍的,應用程序應給出不包含任何代碼或數據庫信息的錯誤提示.
當然在執行測試的過程中,我們也需求對上述兩項內容進行測試.
2.Cross-site scritping(XSS):(跨站點腳本攻擊)
(1)如何進行XSS測試?
!supportLists]-->首先,找到帶有參數傳遞的URL,如 登錄頁面,搜索頁面,提交評論,發表留言 頁面等等。
!supportLists]-->其次,在頁面參數中輸入如下語句(如:Javascrīpt,VB scrīpt, HTML,ActiveX, Flash)來進行測試：
alert(document.cookie)
最后,當用戶瀏覽 時便會彈出一個警告框，內容顯示的是瀏覽者當前的cookie串,這就說明該網站存在XSS漏洞。
試想如果我們注入的不是以上這個簡單的測試代碼，而是一段經常精心設計的惡意腳本，當用戶瀏覽此帖時，cookie信息就可能成功的被 攻擊者獲取。此時瀏覽者的帳號就很容易被攻擊者掌控了。
(2)如何預防XSS漏洞?
從應用程序的角度來講,要進行以下幾項預防:
對Javascrīpt,VB scrīpt, HTML,ActiveX, Flash等 語句或腳本進行轉義.
在 服務端正式處理之前提交數據的合法性(合法性檢查主要包括三項:數據類型,數據長度,敏感字符的校驗)進行檢查等。最根本的解決手段,在確認客戶端的輸入合法之前,服務端 拒絕進行關鍵性的處理操作.
從測試人員的角度來講,要從需求檢查和執行測試過程兩個階段來完成XSS檢查:
在需求檢查過程中對各輸入項或輸出項進行類型、長度以及取 值范圍進行驗證，著重驗證是否對HTML或腳本代碼進行了轉義。
執行測試過程中也應對上述項進行檢查。
3.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
4.Email Header
Injection(郵件標頭注入)
Email Header Injection：如果表單用于發送email,表單中可能包括“subject”輸入項（郵件標題），我們要驗證subject中應能escape掉“\n”標識。
!supportLists]-->因為“\n”是新行，如果在subject中輸入“hello\ncc:spamvictim@example.com”，可能會形成以下
Subject: hello
cc: spamvictim@example.com
如果允許用戶使用這樣的subject，那他可能會給利用這個缺陷通過我們的平臺給其它用 戶發送垃圾郵件。
5.Directory Traversal(目錄遍歷)
（1）如何進行目錄遍歷測試？
目錄遍歷產生的原因是：程序中沒有過濾用戶輸入的“../”和“./”之類的目錄跳轉符,導致惡意用戶可以通過提交目錄跳轉來遍歷服務器上的任意文件。
測試方法：在URL中輸入一定數量的“../”和“./”，驗證系統是否ESCAPE掉了這些目錄跳轉符。
（2）如何預防目錄遍歷？
限制Web應用在服務器上的運行
進 行嚴格的輸入驗證，控制用戶輸入非法路徑
6.exposed error
messages(錯誤信息)
（1）如何進行測試？
首 先找到一些錯誤頁面，比如404,或500頁面。
驗證在調試未開通過的情況下，是否給出了友好的錯誤提示信息比如“你訪問的頁面不存 在”等，而并非曝露一些程序代碼。
（2）如何預防？
測試人員在進行需求檢查時，應該對出錯信息 進行詳細查，比如是否給出了出錯信息，是否給出了正確的出錯信息。
