摘要：與攻擊相比，攻擊往往很少見(jiàn)，因此對(duì)其進(jìn)行防范的資源也相當(dāng)稀少。不過(guò)，這種受信任的攻擊模式更加難以防范，所以被認(rèn)為比更具危險(xiǎn)性。通過(guò)實(shí)時(shí)升級(jí)系統(tǒng)快速同步最新漏洞，避免零日攻擊。

現(xiàn)在，我們絕大多數(shù)人都會(huì)在網(wǎng)上購(gòu)物買(mǎi)東西。但是很多人都不清楚的是，很多電商網(wǎng)站會(huì)存在安全漏洞。比如烏云就通報(bào)過(guò)，國(guó)內(nèi)很多家公司的網(wǎng)站都存在 CSRF 漏洞。如果某個(gè)網(wǎng)站存在這種安全漏洞的話，那么我們?cè)谫?gòu)物的過(guò)程中，就很可能會(huì)被網(wǎng)絡(luò)黑客盜刷信用卡。是不是有點(diǎn)「不寒而栗」 的感覺(jué)？

首先，我們需要弄清楚 CSRF 是什么。它的全稱(chēng)是 Cross-site request forgery ，翻譯成中文的意思就是「跨站請(qǐng)求偽造」，這是一種對(duì)網(wǎng)站的惡意利用。簡(jiǎn)單而言，就是某惡意網(wǎng)站在我們不知情的情況下，以我們的身份在你登錄的某網(wǎng)站上胡作非為——發(fā)消息、買(mǎi)東西，甚至轉(zhuǎn)賬......

這種攻擊模式聽(tīng)起來(lái)有點(diǎn)像跨站腳本（XSS），但 CSRF 與 XSS 非常不同，并且攻擊方式幾乎相左。XSS 利用站點(diǎn)內(nèi)的信任用戶(hù)，而 CSRF 則通過(guò)偽裝來(lái)自受信任用戶(hù)的請(qǐng)求來(lái)利用受信任的網(wǎng)站。與 XSS 攻擊相比，CSRF 攻擊往往很少見(jiàn)，因此對(duì)其進(jìn)行防范的資源也相當(dāng)稀少。不過(guò)，這種「受信任」的攻擊模式更加難以防范，所以被認(rèn)為比 XSS 更具危險(xiǎn)性。

這個(gè)過(guò)程到底是怎樣的呢？讓我們看個(gè)簡(jiǎn)單而鮮活的案例。

銀行網(wǎng)站 A，它以 GET 請(qǐng)求來(lái)完成銀行轉(zhuǎn)賬的操作，如：

http://www.mybank.com/Transfer.php?toBankId=11&money=1000

危險(xiǎn)網(wǎng)站 B，它里面有一段 HTML 的代碼如下：

可能會(huì)發(fā)生什么？你登錄了銀行網(wǎng)站 A，然后訪問(wèn)危險(xiǎn)網(wǎng)站 B 以后，突然發(fā)現(xiàn)你的銀行賬戶(hù)少了10000塊......

為什么會(huì)這樣呢？原因是在訪問(wèn)危險(xiǎn)網(wǎng)站 B 之前，你已經(jīng)登錄了銀行網(wǎng)站 A，而 B 中的以 GET 的方式請(qǐng)求第三方資源（這里的第三方就是指銀行網(wǎng)站了，原本這是一個(gè)合法的請(qǐng)求，但這里被不法分子利用了），所以你的瀏覽器會(huì)帶上你的銀行網(wǎng)站 A 的 Cookie 發(fā)出 GET 請(qǐng)求，去獲取資源

「http://www.mybank.com/Transfer.php?toBankId=11&money=1000」，

結(jié)果銀行網(wǎng)站服務(wù)器收到請(qǐng)求后，認(rèn)為這是一個(gè)合理的轉(zhuǎn)賬操作，就立刻轉(zhuǎn)賬了......

其實(shí)，真實(shí)的銀行網(wǎng)站不會(huì)如此不加防范，但即使用 POST 替代 GET，也只是讓危險(xiǎn)網(wǎng)站多花些力氣而已。危險(xiǎn)網(wǎng)站 B 依然可以通過(guò)嵌入 Javascript 來(lái)嘗試盜取客戶(hù)資金，所以我們時(shí)不時(shí)會(huì)聽(tīng)到客戶(hù)資金被盜的案件，其實(shí)這并不是很不稀奇。

相信，很多人了解到這兒，會(huì)出現(xiàn)一身冷汗，還讓不讓我們?cè)凇鸽p11」期間能夠愉快地享受網(wǎng)購(gòu)的快感了？難道沒(méi)有什么辦法防住它嘛？

當(dāng)然是有的?？梢越o網(wǎng)站打補(bǔ)丁，如 Cookie Hashing (所有表單都包含同一個(gè)偽隨機(jī)值)。這可能是最簡(jiǎn)單的解決方案了，因?yàn)槔碚撋瞎粽卟荒塬@得第三方的 Cookie，所以表單中的數(shù)據(jù)也就構(gòu)造失敗了。但這并不是完美的解決方案，因?yàn)橛脩?hù)的 Cookie 很容易由于網(wǎng)站的 XSS 漏洞而被盜取；另一種方法是用驗(yàn)證碼，每次的用戶(hù)提交都需要用戶(hù)在表單中填寫(xiě)一個(gè)圖片上的隨機(jī)字符串....這個(gè)方案可以完全解決 CSRF，但用戶(hù)體驗(yàn)很遭罪（忒麻煩了）。還有一種是 One-Time Tokens(不同的表單包含不同的偽隨機(jī)值)，需要設(shè)計(jì)令牌和 Session 管理邏輯，并修改 Web 表單，網(wǎng)站運(yùn)維又很遭罪。

以上所有辦法都需要對(duì)網(wǎng)站進(jìn)行修修補(bǔ)補(bǔ)，再花費(fèi)很多氣力去測(cè)試?？赡苡腥藭?huì)想到用防火墻來(lái)防護(hù)，那么有沒(méi)有滿(mǎn)足要求的產(chǎn)品呢？在去年，下一代防火墻——自適應(yīng)安全防護(hù)（RASP）這個(gè)概念橫空出世，吸引了很多企業(yè)的注意，它對(duì)請(qǐng)求上下文的感知能力和深入應(yīng)用內(nèi)部的識(shí)別防御能力一改被動(dòng)的、外部肉盾式的防護(hù)理念，可以在無(wú)需給網(wǎng)站打補(bǔ)丁的情形下承擔(dān)起防護(hù)的責(zé)任，值得嘗試。

這里推薦一個(gè)最新的解決方案，它的名字叫 RASP（實(shí)時(shí)應(yīng)用自我保護(hù)），這種方式可以有效解決這類(lèi)的問(wèn)題。針對(duì) CSRF 漏洞問(wèn)題，RASP 定制了規(guī)則集和防護(hù)類(lèi)，然后采用 Java 字節(jié)碼技術(shù)，在被保護(hù)的類(lèi)被加載進(jìn)虛擬機(jī)之前，根據(jù)規(guī)則對(duì)被保護(hù)的類(lèi)進(jìn)行修改，將防護(hù)類(lèi)織入到被保護(hù)的類(lèi)中。大家不妨可以一試。

目前國(guó)內(nèi)僅有一家在提供 RASP 的服務(wù)廠商 OneASP。 能以最小代價(jià)并且快速解決上述難題，你只需要非常簡(jiǎn)單的修改一下 JVM 的啟動(dòng)配置，就可以將運(yùn)行。它能將攻擊過(guò)程透明化，通過(guò)控制臺(tái)可以非常清楚的知道系統(tǒng)什么時(shí)候、哪個(gè)模塊、哪行代碼遭受了哪種類(lèi)型的攻擊。同時(shí)還能夠快速修復(fù)漏洞，只要將 OneRASP 和應(yīng)用程序部署在一起就可以快速修復(fù)已知漏洞,不需要漫長(zhǎng)的掃描 - 修復(fù) - 掃描的過(guò)程。通過(guò)實(shí)時(shí)升級(jí)系統(tǒng)快速同步最新漏洞，避免零日攻擊。

當(dāng)然，只有 OneRASP 也并非萬(wàn)無(wú)一失，最優(yōu)的解決方案是將 OneRASP 和網(wǎng)絡(luò)安全解決方案、應(yīng)用安全掃描與測(cè)試等安全防護(hù)系統(tǒng)結(jié)合起來(lái),形成多層次立體的防御體系。如今各種攻擊手段層出不窮,單靠其中任一技術(shù)來(lái)防范應(yīng)用程序的安全是不科學(xué)的。但 OneRASP 永遠(yuǎn)是應(yīng)用程序安全保護(hù)的最后一道無(wú)法逾越的壕溝,它可以幫你快速提升應(yīng)用程序的安全級(jí)別，你再也不用擔(dān)憂(yōu)沒(méi)有合格的安全工程師了。當(dāng)然也確保你的企業(yè)不會(huì)作為下一個(gè)安全受害者登上頭條。

OneRASP（實(shí)時(shí)應(yīng)用自我保護(hù)）是一種基于云的應(yīng)用程序自我保護(hù)服務(wù)， 可以為軟件產(chǎn)品提供實(shí)時(shí)保護(hù)，使其免受漏洞所累。