1. 绪论沉睡的巨人——认识CSRF漏洞在广阔的网络世界中各种安全漏洞如同隐藏在代码深处的陷阱随时可能被恶意攻击者利用。其中跨站请求伪造Cross-Site Request Forgery简称CSRF读作“sea-surf”是一种古老但威力巨大的漏洞。它不像跨站脚本XSS那样直接攻击网站本身而是巧妙地利用了网站对用户浏览器的信任在用户毫不知情的情况下以用户自己的身份执行非法操作。CSRF攻击的核心思想在于“伪造请求”。当一个用户在受信任的网站上已经通过身份验证例如登录了网上银行其浏览器中会保存该网站的会话凭证通常是Cookie。此时如果用户被诱导访问了一个攻击者精心设计的恶意网站这个恶意网站就可以向受信任的网站发送精心构造的请求。由于请求携带着用户的合法凭证受信任的网站会误以为这是用户本人的意愿从而执行请求中的操作如修改密码、转账、发布内容等。整个过程用户和网站都被蒙在鼓里。由于其独特的攻击方式CSRF在安全领域也有着许多形象的别名。微软在其文档中喜欢称之为一键式攻击One-Click Attack因为攻击者只需要诱导用户点击一下就能达成目的。此外它也被称为会话劫持Session Riding因为它劫持了用户当前的会话来执行恶意操作。无论名称如何其本质都是利用服务器对客户端请求的盲目信任。为了深入理解CSRF我们可以从广义和狭义两个维度来审视它狭义的CSRF指在攻击者已经通过某种方式如XSS漏洞将恶意代码植入到用户正在访问的页面中然后以“受害用户”的身份向服务端发起伪造的HTTP请求。这种攻击通常需要结合其他漏洞。广义的CSRF这是更常见的理解。攻击者能够预测或构造出一个合法的HTTP请求所需的所有参数如URL、GET/POST参数等然后通过某种方式如在自己的恶意网站上诱导受害者浏览器发起这个请求。无论是否借助受害者的浏览器只要攻击者能成功冒充用户调用接口就构成了广义上的CSRF。本文将主要围绕广义的CSRF展开深入探讨其原理、利用方式、检测手段以及全面的防御策略。2. 核心原理信任的滥用CSRF漏洞的存在根源在于Web应用对于用户请求的验证机制存在缺陷。为了彻底理解它我们需要拆解其背后的核心原理。2.1 攻击的三要素一次成功的CSRF攻击通常需要满足三个基本条件受害者必须登录目标网站受害者的浏览器中必须持有目标网站例如bank.com的有效会话凭证主要是Cookie。如果用户没有登录那么伪造的请求要么因为没有认证信息被拒绝要么即使通过如公开访问的页面也达不到“伪造用户操作”的目的。目标网站存在可被利用的请求目标网站必须有一个可以改变状态或执行敏感操作的接口如转账、改密。并且这个接口的请求参数是可以被攻击者完全预测或构造的。如果接口需要复杂的、无法猜测的动态参数如当前时间戳的哈希值那么攻击者就很难成功。攻击者能诱导用户触发请求攻击者需要能够引诱受害者在已登录状态访问其控制的恶意网站或者点击恶意链接/图片。这是社会工程学的一部分。2.2 浏览器会话管理Cookie的自动发送机制Cookie是Web应用维持用户状态的最常用手段。当用户登录一个网站后服务器会在HTTP响应中设置一个包含会话标识Session ID的Cookie。此后只要浏览器向该网站的域名发起任何请求无论是点击链接、提交表单还是加载图片浏览器都会自动地、无条件地在请求头中附带上这个Cookie。这个设计初衷是为了提供无缝的用户体验但却成为了CSRF攻击得以实现的关键。攻击者正是利用了浏览器这种“诚实”的特性让服务器无法区分一个请求是用户主动发出的还是被恶意网站“强制”发出的。2.3 攻击流程全解析从用户登录到请求伪造让我们通过一个经典的网上银行转账案例来全景式地剖析CSRF攻击的完整流程。第一步用户正常登录建立信任会话用户通过浏览器登录其网上银行www.bank.com。服务器验证用户名密码正确后在响应中设置一个会话Cookie。此时用户的浏览器与bank.com之间建立了信任关系。text// 服务器响应头示例 Set-Cookie: sessionidabc123...; Path/; HttpOnly第二步用户访问恶意网站在保持登录状态的同时用户又因某种原因如收到一封诱人的广告邮件使用同一个浏览器访问了攻击者控制的恶意网站www.evil.com。第三步恶意网站构造并发送伪造请求恶意网站www.evil.com的页面中嵌入了攻击者精心构造的HTML代码。这段代码的目的就是向www.bank.com发送一个转账请求。例如它可以是一个隐藏的表单配合JavaScript在页面加载时自动提交html!—evil.com 页面中的代码 -- html body h1Congratulations! Youre a Winner!/h1 form idcsrfForm actionhttps://www.bank.com/api/transfer methodPOST input typehidden nametoAccount valueattacker123 / input typehidden nameamount value10000 / /form script // 页面加载完成后自动提交表单 document.getElementById(csrfForm).submit(); /script /body /html当用户的浏览器加载这个页面时会自动执行脚本向bank.com发起POST请求。第四步浏览器自动携带合法凭证由于请求目标是www.bank.com浏览器在处理这个由evil.com发起的请求时会自动地在请求头中附带上之前保存的www.bank.com的会话Cookie。第五步服务器被蒙蔽执行非法操作银行服务器www.bank.com接收到这个POST请求。它检查请求发现附带了有效的会话Cookiesessionidabc123...于是认为这个转账操作就是合法用户本人发起的。服务器执行转账逻辑将10000元从用户账户转到了攻击者指定的账户attacker123。第六步攻击完成用户可能毫无察觉转账操作在后台完成用户可能完全不知道发生了什么直到后来查看账户余额才发现异常。整个过程如下图所示2.4 CSRF与XSS的本质区别CSRF和XSS跨站脚本是经常被一起提及的两大客户端攻击技术但它们有着本质的区别。理解这种区别对于安全防护至关重要。特征CSRF (跨站请求伪造)XSS (跨站脚本)攻击起源外部触发。攻击代码存储在攻击者的服务器上。内部注入。恶意脚本被注入到目标网站的页面中。攻击原理利用服务器对用户的信任。伪造用户的请求。利用用户对网站的信任。在目标网站上下文中执行脚本。是否需要登录是。受害者必须在目标网站保持登录状态。否/是。可以窃取未登录用户的会话或针对登录用户操作。代码执行位置恶意网站。目标网站本身。攻击后果执行状态更改操作转账、改密。窃取Cookie、键盘记录、页面篡改、跳转钓鱼网站等能力更强。能否读取响应不能。攻击者无法看到服务器返回的内容。能。脚本可以读取并窃取页面中的任何数据。简单来说CSRF是“冒名顶替”而XSS是“无间道”。XSS由于可以直接在目标网站内执行JavaScript因此它通常可以绕过绝大多数CSRF防御因为脚本可以像正常用户一样获取并提交防御所需的Token。3. CSRF漏洞的主要攻击类型根据攻击者构造请求的方式不同CSRF攻击可以主要分为以下几种类型。3.1 GET类型的CSRF这是最简单、最原始的一种CSRF形式。当目标网站使用HTTP GET请求来执行敏感操作时漏洞就出现了。例如一个银行网站可能允许通过如下GET请求进行转账GET http://bank.com/transfer.do?acctAliceamount100 HTTP/1.1攻击者只需构造一个包含此URL的恶意资源链接诱导用户点击或加载即可。最常见的方式是使用img标签img srchttp://bank.com/transfer.do?acctattackeramount10000 width0 height0 border0当浏览器加载这个不可见的图片时就会自动向该URL发起一个GET请求。由于浏览器会自动携带Cookie转账操作便在用户毫无察觉的情况下完成了。最佳实践是永远不要使用GET请求来修改服务器状态。3.2 POST类型的CSRF大多数敏感操作会要求使用POST方法但这并不能防御CSRF。攻击者只需在自己的页面上创建一个隐藏的表单并在页面加载时用JavaScript自动提交它。htmlform actionhttp://bank.com/transfer.do methodPOST idcsrfform input typehidden nameacct valueattacker / input typehidden nameamount value10000 / /form scriptdocument.getElementById(csrfform).submit();/script当用户访问这个页面时表单会立刻提交浏览器同样会自动附带Cookie伪造的POST请求成功。3.3 链接类型的CSRF这种类型需要用户的主动点击。攻击者将恶意请求的URL伪装成一个普通链接放在论坛、评论区或电子邮件中并配以诱人的文字诱导用户点击。例如a hrefhttp://bank.com/transfer.do?acctattackeramount10000点击领取丰厚奖品/a虽然需要用户交互但在社会工程学的包装下成功率依然很高。4. 漏洞检测与挖掘发现隐藏的威胁在安全测试或渗透过程中发现CSRF漏洞是关键一步。检测方法主要分为静态分析和动态验证。4.1 静态检测代码审计与特征识别静态检测是在不运行程序的情况下通过分析源代码来寻找潜在漏洞。主要关注点包括识别状态改变接口搜索所有处理写操作增、删、改的接口如update、delete、transfer、change、edit、settings等。检查防御措施对于识别出的敏感接口检查其代码中是否实施了有效的CSRF防御。例如在Java的Spring Security中是否配置了.csrf()在PHP中是否调用了wp_verify_nonce()函数验证随机数或者是否校验了Referer头。危险代码模式警惕一些常见的错误实现。例如在WordPress插件中一个经典的逻辑错误是php// 错误示例逻辑运算符使用不当导致防护失效 if (!isset($_POST[nonce]) !wp_verify_nonce($_POST[nonce], action)) { wp_die(Security check failed); // 如果 nonce 存在第一个条件为假整个if不执行验证被绕过 } // 正确做法使用 || if (!isset($_POST[nonce]) || !wp_verify_nonce($_POST[nonce], action)) { wp_die(Security check failed); }检查依赖库版本确认使用的框架或第三方库的CSRF防护组件是否存在已知漏洞。例如历史上 Go 语言的gorilla/csrf库就曾因Referer验证逻辑错误而存在漏洞CVE-2025-24358允许同顶级域名下的子站进行CSRF攻击。4.2 动态验证手动测试与工具利用动态验证是模拟真实攻击过程确认漏洞是否真实存在且可利用。手动测试流程准备环境在浏览器中登录目标网站作为受害者。捕获正常请求使用浏览器开发者工具F12的“网络”Network标签操作一个敏感功能如修改个人资料捕获其发出的HTTP请求。记录下URL、请求方法GET/POST、请求头特别是Cookie和Referer以及请求体POST参数。构造PoC对于GET请求将请求URL直接复制到浏览器的新标签页地址栏中修改关键参数如转账目标账号后回车。观察操作是否成功。对于POST请求根据捕获的请求参数手动创建一个简单的HTML页面包含一个指向目标URL的、参数相同的隐藏表单。模拟攻击在同一个浏览器但新标签页中打开你刚刚创建的本地HTML文件或将其上传到测试服务器访问。观察页面是否自动提交了请求然后切换回目标网站页面刷新查看状态是否被更改例如资料是否真的被修改了。检查开发者工具中该请求的响应状态码。如果返回200 OK并且操作成功而原始请求中是包含CSRF Token的则说明存在漏洞。正常被拦截的CSRF请求应返回403 Forbidden或类似的错误。自动化工具辅助Burp Suite强大的Web渗透测试工具。它有一个内置的“CSRF PoC Generator”功能。在Burp中捕获到敏感请求后右键点击选择“Engagement tools” - “Generate CSRF PoC”Burp会自动生成一个包含隐藏表单的HTML页面。你可以直接复制这个HTML代码用于测试。OWASP ZAP另一个知名的开源Web应用安全扫描器同样具备自动生成CSRF攻击向量的功能。CSRF Tester一款专门用于CSRF漏洞检测的工具。5. 深度防御策略构建多层次防护体系防御CSRF的核心思想是在请求中加入攻击者无法伪造的信息并由服务器进行验证。单一防御措施可能存在局限构建多层次的纵深防御体系是最佳实践。5.1 黄金标准CSRF Token同步令牌CSRF Token或称防伪令牌是目前最主流、最有效的防御方式遵循同步器令牌模式Synchronizer Token PatternSTP。原理生成当用户访问包含表单的页面时服务器生成一个唯一、随机、不可预测的字符串Token并将其与当前用户的会话Session进行关联。服务器将这个Token作为隐藏字段嵌入到表单中input typehidden namecsrf_token value随机字符串。存储服务器端将Token存储在会话中或者使用加密方式存储在Cookie中如双重提交Cookie模式。验证当用户提交表单时浏览器会将表单中的Token和Cookie一起发送给服务器。服务器取出请求中的Token与当前用户会话中存储的Token进行比较。结果如果Token存在且匹配则请求被认为是合法的如果Token缺失或不匹配则请求被拒绝。要点不可预测性Token必须使用强随机数生成器创建避免被攻击者猜测。每会话/每请求通常每个用户会话使用一个Token更严格的做法是每个请求都生成新的Token。服务器端验证验证必须在服务器端进行不能依赖任何客户端逻辑。实现示例ASP.NET CoreRazor页面中使用FormTagHelper会自动生成防伪令牌htmlform methodpost !-- ... 表单内容 ... -- /form其生成的HTML会包含一个隐藏字段htmlinput name__RequestVerificationToken typehidden valueCfDJ8NrAkS...s2-m9Yw5.2 同源检测验证Referer和Origin头这是一种较为轻量级的防御方式通过检查HTTP请求头中的来源信息来判断请求是否来自可信的源。Origin头在跨域请求中浏览器会自动添加Origin头指明请求的来源协议域名端口。这个头信息无法通过JavaScript修改因此可靠性很高。服务器可以检查Origin头如果其值与自己的域名不匹配则拒绝请求。Referer头Referer头指示请求的完整来源页面URL。服务器可以检查Referer头是否以自己网站的域名开头。但这种方法存在一些局限性出于隐私原因用户或浏览器可能禁用发送Referer。某些浏览器或插件可能存在Referer泄露或被篡改的风险。依赖于Referer作为唯一防御手段是危险的。如上文提到的gorilla/csrf漏洞就是因为Referer验证逻辑存在缺陷而被绕过。5.3 现代浏览器特性SameSite Cookie这是浏览器层面提供的一项非常强大的防御机制。通过在设置Cookie时添加SameSite属性可以控制Cookie在跨站请求中是否发送。SameSiteStrict最为严格。浏览器只在同站请求即请求来源与目标域名完全一致中发送此Cookie。任何跨站请求即使是点击链接都不会携带Cookie。这能防御绝大部分CSRF但可能会影响用户体验例如从Google搜索点击链接进入你的网站因为不是同站请求用户需要重新登录。SameSiteLax默认值现代浏览器。在大多数跨站请求中如加载图片、iframe、提交表单Cookie不会被发送。但在一些“顶层导航”的安全上下文中例如通过点击a链接、link relprerender或GET表单且是顶层导航跳转时会发送Cookie。这是安全与体验的平衡。SameSiteNone关闭SameSite限制允许所有跨站请求携带Cookie。但此选项必须配合Secure属性一起使用即Cookie只能通过HTTPS连接发送。将关键会话Cookie的SameSite属性设为Lax或Strict可以有效防御大量通过第三方网站发起的CSRF攻击。5.4 辅助手段验证码与二次鉴权对于极端敏感的操作如转账、修改主邮箱、删除账号等可以引入人机交互验证从根本上阻断CSRF攻击。验证码要求用户输入图片中的字符或完成拼图。攻击者无法在自动化请求中模拟这一步骤。二次鉴权要求用户重新输入密码或输入通过短信/邮件收到的动态验证码。这确保了操作是由用户本人主动发起的。5.5 框架内置防护与WAF利用框架安全机制现代Web开发框架如Spring Security Django ASP.NET Core Express.js等都内置了CSRF防护机制。开发者应优先启用并正确使用框架提供的防护功能而不是自己从头实现因为自己实现的方案更容易出错。部署WAFWeb应用防火墙WAF可以在网络层面对流量进行监控和过滤。它可以实施CSRF防护策略如检查Referer/Origin头、校验Token等为应用提供一层额外的、独立于代码的防护。WAF的优势在于可以集中管理和快速更新防护规则。5.6 各防御机制对比为了更清晰地理解不同防御手段的特点下表进行了简要对比防御机制核心原理优点缺点/局限性CSRF Token请求中包含服务器生成的、不可伪造的随机令牌。最成熟、最可靠的防御方式业界标准。需要开发支持需保证令牌的机密性和不可预测性。Referer/Origin检查验证请求来源是否合法。实现简单无需修改页面代码。Referer可能为空或被篡改依赖浏览器行为不能作为唯一防御。SameSite Cookie浏览器根据请求是否同站来决定是否发送Cookie。浏览器原生支持配置简单效果显著。不是所有浏览器版本都完全兼容Lax模式对某些GET请求无效。验证码/二次鉴权确认操作由真实用户主动发起。安全性极高能防御自动化攻击。严重影响用户体验只适用于最关键的操作。WAF防护在网络层集中检测和拦截恶意请求。独立于应用代码可集中管理和快速响应。可能存在误报攻击者可能研究绕过技术。6. 实战案例分析漏洞的危害与演化理论结合实践才能更深刻地理解CSRF。以下通过几个不同时期和平台的真实案例展示CSRF漏洞的危害和利用方式。6.1 WordPress插件中的逻辑缺陷WordPress使用一种称为“Nonce”Number used once的机制来抵御CSRF。然而开发者的错误实现会导致防护形同虚设。漏洞案例曾在超过60万个活跃安装的 WordPress 插件Fluent Forms中存在一个CSRF漏洞。漏洞的根源在于开发者使用逻辑运算符而非||来检查Nonce。php// 有漏洞的代码 if (!isset($_POST[nonce]) !wp_verify_nonce($_POST[nonce], action)) { wp_die(Security check failed); }这段代码的本意是如果nonce参数不存在并且验证失败则终止执行。然而当攻击者提供一个存在但无效的nonce时第一个条件!isset($_POST[nonce])为false整个if条件false ...的结果为false安全检查被完全跳过恶意请求得以执行。一个小小的操作符错误就导致了严重的安全问题。影响攻击者可以诱导管理员访问恶意网站从而在不知情的情况下修改插件设置、注入恶意脚本最终可能导致网站被完全控制。6.2 Jira服务器的内网扫描器这个案例展示了CSRF漏洞不仅限于操作用户数据还能被用作跳板攻击内网。漏洞背景在Atlassian Jira Server和Data Center 8.7.0之前的版本中存在一个CSRF漏洞CVE-2019-20099。攻击过程Jira的管理员在设置POP3邮件服务器的功能中有一个“测试连接”按钮。研究人员发现当点击测试连接时发出的请求既没有验证CSRF Token也没有检查Referer头。攻击者构造一个恶意网页其中包含一个自动提交的表单该表单指向Jira的“测试连接”接口并指定了攻击者想要探测的内网IP地址和端口如172.16.68.229:110。当已登录的Jira管理员其浏览器可以访问内网访问该恶意网页时其浏览器会向Jira服务器发送伪造的测试连接请求。Jira服务器收到请求后会以自己的身份而不是管理员的浏览器向攻击者指定的内网IP和端口发起真实的POP3连接尝试。攻击者可以通过分析连接请求的耗时来判断该内网IP和端口是否存活从而绘制出内网网络拓扑。结论这个漏洞将CSRF的危害从“操作用户数据”升级到了“利用服务器作为跳板进行内网探测”风险等级大大提高。6.3 框架库的Referer验证绕过即使应用代码本身没问题其依赖的底层安全库也可能存在缺陷。漏洞案例在Go语言中广泛使用的CSRF防护库gorilla/csrf从2015年首次发布到2025年修复的1.7.3版本之前一直存在一个Referer验证的绕过漏洞CVE-2025-24358。漏洞原理该库原本设计在HTTPS连接下会验证Referer头。但它判断是否为HTTPS连接的方式是检查请求结构体中的r.URL.Scheme。然而根据Go语言的规范在服务器端接收到的请求中这个Scheme字段永远是空的。因此这个关键的Referer验证逻辑实际上从未被执行过防护形同虚设。影响如果一个攻击者能够通过XSS等手段控制与目标网站同顶级域名如evil.example.com攻击bank.example.com的任意子站点就可以利用此漏洞结合Cookie的domain属性设置对目标站点发起成功的CSRF攻击。7. 未来趋势与挑战智能化的攻防随着Web技术的发展CSRF攻击与防御的博弈也在持续演进。7.1 AI驱动的自动化检测人工智能和机器学习技术正在被引入安全领域用于更智能地检测CSRF漏洞。行为分析AI模型可以学习正常用户的操作行为模式建立基线。当检测到异常请求序列时例如短时间内从不同IP发起大量修改操作或者操作时间不符合用户习惯可以实时告警或阻断。代码语义分析AI可以像经验丰富的安全专家一样深入理解代码的语义逻辑从而发现更深层次的、传统规则匹配难以发现的逻辑型CSRF漏洞。零日漏洞预测通过分析历史漏洞数据和新框架的特性AI模型或许能预测可能出现新型CSRF攻击模式的方向。7.2 自动化防御与编排未来的安全防御将更加自动化并与安全编排自动化与响应SOAR平台深度融合。自动阻断与修复当WAF或运行时应用自我保护RASP检测到针对某接口的CSRF攻击尝试时可以自动生成防护规则进行阻断甚至可以自动在代码层面创建工单分配给开发者进行修复。攻击链溯源结合全链路追踪和日志分析自动重构攻击者的完整攻击路径帮助安全团队快速定位漏洞根源。7.3 新兴挑战复杂架构下的防护现代Web应用日益复杂也给CSRF防护带来了新的挑战。微服务架构在一个请求可能跨越多个微服务的架构中如何保持CSRF Token的上下文一致性是一个需要仔细设计的问题。单页应用SPASPA通常使用API与后端交互传统的表单Token可能不适用。常见的做法是使用双重提交Cookie模式Double Submit Cookie即后端在Cookie中设置一个随机值并要求前端在每个API请求的自定义头如X-CSRF-Token中提交这个值。服务器验证Cookie中的值和请求头中的值是否匹配。由于同源策略限制来自恶意站点的请求无法读取或设置目标站点的自定义头。无感化防护未来的防护技术将更加注重用户体验。例如利用设备指纹、行为生物特征等无感方式在后台默默完成用户身份的二次确认而无需用户主动输入验证码。8. 结语CSRF漏洞这个利用了Web最基本信任模型的攻击方式虽然在防御技术日益成熟的今天已经得到了很大程度的遏制但它从未真正消失。从开发者的一个逻辑运算符错误到安全库的一个实现缺陷再到新兴架构的配置不当都可能为CSRF攻击敞开大门。对于开发者而言防御CSRF应成为一种编码本能首要原则永远不要使用GET请求来修改服务器状态。黄金法则始终启用并正确使用框架提供的CSRF防护机制这是最简单也是最有效的防线。纵深防御结合SameSite属性、关键操作的二次验证构建多层防护。保持敬畏不要盲目信任任何请求来源即使它携带着合法的Cookie。对每一个写操作接口都要问一句“我如何确认这是用户本人的意图”
web渗透-CSRF漏洞：原理、实战与深度防御
发布时间：2026/5/19 3:08:35
1. 绪论沉睡的巨人——认识CSRF漏洞在广阔的网络世界中各种安全漏洞如同隐藏在代码深处的陷阱随时可能被恶意攻击者利用。其中跨站请求伪造Cross-Site Request Forgery简称CSRF读作“sea-surf”是一种古老但威力巨大的漏洞。它不像跨站脚本XSS那样直接攻击网站本身而是巧妙地利用了网站对用户浏览器的信任在用户毫不知情的情况下以用户自己的身份执行非法操作。CSRF攻击的核心思想在于“伪造请求”。当一个用户在受信任的网站上已经通过身份验证例如登录了网上银行其浏览器中会保存该网站的会话凭证通常是Cookie。此时如果用户被诱导访问了一个攻击者精心设计的恶意网站这个恶意网站就可以向受信任的网站发送精心构造的请求。由于请求携带着用户的合法凭证受信任的网站会误以为这是用户本人的意愿从而执行请求中的操作如修改密码、转账、发布内容等。整个过程用户和网站都被蒙在鼓里。由于其独特的攻击方式CSRF在安全领域也有着许多形象的别名。微软在其文档中喜欢称之为一键式攻击One-Click Attack因为攻击者只需要诱导用户点击一下就能达成目的。此外它也被称为会话劫持Session Riding因为它劫持了用户当前的会话来执行恶意操作。无论名称如何其本质都是利用服务器对客户端请求的盲目信任。为了深入理解CSRF我们可以从广义和狭义两个维度来审视它狭义的CSRF指在攻击者已经通过某种方式如XSS漏洞将恶意代码植入到用户正在访问的页面中然后以“受害用户”的身份向服务端发起伪造的HTTP请求。这种攻击通常需要结合其他漏洞。广义的CSRF这是更常见的理解。攻击者能够预测或构造出一个合法的HTTP请求所需的所有参数如URL、GET/POST参数等然后通过某种方式如在自己的恶意网站上诱导受害者浏览器发起这个请求。无论是否借助受害者的浏览器只要攻击者能成功冒充用户调用接口就构成了广义上的CSRF。本文将主要围绕广义的CSRF展开深入探讨其原理、利用方式、检测手段以及全面的防御策略。2. 核心原理信任的滥用CSRF漏洞的存在根源在于Web应用对于用户请求的验证机制存在缺陷。为了彻底理解它我们需要拆解其背后的核心原理。2.1 攻击的三要素一次成功的CSRF攻击通常需要满足三个基本条件受害者必须登录目标网站受害者的浏览器中必须持有目标网站例如bank.com的有效会话凭证主要是Cookie。如果用户没有登录那么伪造的请求要么因为没有认证信息被拒绝要么即使通过如公开访问的页面也达不到“伪造用户操作”的目的。目标网站存在可被利用的请求目标网站必须有一个可以改变状态或执行敏感操作的接口如转账、改密。并且这个接口的请求参数是可以被攻击者完全预测或构造的。如果接口需要复杂的、无法猜测的动态参数如当前时间戳的哈希值那么攻击者就很难成功。攻击者能诱导用户触发请求攻击者需要能够引诱受害者在已登录状态访问其控制的恶意网站或者点击恶意链接/图片。这是社会工程学的一部分。2.2 浏览器会话管理Cookie的自动发送机制Cookie是Web应用维持用户状态的最常用手段。当用户登录一个网站后服务器会在HTTP响应中设置一个包含会话标识Session ID的Cookie。此后只要浏览器向该网站的域名发起任何请求无论是点击链接、提交表单还是加载图片浏览器都会自动地、无条件地在请求头中附带上这个Cookie。这个设计初衷是为了提供无缝的用户体验但却成为了CSRF攻击得以实现的关键。攻击者正是利用了浏览器这种“诚实”的特性让服务器无法区分一个请求是用户主动发出的还是被恶意网站“强制”发出的。2.3 攻击流程全解析从用户登录到请求伪造让我们通过一个经典的网上银行转账案例来全景式地剖析CSRF攻击的完整流程。第一步用户正常登录建立信任会话用户通过浏览器登录其网上银行www.bank.com。服务器验证用户名密码正确后在响应中设置一个会话Cookie。此时用户的浏览器与bank.com之间建立了信任关系。text// 服务器响应头示例 Set-Cookie: sessionidabc123...; Path/; HttpOnly第二步用户访问恶意网站在保持登录状态的同时用户又因某种原因如收到一封诱人的广告邮件使用同一个浏览器访问了攻击者控制的恶意网站www.evil.com。第三步恶意网站构造并发送伪造请求恶意网站www.evil.com的页面中嵌入了攻击者精心构造的HTML代码。这段代码的目的就是向www.bank.com发送一个转账请求。例如它可以是一个隐藏的表单配合JavaScript在页面加载时自动提交html!—evil.com 页面中的代码 -- html body h1Congratulations! Youre a Winner!/h1 form idcsrfForm actionhttps://www.bank.com/api/transfer methodPOST input typehidden nametoAccount valueattacker123 / input typehidden nameamount value10000 / /form script // 页面加载完成后自动提交表单 document.getElementById(csrfForm).submit(); /script /body /html当用户的浏览器加载这个页面时会自动执行脚本向bank.com发起POST请求。第四步浏览器自动携带合法凭证由于请求目标是www.bank.com浏览器在处理这个由evil.com发起的请求时会自动地在请求头中附带上之前保存的www.bank.com的会话Cookie。第五步服务器被蒙蔽执行非法操作银行服务器www.bank.com接收到这个POST请求。它检查请求发现附带了有效的会话Cookiesessionidabc123...于是认为这个转账操作就是合法用户本人发起的。服务器执行转账逻辑将10000元从用户账户转到了攻击者指定的账户attacker123。第六步攻击完成用户可能毫无察觉转账操作在后台完成用户可能完全不知道发生了什么直到后来查看账户余额才发现异常。整个过程如下图所示2.4 CSRF与XSS的本质区别CSRF和XSS跨站脚本是经常被一起提及的两大客户端攻击技术但它们有着本质的区别。理解这种区别对于安全防护至关重要。特征CSRF (跨站请求伪造)XSS (跨站脚本)攻击起源外部触发。攻击代码存储在攻击者的服务器上。内部注入。恶意脚本被注入到目标网站的页面中。攻击原理利用服务器对用户的信任。伪造用户的请求。利用用户对网站的信任。在目标网站上下文中执行脚本。是否需要登录是。受害者必须在目标网站保持登录状态。否/是。可以窃取未登录用户的会话或针对登录用户操作。代码执行位置恶意网站。目标网站本身。攻击后果执行状态更改操作转账、改密。窃取Cookie、键盘记录、页面篡改、跳转钓鱼网站等能力更强。能否读取响应不能。攻击者无法看到服务器返回的内容。能。脚本可以读取并窃取页面中的任何数据。简单来说CSRF是“冒名顶替”而XSS是“无间道”。XSS由于可以直接在目标网站内执行JavaScript因此它通常可以绕过绝大多数CSRF防御因为脚本可以像正常用户一样获取并提交防御所需的Token。3. CSRF漏洞的主要攻击类型根据攻击者构造请求的方式不同CSRF攻击可以主要分为以下几种类型。3.1 GET类型的CSRF这是最简单、最原始的一种CSRF形式。当目标网站使用HTTP GET请求来执行敏感操作时漏洞就出现了。例如一个银行网站可能允许通过如下GET请求进行转账GET http://bank.com/transfer.do?acctAliceamount100 HTTP/1.1攻击者只需构造一个包含此URL的恶意资源链接诱导用户点击或加载即可。最常见的方式是使用img标签img srchttp://bank.com/transfer.do?acctattackeramount10000 width0 height0 border0当浏览器加载这个不可见的图片时就会自动向该URL发起一个GET请求。由于浏览器会自动携带Cookie转账操作便在用户毫无察觉的情况下完成了。最佳实践是永远不要使用GET请求来修改服务器状态。3.2 POST类型的CSRF大多数敏感操作会要求使用POST方法但这并不能防御CSRF。攻击者只需在自己的页面上创建一个隐藏的表单并在页面加载时用JavaScript自动提交它。htmlform actionhttp://bank.com/transfer.do methodPOST idcsrfform input typehidden nameacct valueattacker / input typehidden nameamount value10000 / /form scriptdocument.getElementById(csrfform).submit();/script当用户访问这个页面时表单会立刻提交浏览器同样会自动附带Cookie伪造的POST请求成功。3.3 链接类型的CSRF这种类型需要用户的主动点击。攻击者将恶意请求的URL伪装成一个普通链接放在论坛、评论区或电子邮件中并配以诱人的文字诱导用户点击。例如a hrefhttp://bank.com/transfer.do?acctattackeramount10000点击领取丰厚奖品/a虽然需要用户交互但在社会工程学的包装下成功率依然很高。4. 漏洞检测与挖掘发现隐藏的威胁在安全测试或渗透过程中发现CSRF漏洞是关键一步。检测方法主要分为静态分析和动态验证。4.1 静态检测代码审计与特征识别静态检测是在不运行程序的情况下通过分析源代码来寻找潜在漏洞。主要关注点包括识别状态改变接口搜索所有处理写操作增、删、改的接口如update、delete、transfer、change、edit、settings等。检查防御措施对于识别出的敏感接口检查其代码中是否实施了有效的CSRF防御。例如在Java的Spring Security中是否配置了.csrf()在PHP中是否调用了wp_verify_nonce()函数验证随机数或者是否校验了Referer头。危险代码模式警惕一些常见的错误实现。例如在WordPress插件中一个经典的逻辑错误是php// 错误示例逻辑运算符使用不当导致防护失效 if (!isset($_POST[nonce]) !wp_verify_nonce($_POST[nonce], action)) { wp_die(Security check failed); // 如果 nonce 存在第一个条件为假整个if不执行验证被绕过 } // 正确做法使用 || if (!isset($_POST[nonce]) || !wp_verify_nonce($_POST[nonce], action)) { wp_die(Security check failed); }检查依赖库版本确认使用的框架或第三方库的CSRF防护组件是否存在已知漏洞。例如历史上 Go 语言的gorilla/csrf库就曾因Referer验证逻辑错误而存在漏洞CVE-2025-24358允许同顶级域名下的子站进行CSRF攻击。4.2 动态验证手动测试与工具利用动态验证是模拟真实攻击过程确认漏洞是否真实存在且可利用。手动测试流程准备环境在浏览器中登录目标网站作为受害者。捕获正常请求使用浏览器开发者工具F12的“网络”Network标签操作一个敏感功能如修改个人资料捕获其发出的HTTP请求。记录下URL、请求方法GET/POST、请求头特别是Cookie和Referer以及请求体POST参数。构造PoC对于GET请求将请求URL直接复制到浏览器的新标签页地址栏中修改关键参数如转账目标账号后回车。观察操作是否成功。对于POST请求根据捕获的请求参数手动创建一个简单的HTML页面包含一个指向目标URL的、参数相同的隐藏表单。模拟攻击在同一个浏览器但新标签页中打开你刚刚创建的本地HTML文件或将其上传到测试服务器访问。观察页面是否自动提交了请求然后切换回目标网站页面刷新查看状态是否被更改例如资料是否真的被修改了。检查开发者工具中该请求的响应状态码。如果返回200 OK并且操作成功而原始请求中是包含CSRF Token的则说明存在漏洞。正常被拦截的CSRF请求应返回403 Forbidden或类似的错误。自动化工具辅助Burp Suite强大的Web渗透测试工具。它有一个内置的“CSRF PoC Generator”功能。在Burp中捕获到敏感请求后右键点击选择“Engagement tools” - “Generate CSRF PoC”Burp会自动生成一个包含隐藏表单的HTML页面。你可以直接复制这个HTML代码用于测试。OWASP ZAP另一个知名的开源Web应用安全扫描器同样具备自动生成CSRF攻击向量的功能。CSRF Tester一款专门用于CSRF漏洞检测的工具。5. 深度防御策略构建多层次防护体系防御CSRF的核心思想是在请求中加入攻击者无法伪造的信息并由服务器进行验证。单一防御措施可能存在局限构建多层次的纵深防御体系是最佳实践。5.1 黄金标准CSRF Token同步令牌CSRF Token或称防伪令牌是目前最主流、最有效的防御方式遵循同步器令牌模式Synchronizer Token PatternSTP。原理生成当用户访问包含表单的页面时服务器生成一个唯一、随机、不可预测的字符串Token并将其与当前用户的会话Session进行关联。服务器将这个Token作为隐藏字段嵌入到表单中input typehidden namecsrf_token value随机字符串。存储服务器端将Token存储在会话中或者使用加密方式存储在Cookie中如双重提交Cookie模式。验证当用户提交表单时浏览器会将表单中的Token和Cookie一起发送给服务器。服务器取出请求中的Token与当前用户会话中存储的Token进行比较。结果如果Token存在且匹配则请求被认为是合法的如果Token缺失或不匹配则请求被拒绝。要点不可预测性Token必须使用强随机数生成器创建避免被攻击者猜测。每会话/每请求通常每个用户会话使用一个Token更严格的做法是每个请求都生成新的Token。服务器端验证验证必须在服务器端进行不能依赖任何客户端逻辑。实现示例ASP.NET CoreRazor页面中使用FormTagHelper会自动生成防伪令牌htmlform methodpost !-- ... 表单内容 ... -- /form其生成的HTML会包含一个隐藏字段htmlinput name__RequestVerificationToken typehidden valueCfDJ8NrAkS...s2-m9Yw5.2 同源检测验证Referer和Origin头这是一种较为轻量级的防御方式通过检查HTTP请求头中的来源信息来判断请求是否来自可信的源。Origin头在跨域请求中浏览器会自动添加Origin头指明请求的来源协议域名端口。这个头信息无法通过JavaScript修改因此可靠性很高。服务器可以检查Origin头如果其值与自己的域名不匹配则拒绝请求。Referer头Referer头指示请求的完整来源页面URL。服务器可以检查Referer头是否以自己网站的域名开头。但这种方法存在一些局限性出于隐私原因用户或浏览器可能禁用发送Referer。某些浏览器或插件可能存在Referer泄露或被篡改的风险。依赖于Referer作为唯一防御手段是危险的。如上文提到的gorilla/csrf漏洞就是因为Referer验证逻辑存在缺陷而被绕过。5.3 现代浏览器特性SameSite Cookie这是浏览器层面提供的一项非常强大的防御机制。通过在设置Cookie时添加SameSite属性可以控制Cookie在跨站请求中是否发送。SameSiteStrict最为严格。浏览器只在同站请求即请求来源与目标域名完全一致中发送此Cookie。任何跨站请求即使是点击链接都不会携带Cookie。这能防御绝大部分CSRF但可能会影响用户体验例如从Google搜索点击链接进入你的网站因为不是同站请求用户需要重新登录。SameSiteLax默认值现代浏览器。在大多数跨站请求中如加载图片、iframe、提交表单Cookie不会被发送。但在一些“顶层导航”的安全上下文中例如通过点击a链接、link relprerender或GET表单且是顶层导航跳转时会发送Cookie。这是安全与体验的平衡。SameSiteNone关闭SameSite限制允许所有跨站请求携带Cookie。但此选项必须配合Secure属性一起使用即Cookie只能通过HTTPS连接发送。将关键会话Cookie的SameSite属性设为Lax或Strict可以有效防御大量通过第三方网站发起的CSRF攻击。5.4 辅助手段验证码与二次鉴权对于极端敏感的操作如转账、修改主邮箱、删除账号等可以引入人机交互验证从根本上阻断CSRF攻击。验证码要求用户输入图片中的字符或完成拼图。攻击者无法在自动化请求中模拟这一步骤。二次鉴权要求用户重新输入密码或输入通过短信/邮件收到的动态验证码。这确保了操作是由用户本人主动发起的。5.5 框架内置防护与WAF利用框架安全机制现代Web开发框架如Spring Security Django ASP.NET Core Express.js等都内置了CSRF防护机制。开发者应优先启用并正确使用框架提供的防护功能而不是自己从头实现因为自己实现的方案更容易出错。部署WAFWeb应用防火墙WAF可以在网络层面对流量进行监控和过滤。它可以实施CSRF防护策略如检查Referer/Origin头、校验Token等为应用提供一层额外的、独立于代码的防护。WAF的优势在于可以集中管理和快速更新防护规则。5.6 各防御机制对比为了更清晰地理解不同防御手段的特点下表进行了简要对比防御机制核心原理优点缺点/局限性CSRF Token请求中包含服务器生成的、不可伪造的随机令牌。最成熟、最可靠的防御方式业界标准。需要开发支持需保证令牌的机密性和不可预测性。Referer/Origin检查验证请求来源是否合法。实现简单无需修改页面代码。Referer可能为空或被篡改依赖浏览器行为不能作为唯一防御。SameSite Cookie浏览器根据请求是否同站来决定是否发送Cookie。浏览器原生支持配置简单效果显著。不是所有浏览器版本都完全兼容Lax模式对某些GET请求无效。验证码/二次鉴权确认操作由真实用户主动发起。安全性极高能防御自动化攻击。严重影响用户体验只适用于最关键的操作。WAF防护在网络层集中检测和拦截恶意请求。独立于应用代码可集中管理和快速响应。可能存在误报攻击者可能研究绕过技术。6. 实战案例分析漏洞的危害与演化理论结合实践才能更深刻地理解CSRF。以下通过几个不同时期和平台的真实案例展示CSRF漏洞的危害和利用方式。6.1 WordPress插件中的逻辑缺陷WordPress使用一种称为“Nonce”Number used once的机制来抵御CSRF。然而开发者的错误实现会导致防护形同虚设。漏洞案例曾在超过60万个活跃安装的 WordPress 插件Fluent Forms中存在一个CSRF漏洞。漏洞的根源在于开发者使用逻辑运算符而非||来检查Nonce。php// 有漏洞的代码 if (!isset($_POST[nonce]) !wp_verify_nonce($_POST[nonce], action)) { wp_die(Security check failed); }这段代码的本意是如果nonce参数不存在并且验证失败则终止执行。然而当攻击者提供一个存在但无效的nonce时第一个条件!isset($_POST[nonce])为false整个if条件false ...的结果为false安全检查被完全跳过恶意请求得以执行。一个小小的操作符错误就导致了严重的安全问题。影响攻击者可以诱导管理员访问恶意网站从而在不知情的情况下修改插件设置、注入恶意脚本最终可能导致网站被完全控制。6.2 Jira服务器的内网扫描器这个案例展示了CSRF漏洞不仅限于操作用户数据还能被用作跳板攻击内网。漏洞背景在Atlassian Jira Server和Data Center 8.7.0之前的版本中存在一个CSRF漏洞CVE-2019-20099。攻击过程Jira的管理员在设置POP3邮件服务器的功能中有一个“测试连接”按钮。研究人员发现当点击测试连接时发出的请求既没有验证CSRF Token也没有检查Referer头。攻击者构造一个恶意网页其中包含一个自动提交的表单该表单指向Jira的“测试连接”接口并指定了攻击者想要探测的内网IP地址和端口如172.16.68.229:110。当已登录的Jira管理员其浏览器可以访问内网访问该恶意网页时其浏览器会向Jira服务器发送伪造的测试连接请求。Jira服务器收到请求后会以自己的身份而不是管理员的浏览器向攻击者指定的内网IP和端口发起真实的POP3连接尝试。攻击者可以通过分析连接请求的耗时来判断该内网IP和端口是否存活从而绘制出内网网络拓扑。结论这个漏洞将CSRF的危害从“操作用户数据”升级到了“利用服务器作为跳板进行内网探测”风险等级大大提高。6.3 框架库的Referer验证绕过即使应用代码本身没问题其依赖的底层安全库也可能存在缺陷。漏洞案例在Go语言中广泛使用的CSRF防护库gorilla/csrf从2015年首次发布到2025年修复的1.7.3版本之前一直存在一个Referer验证的绕过漏洞CVE-2025-24358。漏洞原理该库原本设计在HTTPS连接下会验证Referer头。但它判断是否为HTTPS连接的方式是检查请求结构体中的r.URL.Scheme。然而根据Go语言的规范在服务器端接收到的请求中这个Scheme字段永远是空的。因此这个关键的Referer验证逻辑实际上从未被执行过防护形同虚设。影响如果一个攻击者能够通过XSS等手段控制与目标网站同顶级域名如evil.example.com攻击bank.example.com的任意子站点就可以利用此漏洞结合Cookie的domain属性设置对目标站点发起成功的CSRF攻击。7. 未来趋势与挑战智能化的攻防随着Web技术的发展CSRF攻击与防御的博弈也在持续演进。7.1 AI驱动的自动化检测人工智能和机器学习技术正在被引入安全领域用于更智能地检测CSRF漏洞。行为分析AI模型可以学习正常用户的操作行为模式建立基线。当检测到异常请求序列时例如短时间内从不同IP发起大量修改操作或者操作时间不符合用户习惯可以实时告警或阻断。代码语义分析AI可以像经验丰富的安全专家一样深入理解代码的语义逻辑从而发现更深层次的、传统规则匹配难以发现的逻辑型CSRF漏洞。零日漏洞预测通过分析历史漏洞数据和新框架的特性AI模型或许能预测可能出现新型CSRF攻击模式的方向。7.2 自动化防御与编排未来的安全防御将更加自动化并与安全编排自动化与响应SOAR平台深度融合。自动阻断与修复当WAF或运行时应用自我保护RASP检测到针对某接口的CSRF攻击尝试时可以自动生成防护规则进行阻断甚至可以自动在代码层面创建工单分配给开发者进行修复。攻击链溯源结合全链路追踪和日志分析自动重构攻击者的完整攻击路径帮助安全团队快速定位漏洞根源。7.3 新兴挑战复杂架构下的防护现代Web应用日益复杂也给CSRF防护带来了新的挑战。微服务架构在一个请求可能跨越多个微服务的架构中如何保持CSRF Token的上下文一致性是一个需要仔细设计的问题。单页应用SPASPA通常使用API与后端交互传统的表单Token可能不适用。常见的做法是使用双重提交Cookie模式Double Submit Cookie即后端在Cookie中设置一个随机值并要求前端在每个API请求的自定义头如X-CSRF-Token中提交这个值。服务器验证Cookie中的值和请求头中的值是否匹配。由于同源策略限制来自恶意站点的请求无法读取或设置目标站点的自定义头。无感化防护未来的防护技术将更加注重用户体验。例如利用设备指纹、行为生物特征等无感方式在后台默默完成用户身份的二次确认而无需用户主动输入验证码。8. 结语CSRF漏洞这个利用了Web最基本信任模型的攻击方式虽然在防御技术日益成熟的今天已经得到了很大程度的遏制但它从未真正消失。从开发者的一个逻辑运算符错误到安全库的一个实现缺陷再到新兴架构的配置不当都可能为CSRF攻击敞开大门。对于开发者而言防御CSRF应成为一种编码本能首要原则永远不要使用GET请求来修改服务器状态。黄金法则始终启用并正确使用框架提供的CSRF防护机制这是最简单也是最有效的防线。纵深防御结合SameSite属性、关键操作的二次验证构建多层防护。保持敬畏不要盲目信任任何请求来源即使它携带着合法的Cookie。对每一个写操作接口都要问一句“我如何确认这是用户本人的意图”
