Cross-Site Request Forgery
跨站請求偽造
跨站請求偽造（CSRF）會騙已登入的瀏覽器送出使用者沒有同意的操作。目標網站信任瀏覽器自動附上的 Cookie 或其他憑證，因此可能誤以為操作是真的。
另一個例子
已登入的薪資管理員造訪惡意頁面，該頁面嘗試用 `POST` 修改銀行帳戶。應用程式會要求綁定工作階段的 CSRF 權杖、檢查 `Origin`、使用 `SameSite` Cookie，並要求管理員重新驗證，因此能擋下操作。`GET` 連結不能修改薪資資料。
主要部分
- 01環境式已驗證 Session
- 02跨站偽造 Request
- 03Server 端 CSRF 驗證
什麼時候用
每個會改變資料、又會自動帶上憑證的瀏覽器請求，都要使用適合的權杖和來源檢查來保護。
什麼時候不要用
只使用 `POST` 並不能防護，CORS 也不是完整的 CSRF 防線。絕不能把 CSRF 權杖放在 URL 或其他網站能讀取的位置。
程式裡的名稱
synchronizer/double-submit token + Origin/Fetch Metadata checks + SameSite + reauthentication 上線前要檢查
只能在明確授權且隔離的防禦測試中操作。檢查信任邊界、無害回歸案例和緩解方法。也要檢查機密與個資處理，以及隱藏敏感資料的偵測訊號。再檢查安全失敗、事件負責人、復原與回復上一版。不得測試真實目標。
預期成果：評估並緩解 跨站請求偽造 (Cross-Site Request Forgery) 的風險。不得實作、啟用或在真實環境使用這種攻擊。 使用者情境：已登入的薪資管理員造訪惡意頁面，該頁面嘗試用 `POST` 修改銀行帳戶。應用程式會要求綁定工作階段的 CSRF 權杖、檢查 `Origin`、使用 `SameSite` Cookie，並要求管理員重新驗證，因此能擋下操作。`GET` 連結不能修改薪資資料。 要處理的風險或控制措施：跨站請求偽造 (Cross-Site Request Forgery)。 適用理由：每個會改變資料、又會自動帶上憑證的瀏覽器請求，都要使用適合的權杖和來源檢查來保護。 分類邊界：只使用 `POST` 並不能防護，CORS 也不是完整的 CSRF 防線。絕不能把 CSRF 權杖放在 URL 或其他網站能讀取的位置。 安全要求：只能在已明確授權、與外界隔離的測試環境中操作。使用無害且不會執行的輸入。保護機密與個人資料，說明哪些資料或系統可以互相信任（信任邊界），並記錄緩解方法。 營運防護：上線前設好偵測與隱藏敏感資料的記錄。指定事件負責人，並定義失敗時保持安全及回復上一版的方法。 驗收條件：防禦用回歸測試在緩解前失敗，緩解後通過。不使用真實目標、機密或個人資料。監控與回復上一版的方法都已驗證。 證據與限制（證據邊界）：它只代表該來源的官方說法。其他平台或團隊可能有不同用法。 待確認：授權範圍、受影響資產、資料等級、可能的攻擊者、事件負責人，以及回復上一版的限制。
檢查這份需求
請 AI 程式助手檢查目前如何使用 跨站請求偽造 (Cross-Site Request Forgery)。 定義：跨站請求偽造（CSRF）會騙已登入的瀏覽器送出使用者沒有同意的操作。目標網站信任瀏覽器自動附上的 Cookie 或其他憑證，因此可能誤以為操作是真的。 正式環境檢查：只能在明確授權且隔離的防禦測試中操作。檢查信任邊界、無害回歸案例和緩解方法。也要檢查機密與個資處理，以及隱藏敏感資料的偵測訊號。再檢查安全失敗、事件負責人、復原與回復上一版。不得測試真實目標。 修改程式前，先列出看到的證據、缺口、嚴重程度，以及最小且安全的修正。