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

原创

小H
小H

401 Unauthorized

2026年7月28日 17:48
安徽

在小说阅读器读本章

去阅读

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

看代码时，重点查六处：写回页面的地方有没有转义；用户内容进库前过没过滤；前端有没有用 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 专项测试？

最后说两句

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

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