一.基本概念

1.定義

跨站請求偽造（Cross - Site Request Forgery，縮寫為 CSRF）漏洞是一種網絡安全漏洞。它是指攻擊者通過誘導用戶訪問一個惡意網站，利用用戶在被信任網站（如銀行網站、社交網站等）的登錄狀態，在用戶不知情的情況下，讓用戶的瀏覽器向被信任網站發送非用戶本意的請求，從而執行一些操作，比如修改用戶信息、進行轉賬等操作。

2.示例

• 假設用戶已經登錄了一個網上銀行網站bank.com?，其會話 ID 存儲在瀏覽器的 Cookie 中。攻擊者創建了一個惡意網站evil.com?，在這個網站上有如下 HTML 代碼：

  <form action="https://bank.com/transfer" method="post"><input type="hidden" name="amount" value="1000" /><input type="hidden" name="recipient" value="attacker_account" />
  </form>
  <script>document.forms[0].submit();
  </script>
  

• 當用戶訪問evil.com?時，瀏覽器會自動提交這個表單，向bank.com?發送一個轉賬請求。由于瀏覽器會帶上用戶在bank.com?的會話 Cookie，bank.com?會認為這個請求是用戶自己發起的，從而可能導致用戶的資金被盜轉。

3.危害

• 用戶數據泄露和篡改：攻擊者可以通過 CSRF 漏洞獲取用戶的敏感信息，如修改用戶密碼、郵箱地址等，從而進一步控制用戶賬戶。
• 經濟損失：在涉及金融交易的網站上，攻擊者可以利用 CSRF 漏洞進行非法轉賬、購物等操作，給用戶造成直接的經濟損失。
• 破壞系統功能和信譽：可以對系統的正常功能造成干擾，如大量發送虛假請求，導致系統資源被濫用。同時，也會影響用戶對網站的信任，損害網站的信譽。

二.漏洞類型

GET型CSRF

1.定義

GET 型 CSRF（Cross - Site Request Forgery）是 CSRF 攻擊的一種類型。在這種攻擊方式中，攻擊者誘導用戶的瀏覽器發起一個 HTTP GET 請求，利用用戶在目標網站的登錄狀態，在用戶不知情的情況下執行目標網站上的某些操作。

2.攻擊流程

1. 構造惡意鏈接：攻擊者首先會構造一個包含惡意請求的鏈接。因為 HTTP GET 請求通常用于獲取資源，在網頁中，鏈接（<a>?標簽）、圖像（<img>?標簽）、腳本（<script>?標簽）等元素都可以發起 GET 請求。

2. 利用自動請求機制：

   • 例如，使用<img>?標簽來發起攻擊。攻擊者在惡意網站上放置一個<img>?標簽，將其src?屬性設置為目標網站帶有惡意操作的 GET 請求鏈接。當用戶訪問這個惡意網站時，瀏覽器會自動嘗試加載這個圖像，從而發送這個 GET 請求。
   • 同樣，對于<a>?標簽，攻擊者可以設置href?屬性為惡意鏈接，然后通過一些手段（如欺騙用戶點擊看起來正常的鏈接）來讓用戶觸發這個請求。不過這種方式相對比較容易被用戶察覺，因為用戶可能會看到鏈接的地址。

3. 利用用戶會話狀態：就像其他類型的 CSRF 攻擊一樣，GET 型 CSRF 依賴于用戶在目標網站的會話狀態。當瀏覽器發送這個惡意的 GET 請求時，會自動帶上用戶在目標網站的會話 Cookie，目標網站收到請求后，由于有有效的會話標識，就可能會執行這個請求，以為是用戶自己發起的操作。

3.示例

• 假設一個社交網站有一個點贊功能，其點贊的接口是https://social.com/like?post_id=123?，正常情況下，用戶點擊社交網站上的點贊按鈕會發送這個 GET 請求來為 ID 為 123 的帖子點贊。

• 攻擊者在惡意網站上放置了這樣的代碼：

  <img src="https://social.com/like?post_id=123" alt="malicious_image" />
  

• 當用戶訪問這個惡意網站時，瀏覽器會自動加載這個 “圖像”，實際上就發送了一個點贊的 GET 請求。由于用戶在社交網站的會話 Cookie 會被一起發送，社交網站就可能會為帖子 ID 為 123 的內容點贊，而用戶對此可能完全不知情。

POST型CSRF

1.定義

POST 型 CSRF（Cross - Site Request Forgery）是一種跨站請求偽造攻擊類型，它利用 HTTP POST 請求來實施攻擊。攻擊者通過誘導用戶在已登錄目標網站的狀態下，在用戶瀏覽器不知情的情況下發送包含惡意意圖的 POST 請求，從而導致目標網站執行非用戶本意的操作。

2.攻擊流程

1. 構造惡意表單：攻擊者在惡意網站上構造一個包含目標網站惡意操作的表單。表單的action?屬性指向目標網站中執行關鍵操作的 URL，例如銀行轉賬的提交 URL、用戶信息修改的提交頁面等。表單的各個字段則填寫攻擊者想要執行的操作參數，如轉賬金額、修改后的用戶信息等。

2. 自動提交表單或誘使用戶提交：

   • 攻擊者可以使用 JavaScript 代碼來自動提交表單。例如，在惡意 HTML 頁面中有如下代碼：

     <form id="attackForm" action="https://target.com/transfer" method="post"><input type="hidden" name="amount" value="1000" /><input type="hidden" name="recipient" value="attacker_account" />
     </form>
     <script>document.getElementById('attackForm').submit();
     </script>
     

   • 當用戶訪問這個惡意網站時，瀏覽器會自動提交這個表單，向目標網站發送一個 POST 請求。或者，攻擊者也可以通過一些手段誘使用戶手動提交表單，例如將提交按鈕偽裝成一個吸引人的鏈接或按鈕，讓用戶在不知情的情況下點擊。

3. 利用用戶會話狀態：和 GET 型 CSRF 一樣，POST 型 CSRF 也依賴于用戶在目標網站的會話狀態。當瀏覽器發送這個 POST 請求時，會自動帶上用戶在目標網站的會話 Cookie，目標網站收到請求后，由于收到了帶有有效用戶會話標識（Cookie）的請求，就會執行這個請求，以為是用戶自己發起的操作。

三.防御措施

• 使用 CSRF 令牌（Token）：

  • 網站在生成表單或關鍵請求時，同時生成一個唯一的 CSRF 令牌并將其包含在表單中或者作為請求頭的一部分。當服務器收到請求時，會驗證這個令牌是否有效。因為攻擊者無法輕易獲取這個令牌，所以無法偽造有效的請求。

• 驗證請求來源（Referer 檢查）：

  • 服務器可以檢查請求的來源（即Referer?頭信息），如果請求來自一個不可信的源，就拒絕這個請求。不過這種方法有一定的局限性，因為Referer?頭信息可以被瀏覽器插件或者用戶自己修改。

• Same - Site Cookie 屬性設置：

  • 可以將 Cookie 的Same - Site?屬性設置為Strict?或者Lax?。Strict?模式下，瀏覽器只有在用戶從同一站點訪問時才會發送 Cookie；Lax?模式稍微寬松一些，在一些安全的跨站導航場景下也允許發送 Cookie。這樣可以限制 Cookie 在跨站請求中的濫用，從而減輕 CSRF 攻擊的風險。