文章总结： 本文详细解析了XSS和CSRF两种Web漏洞的原理、攻击方式及防御措施。XSS通过在页面注入脚本偷取用户凭证，CSRF则借用已登录状态发起恶意请求。文章结合银行系统场景，提供了检测方法、防御组合拳（输入过滤、输出转义、Token、二次验证等）以及开发、测试、运维人员的检查清单，强调关键操作需加防伪标识。 综合评分： 85 文章分类： 漏洞分析,安全建设,安全意识,实战经验

金融行业信息安全培训课程（四）：XSS 与 CSRF 详解

原创

小H 小H

401 Unauthorized

2026年7月28日 17:48 安徽

在小说阅读器读本章

去阅读

去年我碰到一个真事。一个客户下午三点收到短信：账户转出两万块。他当时就懵了——一下午没碰手机，密码没泄露，验证码也没收到，钱就这么没了。

后来查出来，不是他的问题。是他上午在银行 App 的活动页留了条言，那条”留言”里塞了段代码。代码在他手机上悄悄跑起来，把他登录后的身份凭证发给了别人。等他再打开 App，坏人已经用他的身份进来了。

这件事把两种最常见的 Web 漏洞凑齐了：XSS 和 CSRF。它们都不用偷你的密码，专挑”你已经登录”的时候下手。今天这篇，我就把这俩讲透，顺便告诉你怎么防。

先记住一句话：XSS 是”偷走你的门禁卡”，CSRF 是”拿着你的门禁卡帮你办事”。一个偷，一个借。别的漏洞是坏人自己闯进来，这俩是借你的身份进来。所以下文你只要盯住一件事——你的”门禁卡”（也就是登录后的会话凭证）是怎么被偷、又被怎么被借的。

XSS：在你的浏览器里安了后门

很多人分不清 XSS 和 CSRF，因为名字像。先说 XSS。

银行的页面上有搜索框、留言区、昵称展示位。你输入”张三”，页面显示”张三”，正常。但如果你输入的是一段脚本，而系统傻乎乎地原样塞回页面，那么每个看到这段内容的人，浏览器都会把这段代码当成真指令去执行。等于在银行的页面里被人安了个后门。

说白了就一句话：**你输入的内容，被系统当成了可执行的代码，又原样显示回页面上了。**看代码最直观——

危险写法：用户输入直接拼进页面

// 后端把用户昵称原样返回，前端直接塞进页面
res.send("<div>欢迎，" + userName + "</div>");
// 如果 userName = <script>偷走登录信息()</script>
// 浏览器会真的去执行这段脚本！

安全写法：显示前先做”转义”

// 返回前先把特殊符号变成纯文本
userName = 转义处理(userName);
// < 变成 &lt;，脚本变成普通文字，跑不起来
res.send("<div>欢迎，" + userName + "</div>");

核心就一句：显示给用户看的内容，有没有被当成”纯文字”处理？没转义 = 后门；转义了 = 安全展示。

XSS 分三种，混进页面的路子不一样：

存储型：脚本写进数据库，谁打开页面谁中招，最阴。银行里的活动留言、用户昵称、富文本公告都是它的窝。 反射型：脚本藏在网址里，骗你点一下才触发，搜索结果页、错误提示页常见。 DOM 型：脚本不过后端，前端自己处理输入时出了岔子，改个网址参数就注入了。

攻击者连密码都不用猜，一个留言 + 一段脚本 = 把客户的登录状态”复制”走了。这就是为什么 XSS 在银行里这么要命。

CSRF：你没点转账，钱却转走了

再说 CSRF。它不往页面塞代码，而是做一个陷阱网页。

你登录着手机银行没退出，随手点开一个论坛链接。这个网页趁你还没关银行页面，用你浏览器里那条合法登录信息，悄悄向银行发了个”转账”请求。银行一校验，以为是本人操作，转账就真的发生了。

关键点在这里：坏人从头到尾不知道你的密码，也拿不到你的登录信息，他只是”借用”了你已登录的状态。所以 CSRF 特别难防——请求看起来完全合法。

危险写法：请求无 Token、无来源校验

// 银行只靠登录信息识别用户，请求可被伪造
POST /api/transfer
登录信息: sessionid=合法值
{ "收款人":"攻击者", "金额":10000 }
// 攻击者照着构造同样的请求就能冒用

安全写法：加随机 Token + 二次验证

// 每个请求带一次性 Token，关键操作还要密码
POST /api/transfer
登录信息: sessionid=合法值
{ "收款人":"...", "金额":...,
  "csrfToken":"随机不可猜", "支付密码":"..." }
// 缺 Token / 密码 → 直接拒绝

银行里 CSRF 最爱钻的，是那些”改数据”的操作：转账、改绑定手机号、改登录密码、解绑、加收款人。这些接口如果只认登录信息、不认防伪标识，坏人照着构造一个请求就能冒用。

在银行系统里，哪些地方最容易中招

我把高发点按业务模块和”长相”两条线给你列一下，你们对号入座。

| 业务模块 | 漏洞类型 | 容易出问题的地方 | 入口/参数 | | — | — | — | — | | 用户认证与账户 | XSS | 个人资料昵称、留言、富文本简介 | 昵称、签名、备注 | | 用户认证与账户 | CSRF | 修改绑定手机、改密码、解绑 | 资料修改接口 | | 支付转账与清算 | CSRF | 转账、添加收款人、发起提现 | 转账/提现接口 | | 积分权益与营销 | XSS | 活动留言区、评论、抽奖弹窗 | 留言、评论内容 | | 积分权益与营销 | CSRF | 兑换、领取奖励、抽奖参与 | 兑换/领取接口 | | 内部管理与后台 | XSS | 公告、工单、客户备注 | 富文本、备注字段 | | 内部管理与后台 | CSRF | 配置修改、审批操作 | 后台操作接口 | | 第三方开放接口 | CSRF | 回调类接口被伪造调用 | 回调网址 |

| 长什么样 | 风险 | 说明 | | — | — | — | | 任何”你输入的内容会显示回页面”的地方 | 高危 | 搜索框、留言、昵称、备注——XSS 温床 | | 富文本 / 能输入 HTML 的区域 | 高危 | 没做标签白名单过滤就危险 | | 关键操作只校验登录信息、没 Token | 高危 | CSRF 温床：转账、改密、改手机 | | 用网址 GET 请求做”改数据”的操作 | 中 | GET 容易被图片/链接自动触发 | | 登录信息没设 HttpOnly / SameSite | 高危 | XSS 偷凭证、CSRF 借凭证都更轻松 |

怎么判断你的系统有没有这俩漏洞

不用看代码也能试个大概：

| 测什么 | 怎么试 | 安全表现 | 中招特征 | | — | — | — | — | | XSS：插脚本 | 在输入框填 <script>alert(1)</script> | 被转义成纯文字，不弹窗 | 弹出弹窗 = 有 XSS | | XSS：存留言 | 发带脚本的留言，换账号看 | 他人看到的是纯文字 | 他人中招 = 存储型 XSS | | XSS：改网址参数 | 把页面参数改成脚本 | 参数被转义 | 脚本执行 = DOM 型 XSS | | CSRF：造请求 | 退出登录后，用旧请求重发 | 被 Token/登录态拒绝 | 仍执行 = 有 CSRF | | CSRF：去掉 Token | 去掉请求里的 csrfToken 再发 | 返回拒绝 | 照常执行 = 缺防护 | | 登录信息检查 | 看 Set-Cookie 有无 HttpOnly/SameSite | 两项都设 | 缺 = 风险放大 |

看代码时，重点查六处：写回页面的地方有没有转义；用户内容进库前过没过滤；前端有没有用 innerHTML 渲染参数；转账改密接口有没有 Token 加二次验证；Token 是不是随机、一次性、服务端校验；Set-Cookie 的 HttpOnly 和 SameSite 设了没有。

防御：两套组合拳

XSS 防的是”显示”和”凭证”。四件事：输入过滤（特殊字符过滤，富文本用白名单）；输出转义（所有显示内容转义，< 变 <）；HttpOnly（登录凭证设 HttpOnly，脚本读不到）；CSP（限制脚本来源，注入也跑不起来）。

CSRF 防的是”请求”。四件事：二次验证（转账、改密加支付密码/验证码）；CSRF Token（每个请求带随机 Token，服务端校验）；SameSite（登录凭证设 SameSite，跨站不自动带）；来源校验（Referer/Origin 不是本域就拒）。

**两套拳的口诀：**XSS 那套，关键在”显示要转义、凭证要上锁”；CSRF 那套，关键在”每个关键请求都带防伪 Token、再验一次身份”。把这四句话落到代码里，这俩漏洞基本就进不来。

三个人，各自查什么

开发

• 所有显示给用户的输入内容，都做了转义吗？
• 富文本输入用的是白名单过滤，而不是黑名单吗？
• 前端有没有用 innerHTML 直接拼接用户输入？
• 所有”改数据”的关键操作，都要求 Token + 二次验证吗？
• Token 是随机、不可猜、服务端校验、一次性的吗？
• 登录信息设置了 HttpOnly 和 SameSite 吗？
• 关键响应有没有配置 CSP 策略？
• 接口有没有校验请求来源 Referer / Origin？

测试

• 有没有对每个输入框都试了 <script>alert(1)</script> 之类的内容？
• 有没有测存储型 XSS（换账号看别人是否中招）？
• 有没有测 DOM 型 XSS（改网址参数）？
• 有没有去掉 Token 重发关键请求，验证被拒？
• 有没有测退出登录后旧请求能否重放？
• 有没有检查 Set-Cookie 的 HttpOnly / SameSite 配置？
• 有没有验证转账等操作的二次验证不可绕过？

运维 / 安全

• 有没有统一在网关 / 过滤器层开启 XSS 过滤与输出编码？
• 有没有对全站登录信息统一强制 HttpOnly + SameSite？
• 有没有配置 CSP 策略并定期审计？
• 有没有对关键操作接口启用 Token 强制校验？
• 有没有监控异常请求来源（大量跨域 Referer）？
• 有没有定期开展 XSS / CSRF 专项测试？

最后说两句

| 漏洞 | 核心要点 | 一句话防御 | | — | — | — | | XSS | 在页面里种脚本，偷凭证、劫持操作 | 输入过滤 + 输出转义 + HttpOnly + CSP | | CSRF | 借你已登录的身份，自动发请求 | Token + 二次验证 + SameSite + 来源校验 |

做业务的、做产品的，记住一点就行：凡是”用户输入会显示出来”或”点一下就能改数据”的地方，都是这俩漏洞的窝。提需求的时候顺嘴问一句”这块转义了吗、带 Token 了吗”，比事后救火强。

本文是《金融行业信息安全培训》系列第四课，与课程框架（PDF）模块四及配套速查表配合使用。适合银行科技部门开发、产品、测试及业务人员阅读。

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：401 Unauthorized 小H 小H《金融行业信息安全培训课程（四）：XSS 与 CSRF 详解》