网站测试报告：WEB应用反CSRF的本质与防御机制

CSRF (跨站请求伪造) 本质：
攻击者诱骗已登录目标站点的用户，在不知情的情况下提交一个恶意请求。该请求利用用户浏览器中已存储的认证信息（如Cookie、Session），以该用户的身份执行未授权的操作（如修改密码、转账）。

主流防御机制
安全测试的核心在于验证这些机制是否被正确实现及其强度。
CSRF Tokens：最常用机制。服务器为每个会话或表单生成一个不可预测的令牌（Token），嵌入表单（通常为隐藏域）或HTTP头。处理请求时，服务器验证该令牌的有效性。
SameSite Cookie属性：通过设置Cookie的SameSite属性（Strict或Lax），限制第三方网站在发起跨站请求时携带认证Cookie。
自定义HTTP头：通常用于AJAX请求，检查是否存在预期的自定义头（如X-Requested-With）。由于浏览器同源策略限制，第三方站点通常无法发送自定义头。
验证Referer/Origin头：服务器检查HTTP请求头中的Origin或Referer字段，判断请求是否来源于可信的本站域名。

对捕获到的CSRF请求进行仔细检查，识别应用采用了哪种或哪几种混合防御机制

1.寻找CSRF Token：
位置：在HTTP请求中，Token可能出现在：
POST请求的Body中（如csrf_token=abc123）。
GET请求的URL参数中（如?action=change&csrf_token=abc123）。
HTTP自定义头中（如X-CSRF-Token: abc123）。

手动提交两次相同请求，观察Token是否变化？Token是否与当前用户会话（Session）绑定？Token是否一次性使用？

2.检查Cookie的SameSite属性：
在开发者工具的“Application”或“存储”选项卡中，检查与认证相关的Cookie是否设置了SameSite属性。值是Strict, Lax, 还是 None？
3.检查自定义头：
观察请求是否包含了如X-Requested-With: XMLHttpRequest或其他非标准头部。移除该头后服务器是否仍然处理请求？
4.验证Referer/Origin依赖：
尝试手动修改或完全移除请求中的Referer和Origin头，观察服务器的响应。如果请求被拒绝，说明服务器可能依赖此头进行校验。