跳至內容

CSRF 保護

簡介

跨網站請求偽造是一種惡意攻擊,藉由代表已驗證的使用者執行未經授權的命令。幸好,Laravel 可以輕鬆保護您的應用程式免受跨網站請求偽造 (CSRF) 攻擊。

漏洞說明

如果您不熟悉跨網站請求偽造,讓我們討論一個關於如何利用此漏洞的範例。假設您的應用程式有一個 /user/email 路由,該路由接受 POST 請求以變更已驗證使用者的電子郵件地址。最有可能的是,此路由會預期 email 輸入欄位包含使用者想要開始使用的電子郵件地址。

在沒有 CSRF 保護的情況下,惡意網站可以建立一個指向您應用程式 /user/email 路由的 HTML 表單,並提交惡意使用者自己的電子郵件地址

<form action="https://your-application.com/user/email" method="POST">
<input type="email" value="[email protected]">
</form>
 
<script>
document.forms[0].submit();
</script>

如果惡意網站在頁面載入時自動提交表單,則惡意使用者只需要誘使您應用程式的毫無戒心的使用者訪問他們的網站,他們的電子郵件地址就會在您的應用程式中變更。

為了防止此漏洞,我們需要檢查每個傳入的 POSTPUTPATCHDELETE 請求,以查看惡意應用程式無法存取的秘密 session 值。

防止 CSRF 請求

Laravel 會自動為應用程式管理的每個活動使用者 session產生一個 CSRF「token」。此 token 用於驗證已驗證的使用者是否是實際向應用程式發出請求的人。由於此 token 儲存在使用者的 session 中,並且每次 session 重新產生時都會變更,因此惡意應用程式無法存取它。

目前 session 的 CSRF token 可以透過請求的 session 或 csrf_token 輔助函數存取

use Illuminate\Http\Request;
 
Route::get('/token', function (Request $request) {
$token = $request->session()->token();
 
$token = csrf_token();
 
// ...
});

每當您在應用程式中定義「POST」、「PUT」、「PATCH」或「DELETE」HTML 表單時,您都應該在表單中包含隱藏的 CSRF _token 欄位,以便 CSRF 保護中介層可以驗證請求。為了方便起見,您可以使用 @csrf Blade 指令來產生隱藏的 token 輸入欄位

<form method="POST" action="/profile">
@csrf
 
<!-- Equivalent to... -->
<input type="hidden" name="_token" value="{{ csrf_token() }}" />
</form>

預設包含在 web 中介層群組中的 Illuminate\Foundation\Http\Middleware\ValidateCsrfToken 中介層將自動驗證請求輸入中的 token 是否與儲存在 session 中的 token 相符。當這兩個 token 相符時,我們知道已驗證的使用者是發起請求的人。

CSRF Tokens & SPAs

如果您正在建構將 Laravel 用作 API 後端的 SPA,您應該查閱Laravel Sanctum 文件,以取得有關使用 API 進行驗證和防止 CSRF 漏洞的資訊。

從 CSRF 保護中排除 URI

有時您可能希望將一組 URI 從 CSRF 保護中排除。例如,如果您使用 Stripe 處理付款並使用其 webhook 系統,則您需要將 Stripe webhook 處理程式路由從 CSRF 保護中排除,因為 Stripe 不會知道要將哪個 CSRF token 發送到您的路由。

通常,您應該將這些路由放置在 Laravel 應用於 routes/web.php 檔案中所有路由的 web 中介層群組之外。但是,您也可以透過將其 URI 提供給應用程式 bootstrap/app.php 檔案中的 validateCsrfTokens 方法來排除特定路由

->withMiddleware(function (Middleware $middleware) {
$middleware->validateCsrfTokens(except: [
'stripe/*',
'http://example.com/foo/bar',
'http://example.com/foo/*',
]);
})
lightbulb

為了方便起見,當執行測試時,CSRF 中介層會自動停用所有路由。

X-CSRF-TOKEN

除了檢查 CSRF token 是否為 POST 參數外,預設包含在 web 中介層群組中的 Illuminate\Foundation\Http\Middleware\ValidateCsrfToken 中介層也會檢查 X-CSRF-TOKEN 請求標頭。例如,您可以將 token 儲存在 HTML meta 標籤中

<meta name="csrf-token" content="{{ csrf_token() }}">

然後,您可以指示像 jQuery 這樣的程式庫自動將 token 新增到所有請求標頭中。這為您使用舊版 JavaScript 技術的 AJAX 應用程式提供了簡單、方便的 CSRF 保護

$.ajaxSetup({
headers: {
'X-CSRF-TOKEN': $('meta[name="csrf-token"]').attr('content')
}
});

X-XSRF-TOKEN

Laravel 將目前的 CSRF token 儲存在加密的 XSRF-TOKEN cookie 中,該 cookie 包含在框架產生的每個回應中。您可以使用 cookie 值設定 X-XSRF-TOKEN 請求標頭。

此 cookie 主要作為開發人員的便利性而傳送,因為某些 JavaScript 框架和程式庫(如 Angular 和 Axios)會自動將其值放入同源請求的 X-XSRF-TOKEN 標頭中。

lightbulb

預設情況下,resources/js/bootstrap.js 檔案包含 Axios HTTP 程式庫,該程式庫會自動為您傳送 X-XSRF-TOKEN 標頭。