在完成 Command Injection、SQL Injection 與 XSS 後，今天我們進入 Web 安全中另一個極具威脅的漏洞：Cross-Site Request Forgery（CSRF，跨站請求偽造）。

• 什麼是 CSRF？

CSRF 是一種利用受害者已建立的身份認證狀態（Session/Cookie），誘騙受害者瀏覽器發送非預期請求的攻擊方式。簡單來說：

1.受害者登入合法網站 A，瀏覽器保存了 Session Cookie。

2.受害者在未登出的情況下造訪惡意網站 B。

3.惡意網站 B 偷偷對網站 A 發送請求（例如修改密碼或轉帳）。

4.瀏覽器會自動帶上網站 A 的 Cookie，導致網站 A 誤以為這是受害者本人的正常操作並執行。

• DVWA 實作步驟

進入 DVWA 左側選單 CSRF。

1. 正常功能測試與 URL 觀察
   在 New password 與 Confirm 欄位輸入 123456 並點擊 Change。
   結果：畫面顯示 Password Change.。
   
   觀察：網址列變為：
   http://localhost:8080/vulnerabilities/csrf/?password_new=123456&password_conf=123456&Change=Change#
   
   這代表後端直接使用 GET 參數來處理密碼修改這種敏感操作。

• 模擬 CSRF 攻擊

攻擊者可以構造一個帶有新密碼參數的惡意連結，並誘騙受害者點擊：
http://localhost:8080/vulnerabilities/csrf/?password_new=hacked&password_conf=hacked&Change=Change#
當已登入 DVWA 的受害者點擊該連結時，瀏覽器會自動帶上 Session Cookie 發送 GET 請求，後端伺服器驗證 Cookie 成功後，即將密碼修改為 hacked。在真實世界中，攻擊者甚至不需要受害者手動點選連結，只需在惡意網站中放入隱藏的標籤即可自動觸發：

• 漏洞成因分析

if( isset( $_GET[ 'Change' ] ) ) {
$pass_new = $_GET[ 'password_new' ];
$pass_conf = $_GET[ 'password_conf' ];

if( $pass_new >= $pass_conf ) {
    $insert = "UPDATE users SET password = '$pass_new' WHERE user = '$user';";
    ...
}

}

後端缺乏任何驗證請求合法來源的機制（如 Anti-CSRF Token 或舊密碼二次驗證），僅依賴瀏覽器自動發送的 Cookie 就信任該請求。

• 如何正確防禦 CSRF？

1.使用Anti-CSRF Token：
伺服器在表單中生成一個隨機且無法預測的Token，提交表單時必須帶上此Token。由於攻擊者無法取得受害者的 Token，攻擊就會失敗。

2.設定Cookie的SameSite屬性：
將敏感Cookie的SameSite設定為Strict或Lax，防止跨站請求時自動帶上Cookie。

3.敏感操作需進行二次驗證：
修改密碼、資金轉帳等高風險操作，要求使用者必須輸入「舊密碼」或「簡訊/TOTP 驗證碼」。

4.避免使用GET處理敏感操作：
修改資料的API應嚴格使用POST/PUT/DELETE方法。