以下是第七周周五学习内容的详细展开。今天你将武装目标站点从攻击者视角切换到防御者视角系统学习并亲手配置 CSRF 的三大主流防御手段。你将看到昨天的攻击页面在加固后的环境中一一失效并理解每种防御的精确边界与绕过风险。第七周·周五CSRF 防御——Token、Referer 校验、SameSite 今日学习目标达成效果能准确说出CSRF Token 的工作原理随机令牌嵌入表单提交时与用户会话关联的令牌进行比对攻击者无法构造能独立实现一个包含 CSRF Token 的表单PHP 或 Python并验证缺少 Token 或 Token 错误时请求被拒绝能解释Referer 校验的防御逻辑拒绝来自非可信域的请求并明白它可能被绕过或缺失能配置SameSite Cookie 属性Lax/Strict用浏览器开发者工具观察跨站请求是否携带 Cookie能在 DVWA CSRF Medium 关卡中绕过 Referer 校验完成攻击并理解为何该校验不够坚固能在 DVWA CSRF High 关卡中体会到 CSRF Token 的防御强度并知道在没有 XSS 的前提下几乎无法绕过能总结多层防御策略Token 为主Referer/Origin 为辅SameSite 兜底并指出实现中的常见安全缺陷。 一、核心防线CSRF Token同步令牌模式1. 原理服务器在用户会话中生成一个高熵随机字符串Token将其嵌入敏感操作的请求中通常是表单的隐藏字段或自定义 HTTP 头。服务器处理请求时检查该 Token 是否存在且与当前用户会话中保存的 Token 一致。攻击者无法获知其他用户的 Token因此即使诱导用户提交请求也会因 Token 缺失或错误而被拒绝。关键要求测试题考点随机且不可预测使用密码学安全的随机数生成器防止攻击者猜测。与用户会话绑定每个用户的 Token 独立且不能跨会话复用。一次性建议每次表单加载生成新 Token或至少限制使用次数。不放入 URL若 Token 出现在 GET 参数中会被 Referer、日志、浏览器历史泄露防御失效。2. 简单实现示例PHP// 生成 Token$_SESSION[csrf_token]bin2hex(random_bytes(32));// 表单中输出echoinput typehidden namecsrf_token value.$_SESSION[csrf_token].;// 验证if($_POST[csrf_token]!$_SESSION[csrf_token]){die(CSRF token invalid);}在 Python Flask 等框架中通常由中间件自动处理。今天在 DVWA 中会看到类似实现。3. 防御效果与局限性完全抵御基本 CSRF外部攻击页面无法读取目标域的 Token受同源策略保护。唯一缺陷如果存在 XSS 漏洞攻击者可以读取页面中的 Token 或直接进行跨域请求从而使 CSRF 防御失效。因此 XSS 与 CSRF 防御必须并行。 二、辅助防线Referer / Origin 头校验1. 原理浏览器在发送请求时会附带Referer头指示请求来源页面 URL或Origin头跨站 POST 时发送仅含协议域名端口。服务器可校验该头是否属于白名单内的域名拒绝来自恶意域名的请求。2. 常见绕过与缺陷Referer 缺失部分用户代理、企业代理、HTTPS 跳转 HTTP 时不发送 Referer或通过设置Referrer-Policy: no-referrer可抑制。如果服务器仅在有 Referer 时校验攻击者可诱导浏览器不发送 Referer如使用meta标签绕过。校验逻辑不严格如果只检查 Referer 是否包含域名关键字攻击者可以在恶意 URL 路径或子域名中包含目标域名如http://target.com.evil.com/或http://evil.com/target.com绕过。Origin 头相对可靠跨站 POST 请求会发送Origin头且无法被页面 JavaScript 修改。现代防御应优先校验 Origin。3. 结论Referer/Origin 校验可作为附加层但由于多种绕过可能绝不可作为唯一防御手段。DVWA Medium 级正是使用了不严格的 Referer 校验我们将在实践中绕过它。 三、浏览器侧防线SameSite Cookie 属性1. 原理SameSite 属性控制 Cookie 在跨站请求中是否被发送从浏览器端直接削弱 CSRF 攻击基础Strict任何跨站请求包括点击链接、表单提交都不发送 Cookie。防御最彻底但可能影响用户体验如从邮件点击链接需重新登录。Lax仅顶级导航如a点击的 GET 请求会携带 Cookie跨站 POST、img、iframe、XMLHttpRequest等不发送。既防 CSRF又兼容常见浏览行为。None必须配合Secure属性允许跨站发送旧行为。2. 设置方法setcookie(PHPSESSID,$value,[samesiteLax,securetrue,httponlytrue]);或通过 Web 服务器配置。现代浏览器默认将未指定 SameSite 的 Cookie 视为Lax但显式设置更安全。3. 防御力度与局限SameSite Lax 可有效防御 POST 型 CSRF但无法防御 GET 型 CSRF如果敏感操作仍用 GET。因此仍需 Token 和规范 HTTP 方法。不支持老旧浏览器IE 部分版本因此不能单独依赖。✍️ 四、动手实践DVWA CSRF 防御的绕过与加固对比环境DVWA 靶场切换安全级别分别测试。实践 1Low 级别无防御复习昨天已成功确认可从外部页面修改密码GET 或 POST 均可。实践 2Medium 级别——Referer 校验绕过将 DVWA 安全等级设为 Medium进入 CSRF 页面。后端会检查$_SERVER[HTTP_REFERER]是否包含服务器主机名如localhost或127.0.0.1若包含则放行。尝试直接攻击用昨天的 GET 攻击页面img srchttp://靶机/vulnerabilities/csrf/?password_newhackpassword_confhackChangeChange此时 Referer 是攻击页面的 URL不包含目标主机名请求被拒绝密码未修改。绕过手法将攻击 HTML 文件命名为包含主机名的文件名例如目标主机为192.168.1.200我们将攻击页命名为192.168.1.200.html或target_192.168.1.200.html然后在受害者浏览器通过本地文件或同域打开注意Referer 是完整 URL如果攻击页面 URL 中包含192.168.1.200字符串且后端仅用stripos检查子串即可绕过。具体操作创建一个文件名为192.168.1.200.html放在攻击者 Web 服务器根目录访问http://攻击者IP/192.168.1.200.html此时 Referer 为http://攻击者IP/192.168.1.200.html包含了目标 IP绕过成功密码被修改。更可靠的方法若后端仅检查 Referer 是否以白名单开头可尝试构造从可信站点跳转的页面如通过 XSS 或开放重定向但这需要其他漏洞。通过文件名绕过是最常见的 DVWA Medium 解法。结论Referer 校验非常脆弱不能依赖。实践 3High 级别——Token 防御设置为 High进入 CSRF 页面。此时修改密码表单中包含一个隐藏的user_token字段每次刷新页面 Token 都会变化。尝试直接攻击用 POST 表单不含 token自动提交DVWA 返回 “CSRF token is incorrect”密码不变。绕过思路必须获取受害者的有效 Token。如果存在 XSS 漏洞如 DVWA 的 XSS 反射型可以编写脚本动态获取 Token 并完成修改。这属于 XSSCSRF 组合攻击证明 CSRF Token 对 XSS 无抵抗力。但如果没有 XSS攻击者无法从外部获取 Token。安全启示High 级别体现了 Token 的正确防御能力同时也强调了 XSS 与 CSRF 的密切关系。实践 4SameSite 演示可选环境搭建使用自己编写的 Python Web 服务设置 Cookie 为 SameSiteLax然后尝试跨站 POST 表单攻击会发现请求中没有 Cookie。详细步骤可参考之前 Cookie 实验增加 SameSite 属性后对比。 五、课后测试题与解析测试题为什么 CSRF Token 必须随机且不可预测请从攻击者角度说明。参考答案CSRF Token 必须使用密码学安全的随机数生成器产生确保攻击者无法猜测或计算出其他用户的有效 Token。如果 Token 是递增的序号、时间戳或简单的哈希攻击者可以通过分析自己会话的 Token 规律推算出受害者可能使用的 Token 值然后将其嵌入攻击页面从而绕过 CSRF 防御。此外Token 需要与用户会话严格绑定并在每次使用后或合理有效期后失效防止重放攻击。因此足够的随机性和不可预测性是 CSRF Token 安全的核心。✅ 今日学习效果自检清单我能够实现一个简单的 CSRF Token 生成与验证逻辑我明白了 Referer 校验容易通过文件名构造或空 Referer 绕过我在 DVWA Medium 中成功绕过了 Referer 检查我在 DVWA High 中验证了 Token 防御的有效性我知道 SameSite Cookie 属性如何从浏览器端减少 CSRF 风险我能设计一套合理的 CSRF 防御方案Token SameSite Referer/Origin 辅助⚠️ 阶段避坑重点不要将 Token 放在 URL 中GET 请求的参数会泄露到 Referer 和日志使 Token 失去保密性。不要仅依赖 Referer 校验它很容易被绕过并且某些合规场景下 Referer 可能被故意禁用。不要以为有了 Token 就绝对安全如果 Token 生成不随机、未绑定会话、或者存在 XSS 漏洞Token 仍然可能被窃取或绕过。SameSite 不是万能不支持老浏览器且 Lax 不能防御 GET 型 CSRF因此仍需配合其他防御手段。注意框架默认配置许多现代 Web 框架已内置 CSRF 保护但需要确保它未被错误关闭。明天我们将进行 DVWA CSRF 关卡的全难度综合实操并要求你编写完整的防御实现代码将这几天攻防两端的技术全部内化。请保留今天修改的攻击页面和防御观察明天将进行最终巩固。