整合營銷服務(wù)商
電腦端+手機(jī)端+微信端=數(shù)據(jù)同步管理
免費(fèi)咨詢熱線：
電腦端+手機(jī)端+微信端=數(shù)據(jù)同步管理
免費(fèi)咨詢熱線：
客也搶賺加密貨幣挖礦財(cái)，去年開始出現(xiàn)大量的網(wǎng)頁式惡意挖礦程序，埋在熱門站點(diǎn)中利用用戶電腦資源挖礦，讓人防不勝防。不只是電腦，趨勢(shì)科技便指出，如果常覺得手機(jī)速度好像越來越慢或是電池常常發(fā)燙，可能已成為幫黑客的免費(fèi)挖礦工。
網(wǎng)頁挖礦程序以Coinhive為首，色情類網(wǎng)站最危險(xiǎn)
趨勢(shì)科技資深技術(shù)顧問簡勝財(cái)指出，過去惡意挖礦程序多以木馬程序的形式進(jìn)駐在用戶電腦中偷挖礦，但從去年起，透過javascript執(zhí)行的網(wǎng)頁式挖礦程序越來越多，甚至伴隨著惡意廣告大規(guī)模散布。12日也傳出包含英、美政府等4,200個(gè)網(wǎng)站，皆被植入惡意挖礦代碼。
什么是網(wǎng)頁式挖礦程序？以市占率最高的Coinhive為例，其將挖取門羅幣的程序打包在瀏覽器端的javascript中，而網(wǎng)站業(yè)者只要在自家網(wǎng)站嵌入Coinhive代碼，就能利用用戶電腦運(yùn)算力挖取門羅幣。Coinhive希望網(wǎng)站業(yè)者可用這筆收入取代在網(wǎng)站植入廣告的收入，一方面也提高用戶體驗(yàn)，而Coinhive則從中抽三成。
盡管Coinhive提醒不要在未提示用戶的情況下使用該服務(wù)，但事實(shí)上，Coinhive已經(jīng)被多個(gè)網(wǎng)站濫用，偷偷盜取用戶電腦運(yùn)算資源。根據(jù)AdGuard研究報(bào)告，有近十億名串流媒體網(wǎng)站的訪客被秘密地用在挖礦活動(dòng)。
根據(jù)奇虎360旗下的網(wǎng)絡(luò)安全研究實(shí)驗(yàn)室（Network Security Research Lab，Netlab）調(diào)查，Alexa Top 30萬的網(wǎng)站中，有629（0.21%）個(gè)網(wǎng)站在首頁嵌入挖礦代碼，其中色情相關(guān)站點(diǎn)是主體，占整體49%，其他還有詐騙（8%）、廣告（7%）、挖礦（7%）、影視（6%）等類別，且部分內(nèi)容網(wǎng)站還會(huì)嵌入2個(gè)或更多挖礦網(wǎng)站。
挖礦程序不只是被嵌入在網(wǎng)頁中，趨勢(shì)科技發(fā)現(xiàn)，有黑客利用Google網(wǎng)絡(luò)廣告服務(wù)DoubleClick來散布挖礦惡意程序，也讓Coinhive挖礦程序數(shù)量突然成長3倍，受害地區(qū)包括日本、法國、臺(tái)灣、意大利與西班牙。
防堵網(wǎng)頁挖礦綁架，學(xué)會(huì)三招自保
趨勢(shì)科技指出，只要避免瀏覽器執(zhí)行JavaScript應(yīng)用程序，就能防止Coinhive挖礦程序使用CPU資源。此外，定期修補(bǔ)、定期更新軟件，尤其是網(wǎng)頁瀏覽器，也能降低加密貨幣挖礦程序的影響。
不只是電腦，手機(jī)同樣會(huì)受網(wǎng)頁式挖礦程序影響，但更難察覺。簡勝財(cái)建議，可用有網(wǎng)頁過濾機(jī)制的防毒應(yīng)用程序加以防范。此外，趨勢(shì)科技也推出瀏覽器App「Trend Micro Zero」，可阻擋內(nèi)嵌挖礦程序，降低裝置電量耗損，但目前僅有iOS版本。
習(xí)CSS注入的目的是學(xué)習(xí)計(jì)算機(jī)知識(shí)，千萬不要做違反法律的事情，不然等待你的是法律的嚴(yán)懲。
CSS僅僅只是一種用來表示樣式的語言嗎？當(dāng)然不是！CSS就已被安全研究人員運(yùn)用于滲透測(cè)試當(dāng)中。使用屬性選擇器和iFrame，并通過CSS注入來竊取敏感數(shù)據(jù)的方法。但由于該方法需要iFrame，而大多數(shù)主流站點(diǎn)都不允許該操作，因此這種攻擊方法并不實(shí)用。這里為大家詳細(xì)介紹一種不需要iframe且只需10秒，就能為獲得CSRF token的方法。
一、背景
CSS屬性選擇器開發(fā)者可以根據(jù)屬性標(biāo)簽的值匹配子字符串來選擇元素。 這些屬性值選擇器可以做以下操作：
屬性選擇器能讓開發(fā)人員查詢單個(gè)屬性的頁面HTML標(biāo)記，并且匹配它們的值。一個(gè)實(shí)際的用例是將以“https://example.com”開頭的所有href屬性變?yōu)槟撤N特定的顏色。而在實(shí)際環(huán)境中，一些敏感信息會(huì)被存放在HTML標(biāo)簽內(nèi)。在大多數(shù)情況下CSRF token都是以這種方式被存儲(chǔ)的：即隱藏表單的屬性值中。
可以將CSS選擇器與表單中的屬性進(jìn)行匹配，并根據(jù)表單是否與起始字符串匹配，加載一個(gè)外部資源，例如背景圖片，來嘗試猜測(cè)屬性的起始字母。通過這種方式，攻擊者可以進(jìn)行逐字猜解并最終獲取到完整的敏感數(shù)值。想要解決這個(gè)問題受害者可以在其服務(wù)器實(shí)施內(nèi)容安全策略（CSP），防止攻擊者從外部加載CSS代碼。
二、無 iFrames
要做到無iFrame，使用一種方法：創(chuàng)建一個(gè)彈窗，然后在設(shè)置計(jì)時(shí)器后更改彈出窗口的位置。使用這種方仍然可以加載受害者的CSS，不再依賴于受害者是否允許iFrame。因?yàn)樽畛醯膹棾鍪峭ㄟ^用戶事件觸發(fā)的，沒有被瀏覽器阻止。為了強(qiáng)制重載，在CSS注入間彈出一個(gè)虛擬窗口，如下：
但由于CSRF是針對(duì)客戶端的攻擊，因此如果能想出一種不需要服務(wù)器的方法，那么就可以節(jié)省大量的開銷和簡化操作。為了接收客戶端加載資源，可以利用Service Workers來攔截和讀取請(qǐng)求數(shù)據(jù)。Service Workers目前只適用于同源請(qǐng)求，在演示中受害者和攻擊者頁面已處于同一源上。
不久后，chrome很可能會(huì)合并這個(gè)實(shí)驗(yàn)性的功能，允許Service Workers攔截跨域請(qǐng)求。這樣，就可以確保在客戶端的攻擊100%的執(zhí)行，并強(qiáng)制用戶在10秒內(nèi)點(diǎn)擊鏈接執(zhí)行CSRF攻擊，演示如下：
三、Demo
如上所述，因?yàn)椴幌脒\(yùn)行一個(gè)web服務(wù)器，所以使用service workers攔截和模擬服務(wù)器端組件。目前，該演示只適用于Chrome瀏覽器。首先創(chuàng)建了一個(gè)易受攻擊的目標(biāo)，它存在一個(gè)基于DOM的CSS注入漏洞，并在頁面放置了一個(gè)敏感token。再對(duì)腳本標(biāo)簽添加了一些保護(hù)措施，對(duì)左尖括號(hào)和右尖括號(hào)進(jìn)行了編碼。
接下來將強(qiáng)制加載受害者的CSS，并且使用上述方法，可一次竊取（猜解）一個(gè)敏感字符。在接收端，定義一個(gè)攔截請(qǐng)求的service worker，并通過post-message將它們發(fā)送回域，然后將token存儲(chǔ)在本地存儲(chǔ)中以供后續(xù)使用。你也可以想象一個(gè)后端Web服務(wù)器，通過Web套接字或輪詢將CSRF token回發(fā)給攻擊者域。
如果你的瀏覽器支持的話，只需點(diǎn)擊打開頁面任意位置，你將看到CSRF token將逐一被猜解出來。
四、結(jié)束語
反射型CSS注入實(shí)際上比存儲(chǔ)型CSS注入更致命，因?yàn)榇鎯?chǔ)型CSS注入需要一個(gè)服務(wù)器在受害者渲染之前來更新CSS。一段時(shí)間以來，CSS注入在嚴(yán)重程度上來回變化。過去IE瀏覽器是允許用戶在CSS中執(zhí)行Javascript代碼的。這個(gè)演示也從某種程度上表明了CSS注入，以及渲染不受信任的CSS仍會(huì)導(dǎo)致嚴(yán)重的安全問題。所以在設(shè)計(jì)軟件一定要測(cè)試，才能及時(shí)發(fā)現(xiàn)和修復(fù)各種漏洞。
面我們說了 2 種常見的 Web 攻擊：XSS 和 SQL 注入。它們分別篡改了原始的 HTML 和 SQL 邏輯，從而使得黑客能夠執(zhí)行自定義的功能。那么除了對(duì)代碼邏輯進(jìn)行篡改，黑客還能通過什么方式發(fā)起 Web 攻擊呢？
我們還是先來看一個(gè)例子。在平常使用瀏覽器訪問各種網(wǎng)頁的時(shí)候，是否遇到過，自己的銀行應(yīng)用突然發(fā)起了一筆轉(zhuǎn)賬，又或者，你的微博突然發(fā)送了一條內(nèi)容？
在我們了解了 XSS 之后，你可能會(huì)聯(lián)想到，這是銀行或者微博中出現(xiàn)了某個(gè) XSS 漏洞。但問題是，你今天并沒有訪問過銀行或者微博的頁面，所以并沒有“被 XSS”的機(jī)會(huì)。這時(shí)，你想到，會(huì)不會(huì)是你今天訪問的其他網(wǎng)頁里存在一些惡意的攻擊，實(shí)現(xiàn)了你不知道的轉(zhuǎn)賬和發(fā)博行為呢？
當(dāng)我們?cè)谠L問一個(gè) Web 頁面的時(shí)候，并不是我們自己去獲取頁面信息，而是瀏覽器去獲取了這些信息，并將它們進(jìn)行了展示。這就說明，你允許瀏覽器代表你去和 Web 的服務(wù)端進(jìn)行交互。為了能夠準(zhǔn)確地代表你的身份，瀏覽器通常會(huì)在 Cookie 中存儲(chǔ)一些必要的身份信息。所以，在我們使用一個(gè)網(wǎng)頁的時(shí)候，只需要在首次訪問的時(shí)候登錄就可以了。
從用戶體驗(yàn)上來說，這當(dāng)然是非常方便的。但是，黑客正是利用這一點(diǎn)，來編寫帶有惡意 JavaScript 腳本的網(wǎng)頁，通過“釣魚”的方式誘導(dǎo)你訪問。然后，黑客會(huì)通過這些 JavaScript 腳本竊取你保存在網(wǎng)頁中的身份信息，通過仿冒你，讓你的瀏覽器發(fā)起偽造的請(qǐng)求，最終執(zhí)行黑客定義的操作。而這一切對(duì)于你自己而言都是無感知的。這就是 CSRF（Cross-Site Request Forgery，跨站請(qǐng)求偽造）攻擊。
接下來，我們就以銀行轉(zhuǎn)賬為例子，來詳細(xì)講解一下這個(gè)攻擊過程。
當(dāng)你在銀行頁面發(fā)起一筆轉(zhuǎn)賬時(shí)，這個(gè)過程其實(shí)是通過一個(gè)轉(zhuǎn)賬接口來完成的。這個(gè)接口的內(nèi)容可能包括下面這些內(nèi)容：
在轉(zhuǎn)賬之前，你肯定進(jìn)行了一次登錄。這樣一來，這個(gè)轉(zhuǎn)賬接口就可以通過你之前存儲(chǔ)在 Cookie 中的相關(guān)字段來完成認(rèn)證了。所以，這個(gè)接口參數(shù)中不需要包含任何身份認(rèn)證相關(guān)的信息。也正是因?yàn)槿绱耍@個(gè)接口滿足了 CSRF 攻擊的基本條件：
于是，黑客可以構(gòu)造一個(gè)如下的空白網(wǎng)頁。我們假設(shè)這個(gè)網(wǎng)頁的地址為 hacker.com。
<html>
<body>
<form action="http://bank.com/transfer" method="POST">
<input type="hidden" name="to" value="hacker" />
<input type="hidden" name="amount" value="10000.00" />
</form>
<script>
document.forms[0].submit(); </script>
</body></html>在 HTML 中，<script>標(biāo)簽內(nèi)的 JavaScript 腳本會(huì)在打開網(wǎng)頁的時(shí)候自動(dòng)執(zhí)行。因此，一旦用戶訪問了這個(gè) hacker.com 的頁面，它就會(huì)自動(dòng)提交 form 表單，向http://bank.com/transfer這個(gè)接口（假設(shè)為轉(zhuǎn)賬接口）發(fā)起一個(gè) POST 請(qǐng)求。
其中，to 和 amount 這兩個(gè)參數(shù)，代表著用戶向黑客的賬號(hào)轉(zhuǎn)賬 10000 元。只要這個(gè)用戶之前登錄過 bank.com，并且賬戶余額大于 10000 元，那么黑客就能夠成功地收到這 10000 元的轉(zhuǎn)賬了。在這個(gè)網(wǎng)頁中，<input>的標(biāo)簽帶有“hidden”屬性，所以這整個(gè)過程對(duì)于用戶來說都是不可見的。如下圖所示：
和 XSS 一樣，CSRF 也可以仿冒用戶去進(jìn)行一些功能操作的請(qǐng)求，比如修改密碼、轉(zhuǎn)賬等等，相當(dāng)于繞過身份認(rèn)證，進(jìn)行未授權(quán)的操作。
值得一提的是，盡管黑客通過 CSRF 能進(jìn)行的操作沒有 XSS 豐富，但 CSRF 在傳播和攻擊成本上都低于 XSS。這也就是說，即使你的網(wǎng)頁中沒有任何注入漏洞，但只要接口配置不當(dāng)，就能夠被 CSRF 利用。而黑客也只需要在自己的域名中，搭建一個(gè)誘導(dǎo)性的網(wǎng)頁，就可以讓任何訪問網(wǎng)頁的用戶都遭受到 CSRF 攻擊。而且，用戶每天需要訪問大量的網(wǎng)頁，根本沒有辦法確認(rèn)每一個(gè)網(wǎng)頁的合法性。而從嚴(yán)格意義上來說，用戶根本沒有辦法防止 CSRF 攻擊。因此，我們只能從應(yīng)用本身入手去加強(qiáng)防護(hù)。
那究竟該怎么進(jìn)行 CSRF 防護(hù)呢？我們有兩種方法。
我們知道，CSRF 是通過自動(dòng)提交表單的形式來發(fā)起攻擊的。所以，在前面轉(zhuǎn)賬的例子中，黑客可以通過抓包分析出 http://bank.com/transfer 這個(gè)接口所需要的參數(shù)，從而構(gòu)造對(duì)應(yīng)的 form 表單。因此，我們只需要在這個(gè)接口中，加入一個(gè)黑客無法猜到的參數(shù)，就可以有效防止 CSRF 了。這就是 CSRF Token 的工作原理。它的工作流程如下圖所示：
因?yàn)?CSRF Token 是每次用戶正常訪問頁面時(shí)，服務(wù)端隨機(jī)生成返回給瀏覽器的。所以，每一次正常的轉(zhuǎn)賬接口調(diào)用，都會(huì)攜帶不同的 CSRF Token。黑客沒有辦法進(jìn)行提前猜測(cè)，也就沒有辦法構(gòu)造出正確的表單了。
回想一下，當(dāng)你進(jìn)行各類支付操作的時(shí)候，銀行網(wǎng)頁通常會(huì)要求你輸入支付密碼。你可能會(huì)覺得奇怪，明明自己已經(jīng)登錄了，為什么還需要輸入一個(gè)獨(dú)立的支付密碼呢？這其實(shí)和 CSRF Token 的原理一樣：這個(gè)獨(dú)立的支付密碼是需要用戶輸入的，只存在于用戶的記憶中，因此，也是黑客無法獲取到的參數(shù)。
怎么理解呢？假如說，黑客通過 CSRF 攻擊，替你發(fā)起了一筆轉(zhuǎn)賬。在支付的時(shí)候，銀行會(huì)發(fā)起一個(gè)全新的頁面，讓你驗(yàn)證支付密碼。這個(gè)時(shí)候你發(fā)現(xiàn)，這個(gè)支付請(qǐng)求不是你本人發(fā)起的，那你肯定不會(huì)輸入支付密碼來完成驗(yàn)證。所以，在用戶進(jìn)行支付這樣的敏感操作時(shí)，應(yīng)用通常會(huì)要求用戶提供一些私密的信息，就是為了對(duì) CSRF 攻擊進(jìn)行防護(hù)。
你現(xiàn)在對(duì) CSRF 的攻擊和防護(hù)，應(yīng)該有了一個(gè)大概的了解。簡單來說，CSRF 其實(shí)就是黑客利用瀏覽器存儲(chǔ)用戶 Cookie 這一特性，來模擬用戶發(fā)起一次帶有認(rèn)證信息的請(qǐng)求，比如轉(zhuǎn)賬、修改密碼等。防護(hù) CSRF 的原理也很簡單，在這些請(qǐng)求中，加入一些黑客無法得到的參數(shù)信息即可，比如 CSRF Token 或者獨(dú)立的支付密碼等。掌握了這些內(nèi)容，其實(shí) CSRF 的知識(shí)基本上就差不多了。
在 CSRF 中，黑客通過誘導(dǎo)用戶訪問某個(gè)網(wǎng)站，讓用戶的瀏覽器發(fā)起一個(gè)偽造的請(qǐng)求。那么，如果服務(wù)端發(fā)起了這個(gè)偽造的請(qǐng)求，又會(huì)發(fā)生什么呢？
我們知道，服務(wù)端也有代理請(qǐng)求的功能：用戶在瀏覽器中輸入一個(gè) URL（比如某個(gè)圖片資源），然后服務(wù)端會(huì)向這個(gè) URL 發(fā)起請(qǐng)求，通過訪問其他的服務(wù)端資源來完成正常的頁面展示。
這個(gè)時(shí)候，只要黑客在輸入中提交一個(gè)內(nèi)網(wǎng) URL，就能讓服務(wù)端發(fā)起一個(gè)黑客定義的內(nèi)網(wǎng)請(qǐng)求，從而獲取到內(nèi)網(wǎng)數(shù)據(jù)。這就是 SSRF（Server Side Request Forgery，服務(wù)端請(qǐng)求偽造）的原理。而服務(wù)端作為內(nèi)網(wǎng)設(shè)備，通常具備很高的權(quán)限，所以，這個(gè)偽造的請(qǐng)求往往因?yàn)槟芾@過大部分的認(rèn)證和授權(quán)機(jī)制，而產(chǎn)生很嚴(yán)重的后果。
比方說，當(dāng)我們?cè)诎俣戎兴阉鲌D片時(shí)，會(huì)涉及圖片的跨域加載保護(hù)，百度不會(huì)直接在頁面中加載圖片的源地址，而是將地址通過 GET 參數(shù)提交到百度服務(wù)器，然后百度服務(wù)器請(qǐng)求到對(duì)應(yīng)的圖片，再返回到頁面展示出來。
這個(gè)過程中，百度服務(wù)器實(shí)際上會(huì)向另外一個(gè) URL 地址發(fā)起請(qǐng)求（比如，上圖中的http://s1.sinaimg.cn）。利用這個(gè)代理發(fā)起請(qǐng)求的功能，黑客可以通過提交一個(gè)內(nèi)網(wǎng)的地址，實(shí)現(xiàn)對(duì)內(nèi)網(wǎng)任意服務(wù)的訪問。這就是 SSRF 攻擊的實(shí)現(xiàn)過程，也就是我們常說的“內(nèi)網(wǎng)穿透”。
了解了 SSRF 攻擊的過程之后，我們知道，在服務(wù)端不做任何保護(hù)措施的情況下，黑客可以利用 SSRF 向內(nèi)網(wǎng)發(fā)起任意的 HTTP 請(qǐng)求。那么，這些請(qǐng)求會(huì)產(chǎn)生什么樣的后果呢？我總結(jié)了一下，主要會(huì)有這樣兩種動(dòng)作：內(nèi)網(wǎng)探測(cè)和文件讀取。
內(nèi)外網(wǎng)一般是隔離的。所以，黑客在外網(wǎng)環(huán)境中，是無法知道內(nèi)網(wǎng)有哪些服務(wù)器，這些服務(wù)器又分別提供了哪些服務(wù)。但是，通過一個(gè)加載圖片的 SSRF 漏洞，黑客就能夠?qū)?nèi)網(wǎng)進(jìn)行探測(cè)。這是怎么做到的呢？別著急，我們慢慢來看。
在前面百度搜圖的例子中，我們請(qǐng)求的地址是：https://image.baidu.com/search/detail?objurl=http://s1.sinaimg.cn/picture.jpg。因?yàn)閔ttp://s1.sinaimg.cn/picture.jpg會(huì)正常返回一個(gè)圖片，所以網(wǎng)頁會(huì)展示出來對(duì)應(yīng)的圖片。
我們假定這樣一個(gè)服務(wù)端邏輯：在這個(gè)請(qǐng)求過程中，服務(wù)端會(huì)判斷 objurl 返回?cái)?shù)據(jù)的 Content Type 是否為 image/jpeg。那么，可能的返回結(jié)果就有三種：
基于這三種返回邏輯，黑客可以構(gòu)造一個(gè)惡意的請(qǐng)求地址：https://image.baidu.com/search/detail?objurl=127.0.0.1:3306。如果服務(wù)器返回“格式錯(cuò)誤”，則代表服務(wù)端本地的 3306 端口可用；如果返回“找不到圖片”，則代表不可用。我們知道，3306 是 MySQL 對(duì)應(yīng)的端口號(hào)，因此，根據(jù)這個(gè)返回的信息，黑客就能夠知道服務(wù)端本地是否開啟了一個(gè) MySQL 服務(wù)。接下來，黑客只需要不斷重復(fù)這個(gè)過程，嘗試不同的 IP 和端口號(hào)，就能夠一點(diǎn)一點(diǎn)探測(cè)出整個(gè)內(nèi)網(wǎng)的結(jié)構(gòu)。
服務(wù)器除了對(duì)圖片的代理不做合法性判斷之外，對(duì)很多其他的代理也不做判斷，而是直接將代理的結(jié)果返回到前端。我們稱這種情況為“有回顯的 SSRF”。在這種情況下，黑客不僅能夠知道請(qǐng)求是否成功了，還能夠知道具體返回的內(nèi)容。這時(shí)候你肯定會(huì)好奇，黑客究竟是怎么做到呢？
在 URI 中，開頭的 http:// 和 https:// 代表需要使用什么協(xié)議去進(jìn)行請(qǐng)求。除了 HTTP 之外，URI 還有很多種協(xié)議可以選擇，比如 file:// 就是直接讀取本地的文件。通過輸入 file://etc/passwd，黑客就能夠通過一個(gè)請(qǐng)求獲取到本地的 passwd 文件，從而知道本地有哪些用戶。經(jīng)過不斷地嘗試，黑客就能夠把整個(gè)服務(wù)器中的文件內(nèi)容都給拉取出來，這其中包括密鑰、源碼等極度敏感的信息。
一般情況下，黑客會(huì)通過 SSRF 攻擊拿到了服務(wù)端的源碼，然后通過對(duì)源碼的分析，找到了一個(gè) SQL 注入的漏洞，再利用 SSRF 發(fā)起對(duì)內(nèi)網(wǎng)的 SQL 注入攻擊，從而拿到了內(nèi)網(wǎng)的命令執(zhí)行權(quán)限。
因?yàn)?SSRF 漏洞起源于業(yè)務(wù)的正常功能需求（比如百度圖片的圖片請(qǐng)求等等）。因此，我們很難真正消除它。盡管如此，我還是會(huì)為你介紹幾種常見的防護(hù)手段，來盡可能地提高應(yīng)用的安全性。這些常見的手段主要包括：白名單限制、協(xié)議限制和請(qǐng)求端限制。
白名單的限制永遠(yuǎn)是最簡單、最高效的防護(hù)措施。SSRF 中的白名單，就是對(duì)用戶提交上來的目標(biāo) URL 進(jìn)行限制。比如，只允許是同一個(gè)域名下的 URL。你可以理解為，讓百度圖片的代理服務(wù)只允許代理 baidu.com 的 URL。但是，很多時(shí)候，因?yàn)闃I(yè)務(wù)功能的設(shè)計(jì)，白名單的限制并不可行。比如，上述百度圖片的例子，這個(gè)功能的設(shè)計(jì)思路就是，baidu.com 這個(gè)域名下能夠請(qǐng)求各類域名下的圖片資源（比如上述例子中的 sinaimg.cn）。
在這種時(shí)候，我們可以對(duì)協(xié)議和資源類型等進(jìn)行限制。比如：對(duì)于使用協(xié)議，我們只允許 HTTP 或者 HTTPS 協(xié)議；對(duì)于返回的內(nèi)容，我們只允許圖片格式的內(nèi)容。通過這些限制，雖然不能完全阻止黑客發(fā)起 SSRF 攻擊，但也大大降低了黑客能夠造成的危害。
除此之外，因?yàn)?SSRF 最終的結(jié)果，是接受代理請(qǐng)求的服務(wù)端發(fā)生數(shù)據(jù)泄漏。所以，SSRF 防護(hù)不僅僅涉及接收 URL 的服務(wù)端檢測(cè)，也需要接受代理請(qǐng)求的服務(wù)端進(jìn)行配合。在這種情況下，我們就需要用到請(qǐng)求端限制，它的防護(hù)措施主要包括兩個(gè)方面。
第一，為其他業(yè)務(wù)提供的服務(wù)接口盡量使用 POST，避免 GET 的使用。因?yàn)椋?SSRF 中（以及大部分的 Web 攻擊中），發(fā)起一個(gè) POST 請(qǐng)求的難度是遠(yuǎn)遠(yuǎn)大于 GET 請(qǐng)求的。因?yàn)槟J(rèn)的請(qǐng)求方式是 GET，而發(fā)起 POST 請(qǐng)求，需要在發(fā)起 HTTP 請(qǐng)求的時(shí)候進(jìn)行配置。很多安全漏洞中不包含能夠配置協(xié)議的地方。在上述百度圖片的例子中，黑客顯然就只能發(fā)起 GET 請(qǐng)求。如果某個(gè)敏感服務(wù)是 POST 的，黑客就無法請(qǐng)求到相關(guān)資源了。
第二，為其他業(yè)務(wù)提供的服務(wù)接口，最好每次都進(jìn)行驗(yàn)證。通過 SSRF，黑客只能發(fā)起請(qǐng)求，并不能獲取到服務(wù)端存儲(chǔ)的驗(yàn)證信息（如認(rèn)證的 key 和 secret 等）。因此，只要接受代理請(qǐng)求的端對(duì)每次請(qǐng)求都進(jìn)行完整的驗(yàn)證，黑客無法成功通過驗(yàn)證，也就無法完成請(qǐng)求了。
我們介紹了 CSRF 和 SSRF 這兩種攻擊方式。其中，CSRF 是黑客控制用戶的瀏覽器發(fā)起偽造的請(qǐng)求，SSRF 則是黑客控制服務(wù)端發(fā)起偽造的請(qǐng)求。通過偽造的請(qǐng)求，黑客可以偽造用戶或者服務(wù)器的身份，越權(quán)獲取數(shù)據(jù)或者發(fā)起請(qǐng)求。應(yīng)用中的請(qǐng)求接口越敏感，黑客能夠造成的傷害就越大。
除此之外，CSRF 和 SSRF 產(chǎn)生于正常的業(yè)務(wù)功能邏輯中，因此，我們沒有辦法從根本上組織黑客發(fā)起偽造的請(qǐng)求。但是，你可以通過加強(qiáng)接口的安全驗(yàn)證，來避免偽造請(qǐng)求造成影響。在 CSRF 中，我們可以通過 CSRF Token 或者二次驗(yàn)證等操作來加強(qiáng)防護(hù)。這樣，黑客無法獲取到隱私信息，也就無法發(fā)起連續(xù)的請(qǐng)求了。在 SSRF 中，我們則需要限制可請(qǐng)求的域名，來限制黑客能夠訪問到的資源。另外，目標(biāo)服務(wù)端，也需要加強(qiáng)接口的驗(yàn)證，來避免偽造請(qǐng)求成功通過授權(quán)。
*請(qǐng)認(rèn)真填寫需求信息，我們會(huì)在24小時(shí)內(nèi)與您取得聯(lián)系。
