建立整體的威脅模型，測試溢出漏洞、信息泄漏、錯誤處理、SQL 注入、身份驗證和授權錯誤.
- 1. 輸入驗證
客戶端驗證 服務器端驗證(禁用腳本調試，禁用Cookies)
1.輸入很大的數（如4,294,967,269），輸入很小的數(負數)
2.輸入超長字符,如對輸入文字長度有限制,則嘗試超過限制,剛好到達限制字數時有何反應
3.輸入特殊字符,如:~!@#$%^&*()_+<>:”{}|
4.輸入中英文空格，輸入字符串中間含空格，輸入首尾空格
5.輸入特殊字符串NULL,null，0x0d 0x0a
6.輸入正常字符串
7.輸入與要求不同類型的字符，如: 要求輸入數字則檢查正值,負值,零值（正零，負零）,小數,字母,空值; 要求輸入字母則檢查輸入數字
8.輸入html和javascript代碼
9.對於像回答數這樣需檢驗數字正確性的測試點，不僅對比其與問題最終頁的回答數，還要對回答進行添加刪除等操作後查看變化
例如：
1.輸入<html”>”gfhd</html>,看是否出錯；
2.輸入<input type=”text” name=”user”/>,看是否出現文本框；
3.輸入<script type=”text/javascript”>alert(“提示”)</script>看是否出現提示。
關於上傳：
1.上傳文件是否有格式限制,是否可以上傳exe文件；
2.上傳文件是否有大小限制,上傳太大的文件是否導致異常錯誤,上傳0K的文件是否會導致異常錯誤,上傳並不存在的文件是否會導致異常錯誤；
3.通過修改擴展名的方式是否可以繞過格式限制，是否可以通過壓包方式繞過格式限制；
4.是否有上傳空間的限制,是否可以超過空間所限制的大小,如將超過空間的大文件拆分上傳是否會出現異常錯誤。
5.上傳文件大小大於本地剩餘空間大小，是否會出現異常錯誤。
6.關於上傳是否成功的判斷。上傳過程中，中斷。程序是否判斷上傳是否成功。
7.對於文件名中帶有中文字符，特殊字符等的文件上傳。
上傳漏洞拿shell：
8.直接上傳asp.asa.jsp.cer.php.aspx.htr.cdx….之類的馬，拿到shell.
9.就是在上傳時在後綴後面加空格或者加幾點，也許也會有驚奇的發現。例：*.asp ,*.asp..。
10.利用雙重擴展名上傳例如：*.jpg.asa格式(也可以配上第二點一起利用)。
11.gif文件頭欺騙
12.同名重複上傳也很OK。：
下載：
- 避免輸入：\..\web.
- 修改命名後綴。
關於URL：
1.某些需登錄後或特殊用戶才能進入的頁面,是否可以通過直接輸入網址的方式進入；
2.對於帶參數的網址,惡意修改其參數,(若爲數字,則輸入字母,或很大的數字,或輸入特殊字符等)後打開網址是否出錯,是否可以非法進入某些頁面；
3.搜索頁面等url中含有關鍵字的,輸入html代碼或JavaScript看是否在頁面中顯示或執行。
4.輸入善意字符。
UBB:
[url=http://www.****.com] 你的網站[/url]
1.試着用各種方式輸入UBB代碼,比如代碼不完整,代碼嵌套等等.
2.在UBB代碼中加入屬性,如樣式,事件等屬性,看是否起作用
3.輸入編輯器中不存在的UBB代碼,看是否起作用
[url=javascript:alert('hello')]鏈接[/url]
[email=javascript:alert('hello')]EMail[/email]
[[email protected] STYLE="background-image: url(javascript:alert('XSS'))"][email protected][/email]
[img]http://www.13fun.cn/2007713015578593_03.jpg style="background-image:url(javascript:alert('alert(xss)'))"[/img]
[img]http://www.13fun.cn/photo/2007-7/2007713015578593_03.jpg "οnmοuseοver=alert('hello');"[/img]
[b STYLE="background-image: url(javascript:alert('XSS'))"]一首詩酸澀澀服務網[/b]
[i STYLE="background-image: url(javascript:alert('XSS'))"]一二三四五六七北京市[/i]
[u]一二三四五六七北京市[/u]
[font=微軟雅黑" STYLE="background-image: url(javascript:alert('XSS'))"]一二三四五六七北京市[/font]
[size=4" STYLE="background-image: url(javascript:alert('XSS'))"]一二三四五六七北京市[/size]
[color=Red" STYLE="background-image: url(javascript:alert('XSS'))"]一二三四五六七北京市[/color]
[align=center" STYLE="background-image: url(javascript:alert('XSS'))"]一二三四五六七北京市[/align]
[float=left" STYLE="background-image: url(javascript:alert('XSS'))"]一二三四五六七北京市[/float]
[font=微軟雅黑 STYLE="background-image: url(javascript:alert('XSS'))"]一二三四五六七北京市[/font]
[size=4 STYLE="background-image: url(javascript:alert('XSS'))"]一二三四五六七北京市[/size]
[color=Red STYLE="background-image: url(javascript:alert('XSS'))"]一二三四五六七北京市[/color]
[align=center STYLE="background-image: url(javascript:alert('XSS'))"]一二三四五六七北京市[/align]
[list=1]
[*]一二三四五六七北京市[/list]
[indent]一二三四五六七北京市[/indent]
[float=left STYLE="background-image: url(javascript:alert('XSS'))"]一二三四五六七北京市[/float]
[media=ra,400,300,0]http://bbsforblog.ikaka.com/posttopic.aspx?forumid=109[/media]
- 2. 輸出編碼
常用的測試輸入語句有：
<input type="text"/>
<input/>
<input/
<script>alert('hello');</script>
1.jpg" οnmοuseοver="alert('xss')
"></a><script>alert(‘xss’);</script>
http://xxx';alert('xss');var/ a='a
‘”>xss&<
a=”\” ; b=”;alert(/xss/);//”
<img src=“輸出內容” border=“0” alt=“logo” />
“’”
‘”’
“””
“ “ “
“”“
“‘ ”
title=””
對輸出數據到輸出數據的對比，看是否出現問題。
- 3. 防止SQL注入
Admin--
‘or --
‘ and ( ) exec insert * % chr mid
and 1=1 ; And 1=1 ; aNd 1=1 ; char(97)char(110)char(100) char(49)char(61)char(49) ; %20AND%201=2
‘and 1=1 ; ‘And 1=1 ; ‘aNd 1=1 ;
and 1=2 ; ‘and 1=2
and 2=2
and user>0
and (select count(*) from sysobjects)>0
and (select count(*) from msysobjects)>0
and (Select Count(*) from Admin)>=0
and (select top 1 len(username) from Admin)>0(username 已知字段)
;exec master..xp_cmdshell “net user name password /add”—
;exec master..xp_cmdshell “net localgroup name administrators /add”—
and 0<>(select count(*) from admin)
簡單的如where xtype=’U’，字符U對應的ASCII碼是85，所以可以用where xtype=char(85)代替；如果字符是中文的，比如where name=’用戶’，可以用where name=nchar(29992)+nchar(25143)代替。
- 4. 跨站腳本攻擊（XSS）
對於 XSS，只需檢查 HTML 輸出並看看您輸入的內容在什麼地方。它在一個 HREF 標記中嗎？是否在 IFRAME 標記中？它在 CLSID 標記中嗎？在 IMG SRC 中嗎？某些 Flash 內容的 PARAM NAME 是怎樣的？
★%3Cinput /%3E
★%3Cscript%3Ealert('XSS')%3C/script%3E
★<input type="text"/>
★<input/>
★<input/
★<script>alert('xss')</script>
★<script>alert('xss');</script>
★</script><script>alert(‘xss’)</script>
★javascript:alert(/xss/)
★javascript:alert(/xss/)
★<img src="#" οnerrοr=alert(/xss/)>
★<img src="#" style="Xss:expression(alert(/xss/));">
★<img src="#"/**/οnerrοr=alert(/xss/) width=100>
★=’><script>alert(document.cookie)</script>
★1.jpg" οnmοuseοver="alert('xss')
★"></a><script>alert(‘xss’);</script>
★http://xxx';alert('xss');var/ a='a
★’”>xss&<
★"οnmοuseοver=alert('hello');"
★&{alert('hello');}
★>"'><script>alert(‘XSS')</script>
★>%22%27><img%20src%3d%22javascript:alert(%27XSS%27)%22>
★>"'><img%20src%3D%26%23x6a;%26%23x61;%26%23x76;%26%23x61;%26%23x73;%26%23x63;%26%23x72;%26%23x69;%26%23x70;%26%23x74;%26%23x3a;alert(%26quot;XSS%26quot;)>
★AK%22%20style%3D%22background:url(javascript:alert(%27XSS%27))%22%20OS%22
★%22%2Balert(%27XSS%27)%2B%22
★<table background="javascript:alert(([code])"></table>
★<object type=text/html data="javascript:alert(([code]);"></object>
★<body οnlοad="javascript:alert(([code])"></body>
★a?<script>alert(’Vulnerable’)</script>
★<!--'">&:
var from = ‘$!rundata.Parameters.getString(’from’)';
var from = ”;hackerFunction(document.cookie);”;
http://searchbox.mapbar.com/publish/template/template1010/?CID=qingke&tid=tid1010&cityName=天津<script>alert("hello")</script>&nid=MAPBXITBJRQMYWJRXPCBX
- 5. 跨站請求僞造（CSRF）
同個瀏覽器打開兩個頁面，一個頁面權限失效後，另一個頁面是否可操作成功。
當頁面沒有CHECKCODE時，查看頁面源代碼，查是是否有token。如果頁面完全是展示頁面，是不會有token的。
一、 用戶註冊
只從用戶名和密碼角度寫了幾個要考慮的測試點，如果需求中明確規定了安全問題，Email，出生日期，地址，性別等等一系列的格式和字符要求，那就都要寫用例測了~
以等價類劃分和邊界值法來分析
1.填寫符合要求的數據註冊： 用戶名字和密碼都爲最大長度（邊界值分析，取上點）
2.填寫符合要求的數據註冊 ：用戶名字和密碼都爲最小長度（邊界值分析，取上點）
3.填寫符合要求的數據註冊：用戶名字和密碼都是非最大和最小長度的數據（邊界值分析，取內點）
4.必填項分別爲空註冊
5.用戶名長度大於要求註冊1位（邊界值分析，取離點）
6.用戶名長度小於要求註冊1位（邊界值分析，取離點）
7.密碼長度大於要求註冊1位（邊界值分析，取離點）
8.密碼長度小於要求註冊1位（邊界值分析，取離點）
9.用戶名是不符合要求的字符註冊（這個可以劃分幾個無效的等價類，一般寫一兩個就行了，如含有空格，#等，看需求是否允許吧~）
10.密碼是不符合要求的字符註冊（這個可以劃分幾個無效的等價類，一般寫一兩個就行了）
11.兩次輸入密碼不一致（如果註冊時候要輸入兩次密碼，那麼這個是必須的）
12.重新註冊存在的用戶
13.改變存在的用戶的用戶名和密碼的大小寫，來註冊。（有的需求是區分大小寫，有的不區分）
14.看是否支持tap和enter鍵等；密碼是否可以複製粘貼；密碼是否以* 之類的加祕符號顯示
備註：邊界值的上點、內點和離點大家應該都知道吧，呵呵，這裏我就不細說了~~
二、 修改密碼
當然具體情況具體分析哈~不能一概而論~
實際測試中可能只用到其中幾條而已，比如銀行卡密碼的修改，就不用考慮英文和非法字符，更不用考慮那些ＴＡＰ之類的快捷鍵。而有的需要根據需求具體分析了，比如連續出錯多少次出現的提示，和一些軟件修改密碼要求一定時間內有一定的修改次數限制等等。
1.不輸入舊密碼，直接改密碼
2.輸入錯誤舊密碼
3.不輸入確認新密碼
4.不輸入新密碼
5.新密碼和確認新密碼不一致
6.新密碼中有空格
7.新密碼爲空
8.新密碼爲符合要求的最多字符
9.新密碼爲符合要求的最少字符
10.新密碼爲符合要求的非最多和最少字符
11.新密碼爲最多字符-1
12.新密碼爲最少字符+1
13.新密碼爲最多字符+1
14.新密碼爲最少字符-1
15.新密碼爲非允許字符（如有的密碼要求必須是英文和數字組成，那麼要試漢字和符號等）
16.看是否支持tap和enter鍵等；密碼是否可以複製粘貼；密碼是否以* 之類的加祕符號
17.看密碼是否區分大小寫，新密碼中英文小寫，確認密碼中英文大寫
18.新密碼與舊密碼一樣能否修改成功
另外一些其他的想法如下：
1 要測試所有規約中約定可以輸入的特殊字符，字母，和數字，要求都可以正常輸入、顯示正常和添加成功
2 關注規約中的各種限制，比如長度，大否支持大小寫。
3 考慮各種特殊情況，比如添加同名用戶，系統是否正確校驗給出提示信息，管理員帳戶是否可以刪除，因爲有些系統管理員擁有最大權限，一旦刪除管理員帳戶，就不能在前臺添加，這給最終用戶會帶來很多麻煩。比較特殊的是，當用戶名中包括了特殊字符，那麼對這類用戶名的添加同名，修改，刪除，系統是否能夠正確實現，我就遇到了一個系統，添加同名用戶時，如果以前的用戶名沒有特殊字符，系統可以給出提示信息，如果以前的用戶名包含特殊字符，就不校驗在插入數據庫的時候報錯。後來查到原因了，原來是在java中拼SQL語句的時候，因爲有"_"，所以就調用了一個方法在“_”，前面加了一個轉義字符，後來發現不該調用這個方法。所以去掉就好了。所以對待輸入框中的特殊字符要多關注。
4 數值上的長度 之類的，包括出錯信息是否合理
5 特殊字符：比如。 / ' " \ </html> 這些是否會造成系統崩潰
6 注入式bug：比如密碼輸入個or 1=1
7 登錄後是否會用明文傳遞參數
8 訪問控制（不知道這個算不算）：登錄後保存裏面的鏈接，關了瀏覽器直接複製鏈接看能不能訪問。
輸入框測試
1．驗證輸入與輸出的是否信息一致；
2．輸入框之前的標題是否正確；
3．對特殊字符的處理，尤其是輸入信息徐需要發送到數據庫的。特殊字符包括：'（單引號）、"（雙引號）、[]（中括號）、()（小括號）、{}（大括號）、;（分號）、<>（大於小於號）……
4．對輸入框輸入超過限制的字符的處理，一般非特殊的沒有作出限制的在255byte左右；
5．輸入框本身的大小、長度；
6．不同內碼的字符的輸入；
7．對空格、TAB字符的處理機制；
8．字符本身顯示的顏色；
9．密碼輸入窗口轉換成星號或其它符號；
10．密碼輸入框對其中的信息進行加密，防止採用破解星號的方法破解；
11．按下ctrl和alt鍵對輸入框的影響；
12．對於新增、修改、註冊時用的輸入框，有限制的，應該輸入時作出提示，指出不允許的或者標出允許的；
13．對於有約束條件要求的輸入框應當在條件滿足時輸入框的狀態發生相應的改變，比如選了湖南就應該列出湖南下面的市，或者選了某些條件之後，一些輸入框會關閉或轉爲只讀狀態；
14．輸入類型；根據前面的欄位標題判斷該輸入框應該輸入哪些內容算是合理的。例如，是否允許輸入數字或字母，不允許輸入其他字符等。
15.輸入長度；數據庫字段有長度定義，當輸入過長時，提交數據是否會出錯。
16.輸入狀態；當處於某種狀態下，輸入框是否處於可寫或非可寫狀態。例如，系統自動給予的編號等欄位作爲唯一標識，當再次處於編輯狀態下，輸入框欄位應處於不可寫狀態，如果可寫對其編輯的話，可能會造成數據重複引起衝突等。
17．如果是會進行數據庫操作的輸入框，還可以考慮輸入SQL中的一些特殊符號如單引號等,有時會有意想不到的錯誤出現
18．輸入類型
輸入長度
是否允許複製粘貼
爲空的情況
空格的考慮
半角全角測試
對於密碼輸入框要考慮顯示的內容是* 輸入錯誤時的提示信息及提示信息是否準確
19．可以先了解你要測試的輸入框在軟件系統的某個功能中所扮演的角色，然後瞭解其具體的輸入條件，在將輸入條件按照有效等價類，無效等價類，邊界值等方法進行測試用例的設計。
20．關鍵字有大小寫混合的情況；
21．關鍵字中含有一個或多個空格的情況，包括前空格，中間空格（多個關鍵字），和後空格；
22．關鍵字中是否支持通配符的情況（視功能而定）；
23．關鍵字的長度分別爲9、10、11個字符時的情況；
24．關鍵字是valid，但是沒有匹配搜索結果的情況；
25．輸入html的標籤會出現哪些問題？輸入<html>會出現什麼問題呢？(這條是我自己發現的，在網上也沒找到類似的東東，呵呵，大家湊合着看吧)
安全測試方面：
給出一些特別的關鍵字，比如or 1=1, 這樣的關鍵字如果不被處理就直接用到數據庫查詢中去，後果可想而知。
用戶體驗相關
我登錄失敗的時候沒有任何提示，這沒什麼，反正提示也只是說失敗…
進去後發現顏色變更很強烈刺得我一眨眼，不過多看幾次就習慣了。
點擊某個鏈接的時候出現錯誤頁面，刷新後就好了，難道是隨機錯誤？
保存文字的時候沒有成功提示，不過能成功保存就算了。
瀏覽記錄的時候竟然出現錯誤頁面，原來我沒有選記錄就瀏覽了，我自己操作不規範嘛。
刪除記錄的時候發現選錯了，想取消的時候卻提示刪除成功，都沒有確認提示，只能下次看仔細點了。
查詢時字母鍵被茶杯壓住了多輸了點字符，竟然出現錯誤頁面，下次把東西整理好。
無聊隨便點點幾個鏈接，竟然沒有反應，既然不用，那就不要做出來嘛。
看看自己上傳的圖片效果如何，這個怎麼不顯示？多試幾次發現名字不包含中文就好了，下次注意下。
改改字體字號顏色美化環境嘛，怎麼格式那裏不顯示正確的字體字號呢，將就用吧。
這裏的記錄條數怎麼這麼多啊？原來是沒有刪除按鈕，看來下次不能隨便加了。
這個結束時間怎麼在開始時間前啊？原來沒有進行控制，下面的人執行時……還是自己改過來吧。
上次我在這裏看見的圖片呢？刷新後就出來了，怎麼和我玩捉迷藏呢？
多輸了點內容，保存時候提示太多了，點確定後發現被清空了，我一個小時的工作啊！
這張圖片真不錯，但是按鈕呢，按鈕呢？按鈕被擠掉了我怎麼編輯啊。
聽說F5是刷新點一下看看。怎麼好像變成了登錄界面？
剛學了怎麼用TAB鍵，確實很方便。TAB一下。跑哪去了，怎麼一片空白啊？？？
玩遊戲的人點擊速度那麼快，我也來試試。怎麼一雙擊就出錯了？
我找錯別字是很厲害的，這不就發現“同意”寫成了“統一”。
這裏提示只能輸入1－100，我偏要輸入9999……保存看看，怎麼系統不能用了？
這裏一點擊就出現IE錯誤，硬是不彈出我需要的窗口。
這個查詢按鈕怎麼灰掉了？這麼多記錄讓我一頁一頁翻過去找啊。
上傳第二個附件的時候怎麼把第一個擠掉了啊，會擠掉也要提示一下嘛。
一個頁面上打開的記錄太多了，變體都用…省略了，要是鼠標放上去浮動顯示完整標題就方便多了。
這幾條記錄有依存關係，刪了一條其他就沒了，提示都沒有，早知道我就用編輯了……
這條記錄怎麼好像是昨天的，我記得今天更新了啊？原來編輯後的記錄沒有傳到引用的地方。
最最奇怪的是昨天上傳時候正常的圖片今天就不能顯示了。我記得沒有隻能顯示一天的功能啊？？？
這裏怎麼沒有任何按鈕呢，看手冊才知道竟然要用右鍵進行操作，怎麼突然冒出個異類啊？？？
這裏怎麼能增加兩條相同的記錄呢？不控制一下天知道手下那些愣頭青會做出什麼來。
這裏的菜單一層一層又一層，足足有五層，把我頭都繞暈了……我記得哪裏說過最好不要超過三層的。
這個界面看起來怎麼這麼彆扭啊，是字體太大了，是按鈕太小了，還是功能太多了，……
怎麼不是管理員登錄進來也能管理啊，那我這個管理員的身份不是多此一舉嗎？
刪除的時候提示Error，幸虧我英語水平好，可是你換成中文不行嗎？
這條記錄不是刪除了嗎，怎麼還能引用啊，到時候出錯了怎麼辦，難道還要我記住刪了那些記錄？
經過精心編輯，我發了一條通知，怎麼用普通用戶查看的時候是默認的字體字號啊？？？
這幾個頁面上的當前日期怎麼是固定不變的啊，這都是去年的日期了，不會是開發時候的吧。
一、工具掃描
目前web安全掃描器針對 XSS、SQL injection 、OPEN redirect 、PHP File Include漏洞的檢測技術已經比較成熟。
商業軟件web安全掃描器：有IBM Rational Appscan、WebInspect、Acunetix WVS
免費的掃描器：W3af 、Skipfish 等等
可以考慮購買商業掃描軟件，也可以使用免費的，各有各的好處。
首先可以對網站進行大規模的掃描操作，工具掃描確認沒有漏洞或者漏洞已經修復後，再進行以下手工檢測。
二、手工檢測
1. 目錄遍歷
目錄遍歷產生的原因是：程序中沒有過濾用戶輸入的“../”和“./”之類的目錄跳轉符, 導致惡意用戶可以通過提交目錄跳轉來遍歷服務器上的任意文件。
測試方法：在URL中輸入一定數量的“../”和“./”，驗證系統是否ESCAPE掉了這些目錄跳轉符。
2. 登陸
(1) 是否正確登陸
(2) 密碼複雜度
(3) ...
3. 用戶權限
(1) 用戶權限控制
1) 用戶權限控制主要是對一些有權限控制的功能進行驗證
2) 用戶A才能進行的操作，B是否能夠進行操作（可通過竄session，將在下面介紹） 3）只能有A條件的用戶才能查看的頁面，是否B能夠查看（可直接敲URL訪問）
(2) 頁面權限控制
1） 必須有登陸權限的頁面，是否能夠在不登陸情況下進行訪問
2）必須經過A——B——C的頁面，是否能夠直接由A——C?
(3) ...
4. Cookie安全
(1) 屏蔽或刪除所有Cookie
(2) 有選擇性地屏蔽Cookie
(3) 篡改Cookie
(4) Cookie加密測試
(5) Cookie安全內容檢查
1) Cookie過期日期設置的合理性：檢查是否把Cookie的過期日期設置得過長。
2) HttpOnly屬性的設置：把Cookie的HttpOnly屬性設置爲True有助於緩解跨站點腳本威脅，防止Cookie被竊取。?
3) Secure屬性的設置：把Cookie的Secure屬性設置爲True，在傳輸Cookie時使用SSL連接，能保護數據在傳輸過程中不被篡改。 對於這些設置，可以利用Cookie?Editor來查看是否正確地被設置。
(6) ...
5. Session安全
(1) Session是客戶端與服務器端建立的會話，總是放在服務器上的，服務器會爲每次會話建立一個sessionId，每個客戶會跟一個sessionID 對應。 並不是關閉瀏覽器就結束了本次會話，通常是用戶執行“退出”操作或者會話超時時纔會結束。
(2) 測試關注點：
1) Session互竄
Session互竄即是用戶A的操作被用戶B執行了。 驗證Session互竄，其原理還是基於權限控制，如某筆訂單隻能是A進行操作，或者只能是A才能看到的頁面，但是B的session竄進來卻能夠獲得A的訂單詳情等。
Session互竄方法： 多TAB瀏覽器，在兩個TAB頁中都保留的是用戶A的session記錄，然後在其中一個TAB頁執行退出操作，登陸用戶B, 此時兩個TAB頁都是B的session，然後在另一個A的頁面執行操作，查看是否能成功。 預期結果：有權限控制的操作，B不能執行A頁面的操作，應該報錯，沒有權限控制的操作，B執行了A頁面 操作後，數據記錄是B的而不是A的。
2) Session超時
基於Session原理，需要驗證系統session是否有超時機制，還需要驗證session超時後功能是否還能繼續走下去。
測試方法： 1、打開一個頁面，等着10分鐘session超時時間到了，然後對頁面進行操作，查看效果。 2、多TAB瀏覽器，在兩個TAB頁中都保留的是用戶A的session記錄，然後在其中一個TAB頁執行退出操作，馬上在另外一個頁面進行要驗證的操作，查看是能繼續到下一步還是到登錄頁面。
3) ...
6. URL安全
(1) URL參數檢查
A: 對URL中參數信息檢查是否正確 如：URL中的訂單號、金額允許顯示出來的話，需要驗證其是否正確
B: 對於一些重要的參數信息，不應該在URL中顯示出來 如：用戶登陸時登錄名、密碼是否被顯示出來了.
(2) URL參數值篡改
修改URL中的數據，看程序是否能識別： 如：對於以下URL，修改其中planId，看是程序是否可以識別： http://pay.daily.taobao.net/mysub/plan/subplan/confirmSubPlanInfo.htm?planId=878 又如：對於URL中包含金額參數的，修改金額看是否能夠提交成功（可能導致用戶把2元金額改成1元金額能提交），還有修改訂單號等重要信息看是否會報錯
(3) URL中參數進行XSS注入
什麼是XSS？ XSS的全稱是Cross Site Script（跨站點腳本） XSS的原理很簡單，即進行腳本注入，URL執行時即把此腳本進行了執行，一般都是JavaScript腳本，如<script>alter(“abc”)<script> 在URL中進行XSS注入，也就是把URL中的參數改成JS腳本。
(4) URL參數中進行SQL 注入
什麼是SQL注入？ SQL注入全稱是SQL Injection ，當應用程序使用輸入內容來構造動態sql語句以訪問數據庫時，會發生sql注入攻擊，如查詢、插入數據時。
測試方法： URL中寫入SQL注入語句，看是否被執行，如：’or 1=1;shutdown
一般情況下要進行SQL注入攻擊，需要對數據庫類型、表名、判斷邏輯、查詢語句等比較清楚才能夠寫出有效的SQL注入語句。
(5) ...
7. 表單提交安全
(1) 表單中注入XSS腳本
測試方法：即在表單填寫框中直接注入JS腳本 如在表單中輸入XSS腳本，程序是不應該讓腳本執行的。
(2) 表單中注入SQL 腳本
(3) ...
8. 上傳文件安全
分析：上傳文件最好要有格式的限制；上傳文件還要有大小的限制。
9. 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，那他可能會給利用這個缺陷通過我們的平臺給其它用 戶發送垃圾郵件。
10. 不恰當的異常處理
分析：程序在拋出異常的時候給出了比較詳細的內部錯誤信息，暴露了不應該顯示的執行細節，網站存在潛在漏洞；
11. ...
WEB的安全性測試主要從以下方面考慮：
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 例子：在登錄時進行身份驗證時，通常使用如下語句來進行驗證：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',接下來的語句將按下一個查詢條件來執行 |
- 最後,驗證是否能入侵成功或是出錯的信息是否包含關於數據庫服務器 的相關信息;如果 能說明存在SQL安 全漏洞.
- 試想,如果網站存在SQL注入的危險,對於有經驗的惡意用戶還可能猜出數據庫表和表結構,並對數據庫表進行增\刪\改的操 作,這樣造成的後果是非常嚴重的.
(2)如何預防SQL注入?
從應用程序的角度來講,我們要做以下三項工作:
- 轉義敏感字符及字符串(SQL的敏感字符包括“exec”,”xp_”,”sp_”,”declare”,”Union”,”cmd”,”+”,”//”,”..”,”;”,”‘”,”--”,”%”,”0x”,”><=!-*/()|”,和”空格”).
- 屏蔽出錯信息：阻止攻擊者知道攻擊的結果
- 在服務端正式處理之前提交數據的合法性(合法性檢查主要包括三 項:數據類型,數據長度,敏感字符的校驗)進行檢查等。最根本的解決手段,在確認客 戶端的輸入合法之前,服務端拒絕進行關鍵性的處理操作.
從測試人員的角度來講,在程序開發前(即需求階段),我們就應該有意識的將安全性檢查應用到需求測試中,例如對一個表單需求進行檢查時,我們一般檢驗以下幾項安全性問題:
- 需求中應說明表單中某一FIELD的類型,長度,以及取值範圍(主要作用就是禁止輸入敏感字符)
- 需求中應說明如果超出表單規定的類型,長度,以及取值範圍的,應用程序應給出不包含任何代碼或數據庫信息的錯誤提示.
當然在執行測試的過程中,我們也需求對上述兩項內容進行測試.
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> |
- 最後,當用戶瀏覽 時便會彈出一個警告框，內容顯示的是瀏覽者當前的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
- 請 參見http://getahead.org/blog/joe/2007/01/01/csrf_attacks_or_how_to_avoid_exposing_your_gmail_contacts.html
4.Email HeaderInjection(郵件標頭注入)
Email Header Injection：如果表單用於發送email,表單中可能包括“subject”輸入項（郵件標題），我們要驗證subject中應能escape掉“\n”標識。
- <!--[if !supportLists]--><!--[endif]-->因爲“\n”是新行，如果在subject中輸入“hello\ncc:[email protected]”，可能會形成以下
Subject: hello
- <!--[if !supportLists]--><!--[endif]-->如果允許用戶使用這樣的subject，那他可能會給利用這個缺陷通過我們的平臺給其它用 戶發送垃圾郵件。
5.Directory Traversal(目錄遍歷)
（1）如何進行目錄遍歷測試？
- 目錄遍歷產生的原因是：程序中沒有過濾用戶輸入的“../”和“./”之類的目錄跳轉符,導致惡意用戶可以通過提交目錄跳轉來遍歷服務器上的任意文件。
- 測試方法：在URL中輸入一定數量的“../”和“./”，驗證系統是否ESCAPE掉了這些目錄跳轉符。
（2）如何預防目錄遍歷？
- 限制Web應用在服務器上的運行
- 進 行嚴格的輸入驗證，控制用戶輸入非法路徑
6.exposed errormessages(錯誤信息)
（1）如何進行測試？
- 首 先找到一些錯誤頁面，比如404,或500頁面。
- 驗證在調試未開通過的情況下，是否給出了友好的錯誤提示信息比如“你訪問的頁面不存 在”等，而並非曝露一些程序代碼。
（2）如何預防？
- 測試人員在進行需求檢查時，應該對出錯信息 進行詳細查，比如是否給出了出錯信息，是否給出了正確的出錯信息。
讓Web站點崩潰最常見的七大原因
磁盤已滿
導致系統無法正常運行的最可能的原因是磁盤已滿。一個好的網絡管理員會密切關注磁盤的使用情況，隔一定的時間，就需要將磁盤上的一些負載轉存到備份存儲介質中（例如磁帶）。
日誌文件會很快用光所有的磁盤空間。Web服務器的日誌文件、SQL*Net的日誌文件、JDBC日誌文件，以及應用程序服務器日誌文件均與內存泄漏有同等的危害。可以採取措施將日誌文件保存在與操作系統不同的文件系統中。日誌文件系統空間已滿時Web服務器也會被掛起，但機器自身被掛起的機率已大大減低。
C指針錯誤
用C或C++編寫的程序，如Web服務器API模塊，有可能導致系統的崩潰，因爲只要間接引用指針（即，訪問指向的內存）中出現一個錯誤，就會導致操作系統終止所有程序。另外，使用了糟糕的C指針的Java模擬量（analog）將訪問一個空的對象引用。Java中的空引用通常不會導致立刻退出JVM，但是前提是程序員能夠使用異常處理方法恰當地處理錯誤。在這方面，Java無需過多的關注，但使用 Java對可靠性進行額外的度量則會對性能產生一些負面影響。
內存泄漏
C/C++程序還可能產生另一個指針問題：丟失對已分配內存的引用。當內存是在子程序中被分配時，通常會出現這種問題，其結果是程序從子程序中返回時不會釋放內存。如此一來，對已分配的內存的引用就會丟失，只要操作系統還在運行中，則進程就會一直使用該內存。這樣的結果是，曾佔用更多的內存的程序會降低系統性能，直到機器完全停止工作，纔會完全清空內存。
解決方案之一是使用代碼分析工具（如Purify）對代碼進行仔細分析，以找出可能出現的泄漏問題。但這種方法無法找到由其他原因引起的庫中的泄漏，因爲庫的源代碼是不可用的。另一種方法是每隔一段時間，就清除並重啓進程。Apache的Web服務器就會因這個原因創建和清除子進程。
雖然Java本身並無指針，但總的說來，與C程序相比， Java程序使用內存的情況更加糟糕。在Java中，對象被頻繁創建，而直到所有到對象的引用都消失時，垃圾回收程序纔會釋放內存。即使運行了垃圾回收程序，也只會將內存還給虛擬機VM，而不是還給操作系統。結果是：Java程序會用光給它們的所有堆，從不釋放。由於要保存實時（Just InTime，JIT）編譯器產生的代碼，Java程序的大小有時可能會膨脹爲最大堆的數倍之巨。
還有一個問題，情況與此類似。從連接池分配一個數據庫連接，而無法將已分配的連接還回給連接池。一些連接池有活動計時器，在維持一段時間的靜止狀態之後，計時器會釋放掉數據庫連接，但這不足以緩解糟糕的代碼快速泄漏數據庫連接所造成的資源浪費。
進程缺乏文件描述符
如果已爲一臺Web服務器或其他關鍵進程分配了文件描述符，但它卻需要更多的文件描述符，則服務器或進程會被掛起或報錯，直至得到了所需的文件描述符爲止。文件描述符用來保持對開放文件和開放套接字的跟蹤記錄，開放文件和開放套接字是Web服務器很關鍵的組成部分，其任務是將文件複製到網絡連接。默認時，大多數shell有64個文件描述符，這意味着每個從shell啓動的進程可以同時打開64個文件和網絡連接。大多數shell都有一個內嵌的 ulimit命令可以增加文件描述符的數目。
線程死鎖
由多線程帶來的性能改善是以可靠性爲代價的，主要是因爲這樣有可能產生線程死鎖。線程死鎖時，第一個線程等待第二個線程釋放資源，而同時第二個線程又在等待第一個線程釋放資源。我們來想像這樣一種情形：在人行道上兩個人迎面相遇，爲了給對方讓道，兩人同時向一側邁出一步，雙方無法通過，又同時向另一側邁出一步，這樣還是無法通過。雙方都以同樣的邁步方式堵住了對方的去路。假設這種情況一直持續下去，這樣就不難理解爲何會發生死鎖現象了。
解決死鎖沒有簡單的方法，這是因爲使線程產生這種問題是很具體的情況，而且往往有很高的負載。大多數軟件測試產生不了足夠多的負載，所以不可能暴露所有的線程錯誤。在每一種使用線程的語言中都存在線程死鎖問題。由於使用Java進行線程編程比使用C容易，所以 Java程序員中使用線程的人數更多，線程死鎖也就越來越普遍了。可以在Java代碼中增加同步關鍵字的使用，這樣可以減少死鎖，但這樣做也會影響性能。如果負載過重，數據庫內部也有可能發生死鎖。
如果程序使用了永久鎖，比如鎖文件，而且程序結束時沒有解除鎖狀態，則其他進程可能無法使用這種類型的鎖，既不能上鎖，也不能解除鎖。這會進一步導致系統不能正常工作。這時必須手動地解鎖。
服務器超載
NetscapeWeb服務器的每個連接都使用一個線程。NetscapeEnterprise Web服務器會在線程用完後掛起，而不爲已存在的連接提供任何服務。如果有一種負載分佈機制可以檢測到服務器沒有響應，則該服務器上的負載就可以分佈到其它的 Web服務器上，這可能會致使這些服務器一個接一個地用光所有的線程。這樣一來，整個服務器組都會被掛起。操作系統級別可能還在不斷地接收新的連接，而應用程序（Web服務器）卻無法爲這些連接提供服務。用戶可以在瀏覽器狀態行上看到connected（已連接）的提示消息，但這以後什麼也不會發生。
解決問題的一種方法是將obj.conf參數RqThrottle的值設置爲線程數目之下的某個數值，這樣如果越過RqThrottle的值，就不會接收新的連接。那些不能連接的服務器將會停止工作，而連接上的服務器的響應速度則會變慢，但至少已連接的服務器不會被掛起。這時，文件描述符至少應當被設置爲與線程的數目相同的數值，否則，文件描述符將成爲一個瓶頸。
數據庫中的臨時表不夠用
許多數據庫的臨時表（cursor）數目都是固定的，臨時表即保留查詢結果的內存區域。在臨時表中的數據都被讀取後，臨時表便會被釋放，但大量同時進行的查詢可能耗盡數目固定的所有臨時表。這時，其他的查詢就需要列隊等候，直到有臨時表被釋放時才能再繼續運行。
這是一個不容易被程序員發覺的問題，但會在負載測試時顯露出來。但可能對於數據庫管理員（DataBaseAdministrator，DBA）來說，這個問題十分明顯。
此外，還存在一些其他問題：設置的表空間不夠用、序號限制太低，這些都會導致表溢出錯誤。這些問題表明了一個好的DBA對用於生產的數據庫設置和性能進行定期檢查的重要性。而且，大多數數據庫廠商也提供了監控和建模工具以幫助解決這些問題。
另外，還有許多因素也極有可能導致Web站點無法工作。如：相關性、子網流量超載、糟糕的設備驅動程序、硬件故障、包括錯誤文件的通配符、無意間鎖住了關鍵的表。
如何做好網站的安全性測試
安全性保護數據以防止不合法用戶故意造成的破壞；
完整性保護數據以防止合法用戶無意中造成的破壞；
安全性測試（security testing）是有關驗證應用程序的安全服務和識別潛在安全性缺陷的過程。
注意：安全性測試並不最終證明應用程序是安全的，而是用於驗證所設立策略的有效性，這些對策是基於威脅分析階段所做的假設而選擇的。
一個完整的WEB安全性測試可以從部署與基礎結構、輸入驗證、身份驗證、授權、配置管理、敏感數據、會話管理、加密。參數操作、異常管理、審覈和日誌記錄等幾個方面入手。
1.安全體系測試
1)部署與基礎結構
網絡是否提供了安全的通信
部署拓撲結構是否包括內部的防火牆
部署拓撲結構中是否包括遠程應用程序服務器
基礎結構安全性需求的限制是什麼
目標環境支持怎樣的信任級別
2)輸入驗證
l如何驗證輸入
A.是否清楚入口點
B.是否清楚信任邊界
C.是否驗證Web頁輸入
D.是否對傳遞到組件或Web服務的參數進行驗證
E.是否驗證從數據庫中檢索的數據
F.是否將方法集中起來
G.是否依賴客戶端的驗證
H.應用程序是否易受SQL注入攻擊
I.應用程序是否易受XSS攻擊
l如何處理輸入
3)身份驗證
是否區分公共訪問和受限訪問
是否明確服務帳戶要求
如何驗證調用者身份
如何驗證數據庫的身份
是否強制試用帳戶管理措施
4)授權
如何向最終用戶授權
如何在數據庫中授權應用程序
如何將訪問限定於系統級資源
5)配置管理
是否支持遠程管理
是否保證配置存儲的安全
是否隔離管理員特權
6)敏感數據
是否存儲機密信息
如何存儲敏感數據
是否在網絡中傳遞敏感數據
是否記錄敏感數據
7)會話管理
如何交換會話標識符
是否限制會話生存期
如何確保會話存儲狀態的安全
8)加密
爲何使用特定的算法
如何確保加密密鑰的安全性
9)參數操作
是否驗證所有的輸入參數
是否在參數過程中傳遞敏感數據
是否爲了安全問題而使用HTTP頭數據
10)異常管理
是否使用結構化的異常處理
是否向客戶端公開了太多的信息
11)審覈和日誌記錄
是否明確了要審覈的活動
是否考慮如何流動原始調用這身份
2.應用及傳輸安全
WEB應用系統的安全性從使用角度可以分爲應用級的安全與傳輸級的安全，安全性測試也可以從這兩方面入手。
應用級的安全測試的主要目的是查找Web系統自身程序設計中存在的安全隱患，主要測試區域如下。
註冊與登陸：現在的Web應用系統基本採用先註冊，後登錄的方式。
A.必須測試有效和無效的用戶名和密碼
B.要注意是否存在大小寫敏感，
C.可以嘗試多少次的限制
D.是否可以不登錄而直接瀏覽某個頁面等。
在線超時：Web應用系統是否有超時的限制，也就是說，用戶登陸一定時間內（例如15分鐘）沒有點擊任何頁面，是否需要重新登陸才能正常使用。
操作留痕：爲了保證Web應用系統的安全性，日誌文件是至關重要的。需要測試相關信息是否寫進入了日誌文件，是否可追蹤。
備份與恢復：爲了防範系統的意外崩潰造成的數據丟失，備份與恢復手段是一個Web系統的必備功能。備份與恢復根據Web系統對安全性的要求可以採用多種手段，如數據庫增量備份、數據庫完全備份、系統完全備份等。出於更高的安全性要求，某些實時系統經常會採用雙機熱備或多級熱備。除了對於這些備份與恢復方式進行驗證測試以外，還要評估這種備份與恢復方式是否滿足Web系統的安全性需求。
傳輸級的安全測試是考慮到Web系統的傳輸的特殊性，重點測試數據經客戶端傳送到服務器端可能存在的安全漏洞，以及服務器防範非法訪問的能力。一般測試項目包括以下幾個方面。
HTTPS和SSL測試：默認的情況下，安全HTTP（Soure HTTP）通過安全套接字SSL（Source Socket Layer）協議在端口443上使用普通的HTTP。HTTPS使用的公共密鑰的加密長度決定的HTTPS的安全級別，但從某種意義上來說，安全性的保證是以損失性能爲代價的。除了還要測試加密是否正確，檢查信息的完整性和確認HTTPS的安全級別外，還要注意在此安全級別下，其性能是否達到要求。
服務器端的腳本漏洞檢查：存在於服務器端的腳本常常構成安全漏洞，這些漏洞又往往被黑客利用。所以，還要測試沒有經過授權，就不能在服務器端放置和編輯腳本的問題。
防火牆測試：防火牆是一種主要用於防護非法訪問的路由器，在Web系統中是很常用的一種安全系統。防火牆測試是一個很大很專業的課題。這裏所涉及的只是對防火牆功能、設置進行測試，以判斷本Web系統的安全需求。
另推薦安全性測試工具：
Watchfire AppScan：商業網頁漏洞掃描器(此工具好像被IBM收購了，所以推薦在第一位)
AppScan按照應用程序開發生命週期進行安全測試，早在開發階段就進行單元測試和安全保證。Appscan能夠掃描多種常見漏洞，例如跨網站腳本、HTTP應答切開、參數篡改、隱藏值篡改、後門/調試選項和緩衝區溢出等等。
Acunetix Web Vulnerability Scanner：商業漏洞掃描器
Acunetix WVS自動檢查您的網頁程序漏洞，例如SQL注入、跨網站腳本和驗證頁面弱密碼破解。Acunetix WVS有着非常友好的用戶界面，還可以生成個性化的網站安全評估報告。
黑盒主要測試點
用戶管理模塊，權限管理模塊，加密系統，認證系統等
工具使用
Appscan（首要）、Acunetix Web Vulnerability Scanner（備用）、HttpAnalyzerFull、TamperIESetup
木桶原理
安全性最低的模塊將成爲瓶頸，需整體提高
（一）可手工執行或工具執行
輸入的數據沒有進行有效的控制和驗證
用戶名和密碼
直接輸入需要權限的網頁地址可以訪問
上傳文件沒有限制（此次不需要）
不安全的存儲
操作時間的失效性
1.1）輸入的數據沒有進行有效的控制和驗證
數據類型（字符串，整型，實數，等）
允許的字符集
最小和最大的長度
是否允許空輸入
參數是否是必須的
重複是否允許
數值範圍
特定的值（枚舉型）
特定的模式（正則表達式）（注：建議儘量採用白名單）
1.22）用戶名和密碼-2
檢測接口程序連接登錄時，是否需要輸入相應的用戶
是否設置密碼最小長度（密碼強度）
用戶名和密碼中是否可以有空格或回車？
是否允許密碼和用戶名一致
防惡意註冊：可否用自動填表工具自動註冊用戶？ （傲遊等）
遺忘密碼處理
有無缺省的超級用戶?（admin等，關鍵字需屏蔽）
有無超級密碼?
是否有校驗碼？
密碼錯誤次數有無限制？
大小寫敏感？
口令不允許以明碼顯示在輸出設備上
強制修改的時間間隔限制（初始默認密碼）
口令的唯一性限制（看需求是否需要）
口令過期失效後，是否可以不登陸而直接瀏覽某個頁面
哪些頁面或者文件需要登錄後才能訪問/下載
cookie中或隱藏變量中是否含有用戶名、密碼、userid等關鍵信息
1.3）直接輸入需要權限的網頁地址可以訪問
避免研發只是簡單的在客戶端不顯示權限高的功能項
舉例Bug：
沒有登錄或註銷登錄後，直接輸入登錄後才能查看的頁面的網址（含跳轉頁面），能直接打開頁面；
註銷後，點瀏覽器上的後退，可以進行操作。
正常登錄後，直接輸入自己沒有權限查看的頁面的網址，可以打開頁面。
通過Http抓包的方式獲取Http請求信息包經改裝後重新發送
從權限低的頁面可以退回到高的頁面（如發送消息後，瀏覽器後退到信息填寫頁面，這就是錯誤的）
1.4）上傳文件沒有限制（此次不需要）
傳文件還要有大小的限制。
上傳木馬病毒等（往往與權限一起驗證）
上傳文件最好要有格式的限制；
1.5）不安全的存儲
在頁面輸入密碼，頁面應顯示 “*****”；
數據庫中存的密碼應經過加密；
地址欄中不可以看到剛纔填寫的密碼；
右鍵查看源文件不能看見剛纔輸入的密碼；
帳號列表：系統不應該允許用戶瀏覽到網站所有的帳號，如果必須要一個用戶列表，推薦使用某種形式的假名（屏幕名）來指向實際的帳號
1.6）操作時間的失效性
檢測系統是否支持操作失效時間的配置，同時達到所配置的時間內沒有對界面進行任何操作時，檢測系統是否會將用戶自動失效，需要重新登錄系統。
支持操作失效時間的配置。
支持當用戶在所配置的時間內沒有對界面進行任何操作則該應用自動失效。
如，用戶登陸後在一定時間內（例如15 分鐘）沒有點擊任何頁面，是否需要重新登陸才能正常使用。
（二）藉助工具或瞭解後手工來進行測試
不能把數據驗證寄希望於客戶端的驗證
不安全的對象引用，防止XSS攻擊
注入式漏洞（SQL注入）
傳輸中與存儲時的密碼沒有加密 ，不安全的通信
目錄遍歷
2.1）不能把數據驗證寄希望於客戶端的驗證
避免繞過客戶端限制（如長度、特殊字符或腳本等），所以在服務器端驗證與限制
客戶端是不安全，重要的運算和算法不要在客戶端運行。
Session與cookie
例：保存網頁並對網頁進行修改，使其繞過客戶端的驗證。
（如只能選擇的下拉框，對輸入數據有特殊要求的文本框）
還可以查看cookie中記錄，僞造請求
測試中，可使用TamperIESetup來繞過客戶端輸入框的限制
2.21）不安全的對象引用，防止XSS等攻擊
阻止帶有語法含義的輸入內容，防止Cross Site Scripting (XSS) Flaws 跨站點腳本攻擊（XSS）
防止Cross-site request forgery（CSRF）跨站請求僞造
xss解釋：不可信的內容被引入到動態頁面中，沒有識別這種情況並採取保護措施。攻擊者可在網上提交可以完成攻擊的腳本，普通用戶點擊了網頁上這些攻擊者提交的腳本，那麼就會在用戶客戶機上執行，完成從截獲帳戶、更改用戶設置、竊取和篡改 cookie 到虛假廣告在內的種種攻擊行爲
測試方法：在輸入框中輸入下列字符，可直接輸入腳本來看
HTML標籤：<…>…</…>
轉義字符：&(&)；<(<)；>(>)； (空格) ；
腳本語言：<script>alert(document.cookie);</script>
特殊字符：‘ ’ <>/
最小和最大的長度
是否允許空輸入
對Grid、Label、Tree view類的輸入框未作驗證，輸入的內容會按照html語法解析出來，要控制腳本注入的語法要素。比如：javascript離不開：“<”、“>”、“(”、“）”、“;”. 在輸入或輸出時對其進行字符過濾或轉義處理
2.23）注入式漏洞（SQL注入）
對數據庫等進行注入攻擊。
例：一個驗證用戶登陸的頁面，
如果使用的sql語句爲：
Select * from table A
where username＝’’ + username+’’ and pass word …..
則在Sql語句後面輸入 ‘ or 1＝1 ―― 就可以不輸入任何password進行攻擊
SELECT count(*)
FROM users
WHERE username='a' or 'a'='a' AND password='a' or 'a'='a'
(資料太多，不顯示了此處，藉助工具Appscan等吧)
2.24）傳輸中與存儲時的密碼沒有加密
利用ssl來進行加密，在位於HTTP層和TCP層之間，建立用戶與服務器之間的加密通信
進入一個SSL站點後，可以看到瀏覽器出現警告信息，然後地址欄的http變成https （特點確定）
證書認證
————————————————————————
檢查數據庫中的用戶密碼、管理者密碼等字段是否是以加密方式保存。
存儲數據庫單獨隔離，有備份的數據庫，權限唯一
2.25）目錄遍歷
舉例：
http://love.ah163.net/Personal_Spaces_List.php?dir=MyFolder
那現在把這個ＵＲＬ改裝一下：
http://love.ah163.net/Personal_S ... /local/apache/conf/
/usr/local/apache/conf/裏的所有文件都出來了
簡要的解決方案:
１、限制Web應用在服務器上的運行 ，格設定WEB服務器的目錄訪問權限
２、進行嚴格的輸入驗證，控制用戶輸入非法路徑，如在每個目錄訪問時有index.htm
（三）研發或使用工具才能進行
認證和會話數據不能作爲GET的一部分來發送
隱藏域與CGI參數
不恰當的異常處理
不安全的配置管理
緩衝區溢出
拒絕服務
日誌完整性、可審計性與可恢復性
3.1）Get or post
認證和會話數據不應該作爲GET的一部分來發送，應該使用POST
例：對Grid、Label、Tree view類的輸入框未作驗證，輸入的內容會按照html語法解析出來
可使用TamperIESetup或ScannerHttpAnalyzerFull來判斷
3.2）隱藏域與CGI參數
Bug舉例：
分析：隱藏域中泄露了重要的信息，有時還可以暴露程序原代碼。
直接修改CGI參數，就能繞過客戶端的驗證了。
如：<inputtype="hidden" name="h" value="http://XXX/checkout.php">
只要改變value的值就可能會把程序的原代碼顯示出來。
如大小寫，編碼解碼，附加特殊字符或精心構造的特殊請求等都可能導致CGI源代碼泄露
可使用appscan或sss等來檢測，檢查特殊字符集
3.3）不恰當的異常處理
分析：程序在拋出異常的時候給出了比較詳細的內部錯誤信息，暴露了不應該顯示的執行細節，網站存在潛在漏洞，有可能會被攻擊者分析出網絡環境的結構或配置
通常爲其他攻擊手段的輔助定位方式
舉例：如www.c**w.com ，搜索爲空時，，數據庫顯示出具體錯誤位置，可進行sql注入攻擊或關鍵字猜測攻擊
3.4）不安全的配置管理
分析：Config中的鏈接字符串以及用戶信息，郵件，數據存儲信息都需要加以保護
配置所有的安全機制，
關掉所有不使用的服務，
設置角色權限帳號，
使用日誌和警報。
手段：用戶使用緩衝區溢出來破壞web應用程序的棧，通過發送特別編寫的代碼到web程序中，攻擊者可以讓web應用程序來執行任意代碼
例：數據庫的帳號是不是默認爲“sa”，密碼（還有端口號）是不是直接寫在配置文件裏而沒有進行加密。
3.5）緩衝區溢出
WEB服務器沒有對用戶提交的超長請求沒有進行合適的處理，這種請求可能包括超長URL，超長HTTP Header域，或者是其它超長的數據
使用類似於“strcpy()，strcat()”不進行有效位檢查的函數，惡意用戶編寫一小段程序來進一步打開安全缺口，然後將該代碼放在緩衝區有效載荷末尾，這樣，當發生緩衝區溢出時，返回指針指向惡意代碼
用戶使用緩衝區溢出來破壞web應用程序的棧，通過發送特別編寫的代碼到web程序中，攻擊者可以讓web應用程序來執行任意代碼。
如apach緩衝區溢出等錯誤，第三方軟件也需檢測
3.6）拒絕服務
手段：超長URL，特殊目錄，超長HTTP Header域，畸形HTTP Header域或者是DOS設備文件
分析：攻擊者可以從一個主機產生足夠多的流量來耗盡狠多應用程序，最終使程序陷入癱瘓。需要做負載均衡來對付。
詳細如：死亡之ping、淚滴（Teardorop）、 UDP洪水（UDP Flood）、 SYN洪水（SYN Flood）、 Land攻擊、Smurf攻擊、Fraggle攻擊、 畸形消息攻擊
3.7）日誌完整性。可審計性與可恢復性
服務器端日誌：檢測系統運行時是否會記錄完整的日誌。
如進行詳單查詢，檢測系統是否會記錄相應的操作員、操作時間、系統狀態、操作事項、IP地址等
檢測對系統關鍵數據進行增加、修改和刪除時，系統是否會記錄相應的修改時間、操作人員和修改前的數據記錄。
工具篇
Watchfire Appscan——全面自動測試工具
Acunetix Web Vulnerability ——全面自動測試工具
ScannerHttpAnalyzerFull——加載網頁時可判斷
TamperIESetup——提交表單時改造數據
注：上述工具最好安裝在虛擬機中，不影響實際機環境
Appscan、 Web Vulnerability 需安裝.net framework，可能與sniffer衝突
ScannerHttpAnalyzerFul與TamperIESetup會影響實際機瀏覽器平時的功能測試