Cross-Site Request Forgery
跨站请求伪造
跨站请求伪造（CSRF）会骗已登录的浏览器发出用户没有同意的操作。目标网站信任浏览器自动带上的 Cookie 或其他凭证，因此可能误以为操作是真的。
另一个例子
已登录的薪资管理员访问恶意页面，该页面尝试用 `POST` 修改银行账户。应用会要求绑定会话的 CSRF 令牌、检查 `Origin`、使用 `SameSite` Cookie，并要求管理员重新认证，因此能拦下操作。`GET` 链接不能修改薪资数据。
主要部分
- 01环境式已认证会话
- 02跨站伪造请求
- 03服务器端 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 或其他凭证，因此可能误以为操作是真的。 生产环境检查：只能在明确授权且隔离的防御测试中操作。检查信任边界、无害回归案例和缓解方法。也要检查机密与个人数据处理，以及隐藏敏感数据的检测信号。再检查安全失败、事件负责人、恢复与回到上一版。不得测试真实目标。 修改程序前，先列出看到的证据、缺口、严重程度，以及最小且安全的修正。