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

創(chuàng)新互聯(lián)公司專業(yè)為企業(yè)提供吳興網(wǎng)站建設(shè)、吳興做網(wǎng)站、吳興網(wǎng)站設(shè)計、吳興網(wǎng)站制作等企業(yè)網(wǎng)站建設(shè)、網(wǎng)頁設(shè)計與制作、吳興企業(yè)網(wǎng)站模板建站服務，十載吳興做網(wǎng)站經(jīng)驗，不只是建網(wǎng)站，更提供有價值的思路和整體網(wǎng)絡服務。

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

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

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

這個過程到底是怎樣的呢？讓我們看個簡單而鮮活的案例。

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

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

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

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

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

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

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

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

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

當然是有的。可以給網(wǎng)站打補丁，如 Cookie Hashing (所有表單都包含同一個偽隨機值)。這可能是最簡單的解決方案了，因為理論上攻擊者不能獲得第三方的 Cookie，所以表單中的數(shù)據(jù)也就構(gòu)造失敗了。但這并不是完美的解決方案，因為用戶的 Cookie 很容易由于網(wǎng)站的 XSS 漏洞而被盜??；另一種方法是用驗證碼，每次的用戶提交都需要用戶在表單中填寫一個圖片上的隨機字符串....這個方案可以完全解決 CSRF，但用戶體驗很遭罪（忒麻煩了）。還有一種是 One-Time Tokens(不同的表單包含不同的偽隨機值)，需要設(shè)計令牌和 Session 管理邏輯，并修改 Web 表單，網(wǎng)站運維又很遭罪。

以上所有辦法都需要對網(wǎng)站進行修修補補，再花費很多氣力去測試?？赡苡腥藭氲接梅阑饓矸雷o，那么有沒有滿足要求的產(chǎn)品呢？在去年，下一代防火墻——自適應安全防護（RASP）這個概念橫空出世，吸引了很多企業(yè)的注意，它對請求上下文的感知能力和深入應用內(nèi)部的識別防御能力一改被動的、外部肉盾式的防護理念，可以在無需給網(wǎng)站打補丁的情形下承擔起防護的責任，值得嘗試。

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

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

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

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

看完上述內(nèi)容，你們對如何有效地抵御CSRF攻擊有進一步的了解嗎？如果還想了解更多知識或者相關(guān)內(nèi)容，請關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道，感謝大家的支持。