我的安全掃描檢測到“缺少 AntiForgeryToken 實作”型別的問題。我的應用程式有一層 .netCore WebApi 服務、一個帶有 RazorPages 服務的 .netCore WebApi 和一個 Angular 前端應用程式。在線閱讀所有 CSRF Token 實作是指 RazorPages 或類似但不是前端應用程式。問題是：令牌是否需要三層架構？我必須對我的 fe 執行該政策嗎？該工具檢測到的問題是否真實存在？
謝謝。
uj5u.com熱心網友回復：
首先要了解什么是antiforgerytoken？這與n層無關。如果您的專案有網頁并且您正在發出 http 請求，則應使用 AntiforgeryToken 以確保安全。
uj5u.com熱心網友回復：
架構無關緊要。
“經驗法則”是，如果您的應用程式中有用戶背景關系，那么您需要一個防偽令牌實作來防止攻擊，例如：
攻擊者使用惡意代碼欺騙用戶訪問不同的網頁（例如 evil.com），該惡意代碼秘密地向應用程式的 Web 服務器（例如 example-bank.com）發送惡意請求。
假設用戶登錄到 example-bank.com 上的應用程式。用戶打開一封電子郵件并單擊指向 evil.com 的鏈接，該鏈接在新選項卡中打開。
evil.com 頁面立即向 example-bank.com 發送惡意請求。也許這是一個將錢從用戶賬戶轉移到攻擊者賬戶的請求。瀏覽器會隨此請求自動發送 example-bank.com cookie（包括身份驗證 cookie）。
如果 example-bank.com 服務器缺少 XSRF 保護，它就無法區分來自應用程式的合法請求和來自 evil.com 的偽造請求。
參考
Angular 的 HttpClient默認啟用 XSRF Token 支持：
HttpClient 支持一種用于防止 XSRF 攻擊的通用機制。在執行 HTTP 請求時，攔截器從 cookie 中讀取令牌，默認為 XSRF-TOKEN，并將其設定為 HTTP 標頭 X-XSRF-TOKEN。因為只有在您的域上運行的代碼才能讀取 cookie，所以后端可以確定 HTTP 請求來自您的客戶端應用程式而不是攻擊者。
默認情況下，攔截器會在所有變異請求（例如 POST）上將這個標頭發送到相對 URL，但不會在 GET/HEAD 請求或具有絕對 URL 的請求上發送。
要利用這一點，您的服務器需要在頁面加載或第一個 GET 請求時在名為 XSRF-TOKEN 的 JavaScript 可讀會話 cookie 中設定一個令牌。在后續請求中，服務器可以驗證 cookie 是否與 X-XSRF-TOKEN HTTP 標頭匹配，因此確保只有在您的域上運行的代碼才能發送請求。每個用戶的令牌必須是唯一的，并且必須可由服務器驗證；這可以防止客戶端制作自己的令牌。將令牌設定為您網站的身份驗證 cookie 的摘要，并添加鹽以增加安全性。
參考
在 .net 端實施也相對簡單。
services.AddAntiforgery(options => options.HeaderName = "X-XSRF-TOKEN");
uj5u.com熱心網友回復：
底層架構無關緊要。真正的問題是你的 Angular 客戶端如何驗證它所交談的內容。
如果它使用由瀏覽器自動發送的方法（通常像 cookie，但也例如 Windows auth / SPNEGO，這可能與您的堆疊相關），那么是的，您確實需要實作針對 CSRF 的保護。
但是，如果您的身份驗證基于以請求標頭之類的形式發送的令牌（甚至在請求正文中，但重點是，不是由瀏覽器自動發送的），那么不，您的應用程式本質上不容易受到典型 CSRF 的攻擊，并且您不需要進一步保護。
轉載請註明出處，本文鏈接：https://www.uj5u.com/qukuanlian/463986.html