如何有效地抵御CSRF攻擊

今天就跟大家聊聊有關(guān)如何有效地抵御CSRF攻擊，可能很多人都不太了解，為了讓大家更加了解，小編給大家總結(jié)了以下內(nèi)容，希望大家根據(jù)這篇文章可以有所收獲。

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

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

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

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

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

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

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

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

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

為什么會(huì)這樣呢？原因是在訪問危險(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 依然可以通過嵌入 Javascript 來嘗試盜取客戶資金，所以我們時(shí)不時(shí)會(huì)聽到客戶資金被盜的案件，其實(shí)這并不是很不稀奇。

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

當(dāng)然是有的。可以給網(wǎng)站打補(bǔ)丁，如 Cookie Hashing (所有表單都包含同一個(gè)偽隨機(jī)值)。這可能是最簡(jiǎn)單的解決方案了，因?yàn)槔碚撋瞎粽卟荒塬@得第三方的 Cookie，所以表單中的數(shù)據(jù)也就構(gòu)造失敗了。但這并不是完美的解決方案，因?yàn)橛脩舻?Cookie 很容易由于網(wǎng)站的 XSS 漏洞而被盜取；另一種方法是用驗(yàn)證碼，每次的用戶提交都需要用戶在表單中填寫一個(gè)圖片上的隨機(jī)字符串....這個(gè)方案可以完全解決 CSRF，但用戶體驗(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ì)想到用防火墻來防護(hù)，那么有沒有滿足要求的產(chǎn)品呢？在去年，下一代防火墻——自適應(yīng)安全防護(hù)（RASP）這個(gè)概念橫空出世，吸引了很多企業(yè)的注意，它對(duì)請(qǐng)求上下文的感知能力和深入應(yīng)用內(nèi)部的識(shí)別防御能力一改被動(dòng)的、外部肉盾式的防護(hù)理念，可以在無需給網(wǎng)站打補(bǔ)丁的情形下承擔(dān)起防護(hù)的責(zé)任，值得嘗試。

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

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

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

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

看完上述內(nèi)容，你們對(duì)如何有效地抵御CSRF攻擊有進(jìn)一步的了解嗎？如果還想了解更多知識(shí)或者相關(guān)內(nèi)容，請(qǐng)關(guān)注億速云行業(yè)資訊頻道，感謝大家的支持。