BS架構(gòu)體系安全滲透測(cè)試基礎(chǔ)2023/12/27BS架構(gòu)體系安全滲透測(cè)試基礎(chǔ)內(nèi)容概要前言當(dāng)今世界，Internet（因特網(wǎng)）已經(jīng)成為一個(gè)非常重要的基礎(chǔ)平臺(tái)，很多企業(yè)都將應(yīng)用架設(shè)在該平臺(tái)上，為客戶提供更為方便、快捷的服務(wù)支持。這些應(yīng)用在功能和性能上，都在不斷的完善和提高，然而在非常重要的安全性上，卻沒(méi)有得到足夠的重視。由于網(wǎng)絡(luò)技術(shù)日趨成熟，黑客們也將注意力從以往對(duì)網(wǎng)絡(luò)服務(wù)器的攻擊逐步轉(zhuǎn)移到了對(duì)Web應(yīng)用的攻擊上。根據(jù)最新調(diào)查，信息安全攻擊有75%都是發(fā)生在Web應(yīng)用而非網(wǎng)絡(luò)層面上。同時(shí)，數(shù)據(jù)也顯示，三分之二的Web站點(diǎn)都相當(dāng)脆弱，易受攻擊。就公司以前WEB項(xiàng)目外部應(yīng)用的現(xiàn)狀：90%的網(wǎng)站都受到過(guò)類似SQL注入等黑客的攻擊。BS架構(gòu)體系安全滲透測(cè)試基礎(chǔ)管理部分內(nèi)容索引B/S架構(gòu)常見(jiàn)安全問(wèn)題BS架構(gòu)體系安全滲透測(cè)試基礎(chǔ)B/S架構(gòu)常見(jiàn)安全問(wèn)題當(dāng)討論起Web應(yīng)用安全，我們經(jīng)常會(huì)聽(tīng)到這樣的回答：

“我們使用了防火墻”、“我們使用了網(wǎng)絡(luò)脆弱掃描工具”、“我們使用了SSL技術(shù)”……所以，“我們的應(yīng)用是安全的”?，F(xiàn)實(shí)真是如此嗎？讓我們一起來(lái)看一下Web應(yīng)用安全的全景圖。BS架構(gòu)體系安全滲透測(cè)試基礎(chǔ)為何要進(jìn)行安全測(cè)試但是，即便有防病毒保護(hù)、防火墻和SSL，企業(yè)仍然不得不允許一部分的通訊經(jīng)過(guò)防火墻，畢竟Web應(yīng)用的目的是為用戶提供服務(wù)，保護(hù)措施可以關(guān)閉不必要暴露的端口，但是Web應(yīng)用必須的80和443端口，是一定要開(kāi)放的?？梢皂樌ㄟ^(guò)的這部分通訊，可能是善意的，也可能是惡意的，很難辨別。這里需要注意的是，Web應(yīng)用是由軟件構(gòu)成的，那么，它一定會(huì)包含缺陷（bugs），這些bug就可以被惡意的用戶利用，他們通過(guò)執(zhí)行各種惡意的操作，或者偷竊、或者操控、或者破壞Web應(yīng)用中的重要信息。只要訪問(wèn)可以順利通過(guò)企業(yè)的防火墻，Web應(yīng)用就毫無(wú)保留的呈現(xiàn)在用戶面前。只有加強(qiáng)Web應(yīng)用自身的安全，才是真正的Web應(yīng)用安全解決之道。BS架構(gòu)體系安全滲透測(cè)試基礎(chǔ)風(fēng)險(xiǎn)性較高的攻擊方法“跨站點(diǎn)腳本攻擊”和“注入缺陷攻擊”，是目前Web應(yīng)用中比例最高的兩種攻擊手段，還有如下八種風(fēng)險(xiǎn)性較高的攻擊方法：MaliciousFileExecution（惡意文件執(zhí)行）；InsecureDirectObjectReference（不安全的直接對(duì)象引用）；Cross-SiteRequestForgery（跨站點(diǎn)的請(qǐng)求偽造）；InformationLeakageandImproperErrorHandling（信息泄漏和不正確的錯(cuò)誤處理）；BrokenAuthentication&SessionManagement（損壞的認(rèn)證和Session管理）；InsecureCryptographicStorage（不安全的密碼存儲(chǔ)）；InsecureCommunications（不安全的通信）；FailuretoRestrictURLAccess（未能限制URL訪問(wèn)）在這里，我簡(jiǎn)單介紹下這些缺陷BS架構(gòu)體系安全滲透測(cè)試基礎(chǔ)常見(jiàn)的Web應(yīng)用攻擊示例1、跨站點(diǎn)腳本攻擊（cross-sitescrīpting，簡(jiǎn)稱XSS），首先來(lái)看一下跨站點(diǎn)腳本的利用過(guò)程，如圖。BS架構(gòu)體系安全滲透測(cè)試基礎(chǔ)在上圖中，惡意攻擊者（這里使用E表示）通過(guò)E-mail或HTTP將某銀行的網(wǎng)址鏈接發(fā)給用戶（銀行用表示），該鏈接中附加了惡意的腳本（上圖步驟一）；用戶訪問(wèn)發(fā)來(lái)的鏈接，進(jìn)入銀行網(wǎng)站，同時(shí)，嵌在鏈接中的腳本被用戶的瀏覽器執(zhí)行（上圖步驟二、三）；用戶在銀行網(wǎng)站的所有操作，包括用戶的cookie和session信息，都被腳本收集到，并且在用戶毫不知情的情況下發(fā)送給惡意攻擊者（上圖步驟四）；惡意攻擊者使用偷來(lái)的session信息，偽裝成該用戶，進(jìn)入銀行網(wǎng)站，進(jìn)行非法活動(dòng)（上圖步驟五）。因此，只要Web應(yīng)用中，有可被惡意攻擊者利用執(zhí)行腳本的地方，都存在極大的安全隱患。黑客們?nèi)绻梢宰層脩魣?zhí)行他們提供的腳本，就可以從用戶正在瀏覽的域中偷到他的個(gè)人信息、可以完全修改用戶看到的頁(yè)面內(nèi)容、跟蹤用戶在瀏覽器中的每一個(gè)動(dòng)作，甚至利用用戶瀏覽器的缺陷完全控制用戶的機(jī)器。目前，跨站點(diǎn)腳本攻擊是最大的安全風(fēng)險(xiǎn)。BS架構(gòu)體系安全滲透測(cè)試基礎(chǔ)檢查您的站點(diǎn)是否處于XSS攻擊保護(hù)的方法

檢查站點(diǎn)的確安全也可以通過(guò)手工完成（硬方法），或利用自動(dòng)的Web應(yīng)用程序安全漏洞評(píng)估工具(如appscan)，它減輕了檢查的負(fù)擔(dān)。該工具爬遍站點(diǎn)，然后根據(jù)嘗試參數(shù)、頭，和路徑找到的所有腳本，運(yùn)行其知道的所有變化。在這兩種方法中，用盡可能多的方式檢查對(duì)應(yīng)用程序的每個(gè)輸入（所有腳本的參數(shù)、HTTP頭、路徑）。如果響應(yīng)頁(yè)面包含瀏覽器可以執(zhí)行的Javascrīpt代碼，那么XSS安全漏洞就已顯露出來(lái)。舉例來(lái)說(shuō)，首先,找到帶有參數(shù)傳遞的URL,如登錄頁(yè)面,搜索頁(yè)面,提交評(píng)論,發(fā)表留言頁(yè)面等等。其次,在頁(yè)面參數(shù)中輸入如下語(yǔ)句(如:Javascrīpt,VBscrīpt,HTML,Flash)來(lái)進(jìn)行測(cè)試：<scrīpt>alert(document.cookie)</scrīpt>最后,當(dāng)用戶瀏覽時(shí)便會(huì)彈出一個(gè)警告框，內(nèi)容顯示的是瀏覽者當(dāng)前的cookie串,這就說(shuō)明該網(wǎng)站存在XSS漏洞。試想如果我們注入的不是以上這個(gè)簡(jiǎn)單的測(cè)試代碼，而是一段經(jīng)常精心設(shè)計(jì)的惡意腳本，當(dāng)用戶瀏覽此帖時(shí)，cookie信息就可能成功的被攻擊者獲取。此時(shí)瀏覽者的帳號(hào)就很容易被攻擊者掌控了。BS架構(gòu)體系安全滲透測(cè)試基礎(chǔ)XSS攻擊示例大名鼎鼎的淘寶網(wǎng)也存在這樣的漏洞，我們?cè)谒阉骺蛑休斎耄?/p>

"/><divstyle="position:absolute;left:0px;top:0px;"><iframesrc=""FRAMEBORDER=0width=1000height=900/></div><ahref=“這樣，我們已經(jīng)修改了淘寶原有的頁(yè)面，在下面嵌入了百度的首頁(yè)。效果如圖：BS架構(gòu)體系安全滲透測(cè)試基礎(chǔ)如何預(yù)防XSS漏洞從應(yīng)用程序的角度來(lái)講,要進(jìn)行以下幾項(xiàng)預(yù)防:對(duì)Javascrīpt,VBscrīpt,HTML,Flash等語(yǔ)句或腳本進(jìn)行轉(zhuǎn)義.在服務(wù)端正式處理之前提交數(shù)據(jù)的合法性(合法性檢查主要包括三項(xiàng):數(shù)據(jù)類型,數(shù)據(jù)長(zhǎng)度,敏感字符的校驗(yàn))進(jìn)行檢查等。最根本的解決手段,在確認(rèn)客戶端的輸入合法之前,服務(wù)端拒絕進(jìn)行關(guān)鍵性的處理操作.

從測(cè)試人員的角度來(lái)講,要從需求檢查和執(zhí)行測(cè)試過(guò)程兩個(gè)階段來(lái)完成XSS檢查:在需求檢查過(guò)程中對(duì)各輸入項(xiàng)或輸出項(xiàng)進(jìn)行類型、長(zhǎng)度以及取值范圍進(jìn)行驗(yàn)證，著重驗(yàn)證是否對(duì)HTML或腳本代碼進(jìn)行了轉(zhuǎn)義。執(zhí)行測(cè)試過(guò)程中也應(yīng)對(duì)上述項(xiàng)進(jìn)行檢查。BS架構(gòu)體系安全滲透測(cè)試基礎(chǔ)注入缺陷2、注入缺陷目前的Web應(yīng)用中，絕大多數(shù)都會(huì)向用戶提供一個(gè)接口，用來(lái)進(jìn)行權(quán)限驗(yàn)證、搜索、查詢信息等功能。比如一個(gè)在線銀行，首先會(huì)有對(duì)注冊(cè)客戶進(jìn)行身份驗(yàn)證的登錄界面，在正確登錄后，會(huì)提供更多交互功能，如根據(jù)客戶的銀行卡號(hào)信息，查詢客戶的最近交易、轉(zhuǎn)賬細(xì)節(jié)等。這些都是注入缺陷的最佳利用場(chǎng)景。所謂注入缺陷，就是在上述場(chǎng)景中，用戶輸入的數(shù)據(jù)被當(dāng)做命令和查詢的一部分，送到后端的解釋器中解釋執(zhí)行。如果用戶的輸入是正常合法的，Web應(yīng)用自然會(huì)返回正常合理的結(jié)果，但是，如果惡意攻擊者，利用輸入數(shù)據(jù)可被后臺(tái)執(zhí)行的原理，偷梁換柱，使用非法的輸入，脆弱的Web應(yīng)用會(huì)怎樣呢？下面舉一個(gè)例子來(lái)說(shuō)明注入缺陷是如何進(jìn)行的。在一個(gè)交易網(wǎng)站中，用戶必須輸入產(chǎn)品ID號(hào)才可以查看該產(chǎn)品的詳細(xì)信息。為了實(shí)現(xiàn)這個(gè)需求，通常會(huì)用SQL語(yǔ)句查詢數(shù)據(jù)庫(kù)來(lái)實(shí)現(xiàn)。開(kāi)發(fā)人員在編寫應(yīng)用程序時(shí)，可能會(huì)使用如下的SQL語(yǔ)句來(lái)實(shí)現(xiàn)上述目的（這里僅為示例）：

BS架構(gòu)體系安全滲透測(cè)試基礎(chǔ)1)Select*fromproductswhereproduct_id=`+用戶輸入的ID+`這里的products是數(shù)據(jù)庫(kù)中用來(lái)存放產(chǎn)品信息的表，＋號(hào)表示SQL語(yǔ)句需要和用戶輸入的真實(shí)ID進(jìn)行拼接。如果用戶輸入325，則該語(yǔ)句在執(zhí)行時(shí)變?yōu)椋篠elect*fromproductswhereproduct_id=`325`數(shù)據(jù)庫(kù)會(huì)將ID為325的產(chǎn)品信息返回給用戶。2)在界面上，需要用戶輸入產(chǎn)品ID的地方，黑客會(huì)輸入如下數(shù)據(jù)：`or`1`=`1

可以看到，黑客并沒(méi)有輸入正常合法的產(chǎn)品編號(hào)。3)通過(guò)黑客的非法輸入，需要執(zhí)行的SQL語(yǔ)句變?yōu)椋篠elect*fromproductswhereproduct_id=``or`1`=`1`

可以看出，SQL語(yǔ)句的意義就完全改變了，當(dāng)產(chǎn)品ID為空或者1＝1時(shí)，返回產(chǎn)品所有信息，而1＝1是永遠(yuǎn)成立的條件，因此，黑客并沒(méi)有輸入任何產(chǎn)品編號(hào)，就可以返回?cái)?shù)據(jù)庫(kù)中所有產(chǎn)品的詳細(xì)信息。通過(guò)這個(gè)例子，我們可以看出，注入缺陷是風(fēng)險(xiǎn)非常高的安全漏洞，一旦Web應(yīng)用中給用戶提供了需要其輸入數(shù)據(jù)的接口，就有可能遭到攻擊，將后臺(tái)的數(shù)據(jù)完全暴露在用戶的面前。BS架構(gòu)體系安全滲透測(cè)試基礎(chǔ)如何預(yù)防SQL注入從應(yīng)用程序的角度來(lái)講,我們要做以下三項(xiàng)工作:轉(zhuǎn)義敏感字符及字符串(SQL的敏感字符包括“exec”,”xp_”,”sp_”,”declare”,”Union”,”cmd”,”+”,”//”,”..”,”;”,”‘”,”--”,”%”,”0x”,”><=!-*/()|”,和”空格”).屏蔽出錯(cuò)信息：阻止攻擊者知道攻擊的結(jié)果在服務(wù)端正式處理之前提交數(shù)據(jù)的合法性(合法性檢查主要包括三項(xiàng):數(shù)據(jù)類型,數(shù)據(jù)長(zhǎng)度,敏感字符的校驗(yàn))進(jìn)行檢查等。最根本的解決手段,在確認(rèn)客戶端的輸入合法之前,服務(wù)端拒絕進(jìn)行關(guān)鍵性的處理操作.

從測(cè)試人員的角度來(lái)講,在程序開(kāi)發(fā)前(即需求階段),我們就應(yīng)該有意識(shí)的將安全性檢查應(yīng)用到需求評(píng)審中,例如對(duì)一個(gè)表單需求進(jìn)行檢查時(shí),我們一般檢驗(yàn)以下幾項(xiàng)安全性問(wèn)題:需求中應(yīng)說(shuō)明表單中某一FIELD的類型,長(zhǎng)度,以及取值范圍(主要作用就是禁止輸入敏感字符)需求中應(yīng)說(shuō)明如果超出表單規(guī)定的類型,長(zhǎng)度,以及取值范圍的,應(yīng)用程序應(yīng)給出不包含任何代碼或數(shù)據(jù)庫(kù)信息的錯(cuò)誤提示.當(dāng)然在執(zhí)行測(cè)試的過(guò)程中,我們也需求對(duì)上述兩項(xiàng)內(nèi)容進(jìn)行測(cè)試.

BS架構(gòu)體系安全滲透測(cè)試基礎(chǔ)信息泄漏和不正確的錯(cuò)誤處理此漏洞利用的重點(diǎn)在于應(yīng)用程序未能正確處理自身發(fā)生的錯(cuò)誤，技術(shù)重點(diǎn)在于某些應(yīng)用程序出錯(cuò)時(shí)，會(huì)把錯(cuò)誤信息反饋到用戶端，這些錯(cuò)誤信息通?？捎糜谡{(diào)試的目的，

從錯(cuò)誤反饋信息中獲取有用的信息，從而加以利用，突破網(wǎng)站安全。

當(dāng)Web應(yīng)用程序發(fā)生錯(cuò)誤時(shí)，如果處理不得當(dāng)，可能會(huì)把相關(guān)的錯(cuò)誤信息反饋至客戶瀏覽器。這種情況更多見(jiàn)于PHP+MySQL的Web應(yīng)用，一些程序人員沒(méi)有正確的做異常處理，當(dāng)發(fā)生錯(cuò)誤里，系統(tǒng)向?yàn)g覽器端返回了本來(lái)是用于調(diào)試目的的相關(guān)信息。這些信息往往可能含有重要的安全信息。例如：某個(gè)網(wǎng)站的MySQL停止了運(yùn)行，而這時(shí)用戶訪問(wèn)此網(wǎng)站時(shí)，發(fā)現(xiàn)網(wǎng)頁(yè)提示如下信息：

MySQLError:LostconnectiontoMySQLserverduringquery

從這個(gè)回饋來(lái)看，用戶請(qǐng)求的頁(yè)所使用的數(shù)據(jù)庫(kù)是MySQL!這無(wú)疑暴露是安全人員所不希望看到的。高明的入侵者，會(huì)盡可能的使其在頁(yè)面瀏覽或提交時(shí)，使用不正當(dāng)?shù)臄?shù)據(jù)或方法，以此期望頁(yè)面產(chǎn)生錯(cuò)誤回饋，從而利用這些信息完成入侵。

從服務(wù)器角度，關(guān)閉調(diào)試信息回饋功能，并且善用異常處理功能，可以盡可能避免此類安全漏洞。BS架構(gòu)體系安全滲透測(cè)試基礎(chǔ)不安全的直接對(duì)象引用不安全的直接對(duì)象引用漏洞利用的重點(diǎn)是web開(kāi)發(fā)中，應(yīng)用代碼訪問(wèn)文件時(shí)沒(méi)受到權(quán)限控制，技術(shù)重點(diǎn)在于利用有漏洞的web程序讀取文件系統(tǒng)資料。

本文主要介紹不安全的直接對(duì)象引用漏洞的過(guò)程而不是技術(shù)細(xì)節(jié)。以PHP為例，看以下這個(gè)場(chǎng)景：

$filea=$_GET['filename'];

echo“<ahref=".$filea.">下載此鏈接</a>";

如果惡意用戶對(duì)之加以利用，就可能可以使用如下方式下載用戶主機(jī)上其他的文件

/downlist.php?filename=c:/boot.ini

解決此問(wèn)題的方法是必須控制web應(yīng)用程序?qū)ξ募脑L問(wèn)。BS架構(gòu)體系安全滲透測(cè)試基礎(chǔ)跨站請(qǐng)求偽造跨站請(qǐng)求偽造漏洞利用的重點(diǎn)攻擊者了解受害者所在的站點(diǎn)，在于攻擊者需要精心構(gòu)造可以完成目標(biāo)裝點(diǎn)數(shù)據(jù)修改的URL，攻擊者的目標(biāo)站點(diǎn)具有持久化授權(quán)cookie或者受害者具有當(dāng)前會(huì)話cookie，并且目標(biāo)站點(diǎn)沒(méi)有對(duì)用戶在網(wǎng)站行為的第二授權(quán)。

我們假定三個(gè)角色：攻擊者、用戶、網(wǎng)上銀行、一個(gè)論壇。攻擊的流程主要分以下幾個(gè)步驟：1、用戶連入網(wǎng)上銀行操作，該網(wǎng)上銀行使用持久化授權(quán)cookie，只要用戶不清除cookies，任何時(shí)候連入網(wǎng)上銀行時(shí)，該銀行網(wǎng)站都認(rèn)為該用戶是有效的；

2、攻擊者在論壇上發(fā)表圖片，內(nèi)嵌有GET或POST方法的URL并指向該網(wǎng)上銀行，如果該URL由一個(gè)銀行的合法用戶發(fā)出，則該URL會(huì)使用戶帳戶被修改；

3、用戶瀏覽此論壇并點(diǎn)擊該圖片，攻擊者預(yù)設(shè)的URL被由用戶發(fā)往銀行站點(diǎn)，因該用戶未清除cookie，該請(qǐng)求有效，用戶帳戶在用戶并不知情的前提下被成功修改。

我們注意到，這個(gè)過(guò)程很象跨站腳本攻擊，但實(shí)際上，是完全不同的?？缯灸_本攻擊需要在客戶端寫入惡意代碼，以搜集cookie等信息，而跨站請(qǐng)求偽造則根本不需要向用戶端寫入任何東西，直接利用銀行授權(quán)的持久認(rèn)證和用戶未清理的cookie。BS架構(gòu)體系安全滲透測(cè)試基礎(chǔ)

這里的問(wèn)題在于，論壇用戶不能上傳js腳本，于是直接利用URL來(lái)誘騙用戶，以致于完成數(shù)據(jù)操作。

由此可見(jiàn)，該攻擊的重點(diǎn)在于要知道目標(biāo)站點(diǎn)和目標(biāo)用戶，并且該受害站點(diǎn)沒(méi)有使用更多的授權(quán)認(rèn)證。

對(duì)于web站點(diǎn)，將持久化的授權(quán)方法（例如cookie）切換為瞬時(shí)的授權(quán)方法（在每個(gè)form中提供隱藏field），這將幫助網(wǎng)站防止這些攻擊。一種類似的方式是在form中包含秘密信息、用戶指定的代號(hào)作為cookie之外的驗(yàn)證。

BS架構(gòu)體系安全滲透測(cè)試基