如何检测和记录 CSRF 攻击，有哪些监控策略？

CSRF 攻击的检测依赖对请求来源和行为的异常识别，核心监控策略包括 Referer/Origin 校验、Token 失效记录、请求频率异常检测和日志溯源分析。

检测 CSRF 攻击的三个关键信号

1. 请求头异常——非 GET 请求缺失 Referer 或 Origin 与目标域名不匹配，是最直接的攻击特征。Referer Check 不能作为唯一防御手段，但作为检测指标非常有效。

2. Token 校验失败——服务端验证 CSRF Token 不通过时，记录该请求的来源 IP、User-Agent、时间戳和目标路径。高频 Token 失败通常意味着定向攻击。

3. 行为模式异常——同一用户短时间内发起大量状态变更请求，或请求来源 IP 与历史地理位置不匹配（如1小时内跨1000公里），需要结合业务场景判断。

监控策略怎么落地

• 中间件层拦截+记录：在 CSRF Token 校验中间件中，校验失败时同步写入结构化日志，字段包括 eventType（detected/blocked）、confidence（置信度）、patterns（匹配的异常类型）
• Referer/Origin 白名单监控：维护合法来源域名列表，非白名单来源的写操作请求触发告警
• 频率阈值告警：对同一 IP 或用户 ID，10秒内超过20次写请求触发异常标记，配合 Prometheus + Alertmanager 推送
• 日志聚合分析：按时间窗口统计攻击趋势、Top 攻击 IP、高频异常模式，生成日报辅助策略调优

面试追问

Q: 为什么 Referer Check 不能单独做防御？ Referer 可被用户隐私设置或浏览器策略省略，正常请求也可能缺失 Referer，单独依赖会误拦合法请求。但它作为检测信号仍然有效——有 Referer 但域名不匹配，基本可以判定可疑。

Q: SameSite Cookie 能完全替代 CSRF Token 吗？ 不能。SameSite=Lax 只保护跨站顶级导航的 POST 请求，同站内的 XSS 配合 CSRF 仍可绕过。此外老旧浏览器不支持 SameSite 属性。两者应该组合使用。