1. 项目概述为什么CSRF是逻辑漏洞的“隐形杀手”做安全测试或者漏洞挖掘的朋友对CSRFCross-Site Request Forgery跨站请求伪造这个名字肯定不陌生。但很多人尤其是刚入门的朋友常常把它和XSS跨站脚本攻击搞混或者觉得它“危害不大”、“利用条件苛刻”。我刚开始接触安全时也这么想直到在一次真实的企业渗透测试中我们利用一个简单的CSRF漏洞在管理员毫无察觉的情况下批量删除了后台的所有用户数据才真正体会到它的威力——它不直接偷你的“钥匙”Session而是骗你用你自己的“钥匙”去开一扇危险的门。这是一种典型的逻辑漏洞攻击者利用的是应用在业务逻辑设计上的缺陷而非系统底层的代码执行或内存溢出问题。简单来说CSRF攻击的核心在于“冒名顶替”。想象一下这个场景你登录了网上银行此时浏览器保存了你的登录凭证Cookie然后你不小心点开了一个恶意网页。这个网页里藏着一个自动提交的表单目标正是网上银行的转账接口。由于浏览器会自动带上你登录银行的Cookie银行服务器看到这个带有合法Cookie的请求就会认为是你本人操作的从而成功执行转账。整个过程攻击者完全不知道你的密码也不需要窃取你的Cookie他只是在“借用”你的身份和权限。这就是逻辑漏洞的可怕之处系统每一步的验证从技术上看都没错用户已登录Session有效但整个请求的发起逻辑是错的并非用户本意。所以把CSRF单纯看作一个技术点来学习是远远不够的。它更像是一个切入点让我们去审视一个Web应用在“状态管理”和“请求授权”逻辑上是否足够健壮。从零基础到精通CSRF不仅仅是学会几个Payload更是建立起一套发现和防御逻辑漏洞的思维模式。这篇文章我会结合我这些年踩过的坑和实战经验从原理、场景、手工与工具测试方法、高级利用技巧到防御方案带你彻底吃透CSRF。无论你是想入门安全测试的学生还是希望提升自家产品安全性的开发者收藏这一篇足够你搭建起关于CSRF的完整知识体系。2. CSRF漏洞核心原理深度拆解要理解CSRF我们必须深入到HTTP协议和浏览器同源策略的细节中去。很多人对原理一知半解导致在漏洞挖掘和防御时总是抓不住重点。2.1 攻击发生的三要素缺一不可一个成功的CSRF攻击必须同时满足以下三个条件这就像一把锁的三道机关全部打开才能生效关键操作存在语义化动作目标应用存在一个可以通过HTTP请求通常是GET或POST触发的“状态改变”操作。比如修改密码、转账、发表评论、删除项目、添加管理员等。仅仅是查询数据的操作如查看个人资料通常不构成严重威胁。请求可预测且无不可伪造令牌攻击者能够完全预测出触发该操作所需请求的所有参数。更重要的是应用在处理这个请求时没有使用随机的、一次性的、与当前用户会话绑定的令牌即CSRF Token进行验证。请求的鉴权完全依赖于浏览器自动携带的凭证如Session Cookie、Basic Auth头等。受害者已认证并保持会话受害者用户必须已经登录了目标网站并且浏览器中仍然保存着有效的会话凭证如Cookie未过期。同时受害者需要访问攻击者构造的恶意页面。这三个条件中第二个条件是防御的关键也是我们漏洞挖掘时重点寻找的突破点。如果应用为每个敏感表单都生成了一个唯一的、随机的CSRF Token并验证该Token的有效性那么即使攻击者能预测其他所有参数也无法伪造出合法的请求。2.2 浏览器“自动提交”机制详解这是CSRF攻击得以实现的技术基础。浏览器的同源策略Same-Origin Policy限制了不同源站点之间的脚本互访但它并没有禁止从一个源向另一个源“发送请求”。关键在于浏览器在发送跨域请求时会根据请求类型和内容决定是否自动携带目标站点的凭证如Cookie。简单请求与非简单请求对于GET请求、以及Content-Type为application/x-www-form-urlencoded、multipart/form-data或text/plain的POST请求浏览器会直接发出并自动携带Cookie。这类请求极易被CSRF利用例如通过img src“https://bank.com/transfer?toattackeramount1000”标签发起的GET请求或者通过自动提交的HTML表单发起的POST请求。预检请求Preflight对于非简单请求如Content-Type为application/json或带有自定义头的请求浏览器会先发送一个OPTIONS方法的预检请求服务器响应允许后才会发送真正的请求。这里有一个常见的误区很多人认为使用AJAX发送JSON请求就能天然防御CSRF。实际上如果服务器没有正确配置CORS跨域资源共享策略在特定条件下例如某些浏览器的旧版本或配置不当攻击依然可能发生。更稳妥的做法是无论请求类型如何都对改变状态的接口实施CSRF防护。理解这一点就能明白为什么仅仅把GET请求改成POST请求并不能防御CSRF。攻击者完全可以构造一个隐藏的form表单用JavaScript自动提交同样可以发起POST请求。2.3 与XSS的本质区别权限的“窃取”与“冒用”这是新手最容易混淆的地方。我画个简单的对比表特性CSRF (跨站请求伪造)XSS (跨站脚本攻击)攻击目标利用用户的登录状态以用户身份执行非授权操作。在用户浏览器中执行恶意脚本窃取信息或进行其他攻击。所需条件用户已登录目标站点目标站点存在逻辑漏洞无Token验证。目标站点存在输入输出过滤不严的漏洞允许注入脚本。攻击者视角不需要获取用户的Cookie或Session。通常需要窃取Cookie、Session或其他敏感信息。核心利用伪造HTTP请求。注入并执行JavaScript代码。关系XSS漏洞可能导致更严重的CSRF攻击例如通过XSS窃取CSRF Token。CSRF通常不依赖XSS但两者结合威力巨大。简单记XSS是“在你的地盘浏览器里搞破坏”而CSRF是“冒充你去别的地方其他网站干坏事”。一个关注“执行环境”一个关注“请求身份”。3. 手工挖掘CSRF漏洞的实战流程知道了原理我们就要上手找。手工挖掘CSRF漏洞是一个需要耐心和细致观察的过程。下面是我常用的一套流程适用于黑盒测试场景。3.1 信息收集与功能点梳理在开始测试前不要急着上工具。先像普通用户一样把目标网站Web Application或者系统如ThinkPHP开发的后台完整地浏览和使用一遍。这一步的目标是绘制一张“攻击面地图”。枚举所有功能点注册、登录、修改个人资料邮箱、密码、手机号、发表内容文章、评论、管理操作删除用户、审核内容、调整权限、支付、地址管理、消息设置等。用思维导图工具记录下来。重点关注状态改变操作在所有功能点中标记出所有会导致服务器数据发生“增删改”的操作。这些是CSRF的潜在高危点。例如“修改邮箱”比“查看邮箱”危险得多。记录请求特征使用浏览器开发者工具F12切换到Network网络面板并勾选“Preserve log”保留日志。然后手动触发每一个你标记出的高危操作。观察请求方法是GET还是POSTPUT、DELETE等方法是否被使用观察请求参数除了业务参数如new_email, old_password有没有一个看起来是随机字符串的参数它的参数名通常是csrf_token,authenticity_token,_token等。这是防御CSRF的关键信号。观察认证方式请求头Headers里认证是依靠Cookie中的Session ID还是Authorization头Cookies是否设置了HttpOnly和Secure属性这虽然不能防CSRF但能增加攻击难度。实操心得很多现代框架如Laravel, Django, Spring Security默认会为表单注入CSRF Token。但开发者可能会因为“麻烦”或“觉得没必要”而在某些API接口上手动关闭它。所以不要看到登录表单有Token就以为万事大吉要测试每一个敏感端点。3.2 漏洞验证构造与触发PoC当你发现一个敏感操作比如修改密码的请求中没有CSRF Token之类的不可预测参数并且鉴权仅靠Cookie时就可以开始验证了。1. 验证GET型CSRF这是最简单的一种。如果修改密码的接口是GET /change_password?new_password123456。构造PoC直接创建一个HTML文件内容如下img srchttp://target.com/change_password?new_passwordhacked123 /触发让已登录目标网站的用户访问这个HTML页面。如果他的密码被修改漏洞存在。风险由于GET请求可能被浏览器预加载、被网络设备日志记录更容易意外触发。2. 验证POST型CSRF更常见的情况。假设修改邮箱的接口是POST /update_email参数为emailnewattacker.com。构造PoC创建一个自动提交表单的HTML文件。!DOCTYPE html html body form idcsrfForm actionhttp://target.com/update_email methodPOST input typehidden nameemail valueattackerevil.com / !-- 如果有其他必填参数也需要一并隐藏填入 -- input typehidden nameuser_id value123 / /form script // 页面加载后自动提交表单 document.getElementById(csrfForm).submit(); /script /body /html触发用户访问此页面表单会自动提交完成邮箱修改。3. 验证JSON型或复杂POST请求有些应用使用AJAX发送JSON数据。此时需要利用form的enctypetext/plain或通过构造Flash攻击已逐渐淘汰等方式但更通用的方法是如果该应用同时支持application/x-www-form-urlencoded格式则优先测试该格式。如果只支持JSON则需要检查CORS策略和是否有其他验证缺陷。避坑指南在本地验证时务必确保测试环境与目标网站域名不同例如用本地file协议或自己搭建的HTTP服务器以模拟真实的跨站场景。同时浏览器的第三方Cookie策略可能会影响测试结果需要根据实际情况调整浏览器设置。3.3 绕过常见防御机制的技巧现在的Web应用多少都有些防护直接裸奔的接口变少了。这时候就需要一些绕过技巧。1. Token在哪—— 寻找Token的生成与验证逻辑Token在表单中这是最常见的方式。检查HTML源码寻找隐藏的input字段。如果Token存在但未与用户会话绑定例如所有用户的Token都一样或者验证后未销毁可重复使用则依然存在漏洞。Token在Cookie中有些框架如Django早期版本会将Token放在Cookie里提交时再从Cookie中读取并验证。这需要检查服务器是否严格对比了Cookie中的Token和请求体或参数中的Token。如果服务器只检查了Cookie里的Token而请求中可以不提供或者对比逻辑有误则存在漏洞。Token在请求头中通过自定义Header如X-CSRF-Token传递。这通常需要配合JavaScriptAJAX使用。在纯HTML表单提交的场景下攻击者无法为跨域请求添加自定义头因此这种防护是有效的。但是如果网站同时存在任何XSS漏洞攻击者就可以利用XSS读取Token并构造请求实现“组合拳”攻击。2. 检查Referer/Origin头—— 验证逻辑可被绕过很多应用会检查HTTP请求头中的Referer或Origin字段判断请求来源是否合法。空Referer如果服务器在Referer为空时通过了检查例如使用if not referer or referer.startswith(‘https://target.com’)这种错误逻辑攻击者可以通过在HTTPS页面中发起HTTP请求或者使用meta name“referrer” content“no-referrer”标签使浏览器发送空Referer从而绕过检查。Origin头Origin头通常用于CORS场景且不能被meta标签控制。但如果服务器验证逻辑不严谨如仅检查域名部分不检查协议和端口或者存在域名解析、重定向方面的漏洞也可能被绕过。实战技巧在测试时用Burp Suite等工具抓包手动删除或修改Referer和Origin头观察服务器响应。如果删除后请求依然成功说明防护无效。3. 双重Cookie验证—— 警惕逻辑缺陷这是一种较弱的防御方式在请求参数或Body中也需要携带Cookie中的某个值如session_id。由于浏览器的同源策略攻击者无法通过CSRF页面读取目标站的Cookie因此他无法知道这个值。这看起来是安全的。但是如果网站存在任何子域可控、或者Cookie设置过于宽松如Set-Cookie: session_idxxx; Domain.example.com攻击者可能在其控制的子域上设置Cookie从而污染父域的Cookie实现攻击。4. 利用工具高效挖掘与利用CSRF手工测试虽然透彻但效率较低。在实际的漏洞挖掘尤其是SRC、EDUSRC项目或渗透测试中我们通常需要借助工具进行辅助和加速。4.1 被动扫描与主动探测Burp Suite, OWASP ZAP专业的安全测试人员离不开Burp Suite。它的“Scanner”和“CSRF PoC Generator”功能是挖掘CSRF的利器。配置代理与爬虫将浏览器代理设置为Burp开启代理拦截Proxy - Intercept is on。然后使用浏览器正常浏览目标网站的所有功能。Burp的“Target” - “Site map”会自动记录下所有的请求。启动被动扫描在Site map中右键点击你的目标主机或目录选择 “Actively scan this branch”。Burp会自动对已发现的请求进行漏洞扫描其中就包括CSRF检测。它主要通过分析请求参数判断是否存在明显的Token缺失。主动生成PoC对于任何一个你怀疑的请求比如修改密码的POST请求在Proxy历史记录或Repeater模块中右键点击该请求选择“Engagement tools” - “Generate CSRF PoC”。Burp会自动生成一个包含所有参数的HTML表单。你可以在这个基础上进行修改比如删除不必要的参数调整提交方式等。生成的PoC可以直接在浏览器中打开进行测试极大地提高了验证效率。注意事项自动化工具的扫描结果会有误报和漏报。它可能误将一些有Token但Token可预测或可重放的请求报为安全也可能漏掉一些需要特定上下文如多步操作的复杂CSRF。因此工具报告需要结合人工审计来确认。4.2 半自动化测试脚本编写对于需要批量测试大量接口或者测试逻辑复杂的多步CSRF例如先请求A页面获取Token再用这个Token去请求B接口编写简单的Python脚本会更高效。下面是一个使用requests库和BeautifulSoup库测试“无Token表单”的简化示例脚本思路import requests from bs4 import BeautifulSoup session requests.Session() # 1. 首先登录获取有效的会话Cookie login_data {username: test_user, password: test_pass} login_resp session.post(http://target.com/login, datalogin_data) # 2. 访问一个敏感功能页面如修改邮箱页 profile_page session.get(http://target.com/profile/edit) # 3. 解析页面查找表单 soup BeautifulSoup(profile_page.text, html.parser) forms soup.find_all(form) for form in forms: action form.get(action) method form.get(method, get).lower() inputs form.find_all(input) # 4. 检查表单中是否有名为 csrf_token, _token 等的隐藏字段 has_csrf_token False for inp in inputs: if inp.get(type) hidden and token in inp.get(name, ).lower(): has_csrf_token True break # 5. 如果没有找到CSRF Token则记录下这个表单的详细信息供后续手动验证 if not has_csrf_token and action: print(f[!] 潜在CSRF漏洞表单: {method.upper()} {action}) print(f 表单参数: {[inp.get(name) for inp in inputs if inp.get(name)]})这个脚本可以帮助你快速筛选出未受保护的表单然后你再针对这些表单进行深入的手工PoC构造和验证。4.3 针对特定框架的测试思路如热搜词中提到的ThinkPHP、IIS等针对特定框架或中间件CSRF的挖掘可能有其特殊性。ThinkPHP老版本的ThinkPHP如3.x内置的CSRF防护需要开发者手动开启。如果开发者在配置文件中未开启‘csrf_protection’ true或者在写表单时未使用{:token()}函数生成令牌那么整个应用可能处于无防护状态。测试时可以查看表单页面源码搜索token或__hash__等关键字。IIS/.NETASP.NET WebForms 使用ViewState作为状态管理机制其中包含一个ViewStateUserKey可用于防御CSRF但并非默认启用。ASP.NET MVC 则提供了AntiForgeryToken机制。测试时检查表单中是否存在__RequestVerificationToken这个隐藏字段。Spring Security默认情况下Spring Security为启用CSRF防护。但它可能为某些路径如登录接口、静态资源禁用防护。检查Spring Security的配置看是否存在csrf().disable()或对特定路径的permitAll()配置。了解目标的技术栈能让你更有针对性地进行测试事半功倍。5. 从原理到实战高级CSRF攻击场景剖析掌握了基础验证方法我们来看几个更复杂、更贴近真实网络环境的攻击场景。这些场景往往能绕过一些简单的防护危害也更大。5.1 基于JSON的CSRF攻击现代前端应用大量使用AJAX发送JSON数据。如果服务器端没有正确验证Content-Type或Origin攻击依然可能发生。攻击场景一个修改用户昵称的API只接受application/json格式。POST /api/user/update_nickname HTTP/1.1 Host: target.com Content-Type: application/json Cookie: sessionidabc123 {nickname: NewNick}绕过尝试攻击者构造一个带有enctypetext/plain的表单。当表单以此编码提交时浏览器会将数据以纯文本形式发送且Content-Type为text/plain。如果服务器端解析JSON的库不够健壮例如先尝试解析JSON失败后再按其他方式解析可能会意外地处理这个请求。form actionhttp://target.com/api/user/update_nickname methodPOST enctypetext/plain input name{nickname:Hacked,ignore: valuetest} typehidden /form scriptdocument.forms[0].submit();/script提交后请求体可能是{nickname:Hacked,ignore:test}。某些JSON解析器可能会忽略末尾的test”}从而成功解析出nickname: Hacked。核心要点防御此类攻击服务器端必须严格校验Content-Type头为application/json并且使用健壮的JSON解析器在解析失败时直接拒绝请求。5.2 组合漏洞攻击XSS CSRF这是威力巨大的组合拳。一个反射型XSS漏洞可能只能弹个窗但如果利用它来窃取CSRF Token就能发起高权限的CSRF攻击。攻击链攻击者发现目标站profile.php页面存在反射型XSS参数name未过滤直接输出。该站点的“修改密码”功能有CSRF Token防护。攻击者构造一个恶意链接http://target.com/profile.php?namescriptfetch(‘/change_password_page’).then(rr.text()).then(html{var tokenhtml.match(/csrf_token” value”(.*?)”/)[1]; fetch(‘/change_password’, {method:‘POST’, body:‘new_passhackedcsrf_token’token}); })/script管理员点击此链接后脚本会在管理员浏览器中执行先访问修改密码页面用正则表达式提取出页面中的CSRF Token然后用这个Token发起一个修改密码的合法请求。由于请求发自管理员浏览器且带有正确的Token攻击成功。这种攻击完全绕过了独立的CSRF防护将危害提升到了新的等级。它告诉我们安全是一个整体一处短板可能导致全线崩溃。5.3 针对内部网络或本地应用的CSRFCSRF不仅可以攻击公网应用在内部网络或浏览器访问的本地服务如路由器管理界面192.168.1.1或本地开发服务器localhost:3000上同样有效。场景公司内网有一个简陋的设备管理系统部署在http://10.0.0.5用于重启服务器。该页面无CSRF防护。攻击一个内部员工在办公电脑上登录了这个系统。他偶然点开了另一个同事分享的“搞笑图片”页面该页面托管在内网另一台服务器上。这个页面里隐藏了一个img src“http://10.0.0.5/reboot?serverdb01”标签。于是数据库服务器被意外重启。这种攻击在内部安全测试中尤其需要关注因为内网应用的安全意识往往更薄弱。6. 企业级防御方案设计与落地作为防御方我们该如何系统地构建CSRF防护体系这里提供一套从架构到代码的落地方案。6.1 同步令牌模式最可靠的方案这是目前最主流、最有效的防御方案被各大Web框架广泛采用。核心流程生成令牌当用户会话建立时服务器生成一个高强度随机数Token将其存储在服务器端如Session中同时发送给客户端。客户端携带对于需要防护的请求通常是所有非幂等的POST/PUT/DELETE请求客户端必须将这个Token作为参数表单隐藏域或请求头如X-CSRF-Token一并提交。对于传统表单Token放在隐藏域对于AJAX请求可以从Cookie或Meta标签读取然后放入请求头。服务器验证服务器收到请求后比较客户端提交的Token和服务器Session中存储的Token是否一致且未过期。一致则通过否则拒绝。关键实现细节与避坑点Token的绑定Token必须与当前用户会话绑定。全局统一的Token是无效的。Token的随机性与强度使用安全的随机数生成器如操作系统的CSPRNG确保Token不可预测。每会话或每表单可以采用“每会话一个Token”简单但有一定重放风险或“每个表单一个Token”更安全但实现复杂。对于安全性要求极高的操作如转账建议使用一次性的Token。AJAX请求的处理对于单页面应用SPA可以将Token放在页面的meta标签中或由登录接口返回然后由JavaScript在每次请求时将其添加到请求头如X-CSRF-Token。切记不能依赖Cookie自动携带因为攻击者无法自定义请求头。敏感Cookie属性为Session Cookie设置Secure仅HTTPS传输和HttpOnly禁止JavaScript读取属性。这虽不能防CSRF但能防止Token通过XSS被窃取是重要的辅助防御措施。6.2 双重Cookie验证一种补充思路如前所述将Token放在Cookie中请求时再从Cookie中读取并验证。这种方案在正确实现下是有效的但需要注意Cookie作用域必须确保CSRF Token的Cookie作用域严格避免被子域污染。Token存储Token仍需在服务器端有对应记录用于验证不能仅做字符串比对。适用场景更适合API接口方便前端JavaScript统一从Cookie读取并设置到请求头中。6.3 同源检测与自定义头简单有效检查Origin/Referer头这是一个低成本且有效的辅助手段。服务器可以检查请求头中的Origin优先或Referer字段判断请求是否来源于可信的域名。优点实现简单对用户透明。缺点存在被绕过的风险如前文所述且在某些合法场景下如从HTTPS跳转到HTTP或用户隐私设置这些头可能为空或被移除需要做好兼容处理例如对于空Referer的请求可以要求额外的验证。建议不要将其作为唯一的防御手段而是作为同步令牌模式的一道额外防线。使用自定义请求头让前端在所有“状态改变”请求的Header中添加一个自定义字段如X-Requested-With: XMLHttpRequest。由于浏览器同源策略限制攻击者无法通过CSRF跨域添加自定义头。优点对于纯AJAX应用非常有效且简单。缺点对于传统表单提交无效如果网站支持CORS并配置了允许自定义头则此方法失效。6.4 框架内置防护的最佳实践绝大多数现代Web开发框架都内置了CSRF防护模块。最佳实践就是除非有极其特殊的理由否则不要关闭它。Django使用{% csrf_token %}模板标签。确保中间件django.middleware.csrf.CsrfViewMiddleware已启用。对于AJAX请求需要从Cookie获取Token并设置X-CSRFTOKEN头。Spring Security (Java)默认启用。确保配置中不要随意调用csrf().disable()。前端提交表单时Thymeleaf等模板引擎会自动添加_csrf令牌。Laravel (PHP)为每个活跃用户会话生成CSRF令牌并通过csrfBlade指令注入表单。验证由VerifyCsrfToken中间件自动完成。Express.js csurf middleware使用csurf中间件。注意在前后端分离项目中需要正确配置Token的获取和提交方式。开发中的常见错误为API接口全局禁用CSRF认为API只用Token认证如JWT就安全了。但若JWT Token存储在localStorage中仍需防范通过XSS发起的CSRF式攻击虽然不叫传统CSRF但逻辑类似。对于API建议使用同步令牌或严格校验Origin头。Token泄露通过XSS漏洞、不安全的日志、错误的API响应体泄露了CSRF Token。验证逻辑错误例如对比Token时未考虑大小写或空格导致验证绕过。7. 漏洞挖掘实战中的疑难问题排查在实际测试中你可能会遇到一些“奇怪”的情况让你不确定漏洞是否存在。这里记录几个常见的疑难场景和排查思路。7.1 状态码成功但业务未生效你用PoC发起了请求服务器返回了200 OK甚至返回了成功的JSON消息{“code”: 200, “msg”: “success”}但回到网站查看发现数据并没有被修改。可能原因1二次确认很多关键操作如删除、支付有前端二次确认弹窗。你的PoC绕过了前端JavaScript直接请求了后端接口但后端接口可能设计为只接收来自前端特定流程的请求例如需要先请求一个get_confirm_token的接口。你需要分析完整的前端交互流程。可能原因2操作日志与审计后端确实执行了操作但触发了风控或审计规则操作被自动回滚或标记为待审核。检查是否有相关的通知或日志功能。排查方法使用Burp的Repeater模块完全模拟浏览器的正常操作流程从第一步开始按顺序发送请求观察每个请求的响应和后续请求的参数变化。7.2 存在Token但似乎可重用你发现请求中有Token但测试发现同一个Token似乎可以多次使用。测试方法用同一个Token更换关键参数如新的邮箱地址重复发送请求。如果两次都成功说明Token未与操作内容绑定存在重放攻击风险。深入测试尝试将用户A的Token用于用户B的会话需要先窃取Token。如果也成功说明Token未与用户会话严格绑定这是严重漏洞。结论一个健壮的Token应该是一次性的使用后即失效或与请求参数进行哈希绑定的例如Token HMAC(secret_key, session_id action_param)确保Token只能用于特定的操作。7.3 依赖Referer验证的边界情况目标站点检查Referer头你的空Referer攻击失败了。但你不甘心觉得可能有其他绕过方式。测试子域与协议如果目标站点是https://app.target.com尝试构造来源为http://app.target.com协议不同、https://dev.target.com子域不同、https://target.com根域的请求看服务器是否放行。有些正则匹配写得不严谨可能只匹配了target.com。利用URL解析差异尝试在Referer中注入路径、参数或片段标识符如https://target.com.evil.com/或https://target.comevil.com/。古老的浏览器或服务器解析库可能对此解析有误。终极建议即使找到了绕过方法在漏洞报告中也应明确指出“依赖Referer验证是不安全的”并推荐采用同步令牌方案。挖掘CSRF漏洞尤其是逻辑复杂的漏洞需要像侦探一样思考耐心地追踪每一个请求和响应理解应用背后的完整状态流转。这个过程本身就是对Web应用安全逻辑的深刻训练。