XSS 和 CSRF 的本质区别及开发防御全解析

  在前端Web安全中，XSS和CSRF是最常见的两种跨站攻击，很多人容易混淆二者。其实只要抓住核心逻辑，就能快速区分，先记住最关键的核心结论：

核心结论1：XSS是「跨站脚本注入」，利用「用户对目标网站的信任」，让目标网站执行攻击者的恶意脚本；CSRF是「跨站请求伪造」，利用「目标网站对用户浏览器的信任」，冒充用户发起合法的跨站请求。

核心结论2：简单来说，XSS是让网站“帮攻击者做事”，核心是「脚本执行」；CSRF是让网站“把攻击者的事当用户的事”，核心是「请求伪造」。更通俗的比喻：XSS是偷了你的钥匙开门做事，CSRF是你拿着钥匙站在门口，骗子骗你抬手开了门。二者的攻击逻辑、利用的信任关系、行为特征完全不同，这是最本质的区别。下面从核心对比、通俗解读、类型拆解、防御策略、开发速查五个维度，结合具体例子，彻底讲透二者的区别与实操防护方法。

一、核心维度对比（最直观区分，适配查阅）

为了方便快速区分，整理了10个核心维度的对比表，覆盖攻击全流程，不管是面试还是实际开发，都能直接对照判断：

二、通俗比喻（秒懂攻击逻辑，避开晦涩术语）

用生活化的例子拆解两种攻击的核心逻辑，一看就懂，再也不混淆：

XSS：鸠占鹊巢，借刀杀人

你（用户）信任一家餐厅（目标网站），餐厅的厨师（网站程序）有个漏洞——不会检查食材里是否有异物。攻击者趁机偷偷往餐厅的菜品（用户输入的内容，比如评论、留言）里加了泻药（恶意脚本），你不知情地吃了这道菜（浏览包含恶意脚本的页面，执行网站返回的代码），最终中招（个人信息被偷、账号会话被劫持）。关键总结：问题出在餐厅“做的菜里本身有问题”，也就是目标网站返回了包含恶意脚本的内容，核心是“脚本被执行”。

CSRF：冒名顶替，借手办事

你（用户）在银行（目标网站）办了银行卡，还登录了网上银行（浏览器保存了你的登录会话，有有效身份凭证）。银行有个漏洞——只认你的银行卡（浏览器里的登录Cookie），不认操作是谁发起的。攻击者知道你有银行卡，也知道银行的付款规则（网站的请求格式），于是拉你到他的假店铺（恶意页面），让你无意间按了付款按钮（触发跨站请求）。银行看到请求里带着你的银行卡（合法Cookie），就以为是你主动付款，执行了转账操作。关键总结：问题出在银行“只认凭证，不认操作来源”，也就是目标网站误把攻击者构造的请求当成了用户的主动操作，核心是“请求被伪造”。

三、各自的核心类型（补充特征，强化本质认知）

了解二者的常见类型，能进一步分清“脚本执行”（XSS）和“请求伪造”（CSRF）的核心差异，仅列核心类型，不展开复杂细节，贴合实际开发场景：

XSS：按脚本存储/执行方式分类（核心是脚本能被执行）

1. 存储型XSS：恶意脚本被永久存储在目标网站（比如数据库、论坛评论区、留言板），所有访问该页面的用户都会触发，危害最大。举例：攻击者在某论坛评论区注入恶意脚本，脚本被存到论坛服务器，后续所有浏览该评论的用户，都会执行这个脚本，导致账号信息被偷。
2. 反射型XSS：恶意脚本拼接在URL中，目标网站直接反射返回给用户，需要用户点击恶意链接才会触发，危害中等。举例：攻击者构造含恶意脚本的URL（如http://目标网站/search?key=<script>恶意代码</script>），诱导用户点击，用户点击后，网站会将URL中的脚本返回并执行。
3. DOM型XSS：无需服务器参与，恶意脚本通过篡改页面DOM结构执行，漏洞出在前端JS代码。举例：某网站前端JS代码直接使用location.href中的参数渲染页面，攻击者构造含恶意脚本的URL，用户点击后，前端JS读取URL参数并执行，篡改页面内容或窃取信息。

CSRF：按请求方式分类（核心是请求能被伪造）

1. GET型CSRF：通过URL构造请求，利用浏览器自动发送GET请求的特性触发，最易构造。举例：攻击者在恶意页面中插入<img src="http://银行网站/transfer?to=攻击者账号&money=1000">，用户登录网银后访问该恶意页面，浏览器会自动请求这个URL，银行误以为是用户主动转账。
2. POST型CSRF：通过恶意页面的表单构造POST请求，需要通过JS自动提交表单触发，稍复杂但危害相同。举例：攻击者在恶意页面中写一个隐藏表单，表单action指向银行转账接口，method为POST，再用JS自动提交表单，用户登录网银后访问该页面，就会自动提交转账请求。

四、关键易混淆点澄清（避开常见误区，精准区分）

1. “CSRF是XSS的子集？” 不是！二者无包含关系，只是都属于跨站攻击，但攻击逻辑完全独立。防御XSS的手段（如输入过滤）无法防御CSRF，反之亦然（如CSRF Token无法防御XSS）。比如，给Cookie加HttpOnly属性能防XSS窃取Cookie，但无法防CSRF伪造请求。
2. “CSRF能窃取用户Cookie吗？” 不能！CSRF的本质是利用浏览器自动携带Cookie，但攻击者无法读取Cookie内容（浏览器同源策略限制），只能让目标网站识别Cookie；而XSS（未加HttpOnly时）能直接读取Cookie，这是二者数据能力的核心区别。
3. “有XSS漏洞的网站，一定有CSRF漏洞？” 不一定！XSS是输入输出漏洞，CSRF是请求验证漏洞，二者成因不同。一个网站可能有XSS漏洞（过滤不严），但配置了CSRF Token，就不会有CSRF漏洞；反之，一个网站无XSS漏洞，但未做跨站请求验证，就可能有CSRF漏洞。
4. “二者都依赖用户登录状态，原因一样吗？” 不一样！XSS依赖登录状态，是因为只有用户登录后，目标网站才会返回包含用户敏感信息的页面，恶意脚本执行后才能窃取有效的登录凭证（未登录的凭证无意义）；CSRF依赖登录状态，是因为只有用户登录后，浏览器才会保存目标站点的登录Cookie，跨域请求时才能自动携带，让目标站点验证通过（未登录则无Cookie可利用）。
5. “二者关联是什么？” XSS可以绕过所有CSRF防御！因为XSS的恶意脚本是在目标域执行的，属于同源操作，能直接获取页面中的CSRF Token、Cookie等所有信息，进而构造带Token的合法请求，让CSRF防御失效。结论：XSS是比CSRF更根本的漏洞，若站点存在XSS，所有CSRF防御都无意义，优先修复XSS。

五、核心防御策略（针对性防护，反推本质差异）

二者的防御方案完全围绕自身核心漏洞设计，防御手段的差异也能印证本质区别。核心原则：XSS堵死“脚本注入”入口，CSRF验证“请求真实性”；优先修复XSS，前后端协同防御（单一端防御均有漏洞）。

XSS 防御：核心是「阻止恶意脚本的注入和执行」

围绕“输入过滤、输出转义、限制脚本执行”展开，核心是让攻击者注入的脚本无法被浏览器执行，关键手段如下：

1. 输入过滤：对用户所有输入（表单、URL、评论、留言等）做严格过滤，剔除<script>、onclick、eval、javascript:等脚本相关的关键字和属性。比如，用户提交评论时，过滤掉包含“javascript:”的内容。
2. 输出转义：对网站向页面输出的内容做HTML转义，把<转成&lt;、>转成>、"转成&quot;，让恶意脚本变成纯文本，无法被浏览器解析执行。比如，用户输入“<script>偷信息</script>”，转义后会显示为普通文本，不会执行。
3. 使用CSP（内容安全策略）：通过HTTP响应头或meta标签配置CSP，限制页面加载的资源来源，禁止内联JS执行、禁止eval，从浏览器层面阻止脚本执行。比如，配置CSP仅允许加载本站和可信CDN的脚本。
4. HttpOnly Cookie：给敏感Cookie（如登录会话Cookie、Token）加HttpOnly属性，禁止JS读取，即使XSS注入成功，也无法窃取Cookie，起到兜底作用。同时搭配Secure属性（仅HTTPS传输），防止中间人劫持。
5. 禁用高危API：避免使用innerHTML、eval、document.write等高危API，优先用textContent渲染文本。比如，用textContent显示用户昵称，代替innerHTML，防止注入脚本。

CSRF 防御：核心是「验证请求的真实性，杜绝伪造」

围绕“验证请求合法性、限制Cookie跨域携带”展开，核心是让目标站点能识别出“该请求不是用户主动发起的”，关键手段如下：

1. CSRF Token 验证（最核心、最有效）：目标网站为每个用户会话生成唯一的随机Token（至少32位，不可预测），与用户会话绑定，嵌入页面表单或请求头；服务器接收到非GET请求时，校验Token的有效性，不一致直接拒绝请求。攻击者无法获取该Token，无法构造合法请求。
2. SameSite Cookie：给会话Cookie配置SameSite=Strict/Lax属性，限制Cookie仅在同站请求中携带，跨站请求会自动屏蔽Cookie，从根源上阻止跨站请求携带身份凭证。普通站点选Lax（兼顾体验），金融、支付站点选Strict（最高安全）。
3. Referer/Origin 校验：服务器校验请求的Referer（请求来源页面）或Origin（请求来源域名），仅允许同站或可信域名的请求通过，拒绝陌生域名的跨站请求。注意兼容移动端和隐私模式（部分场景Referer为空）。
4. 操作加额外校验：对高危操作（转账、改密码、删账号、绑定手机）增加二次验证（短信验证码、密码、指纹），即使请求被伪造，也无法通过最终校验。
5. 规范请求方式：严格遵循REST规范，GET请求仅做数据查询，所有状态变更操作（转账、改密码等）强制使用POST/PUT/DELETE，增加攻击成本（GET请求易构造，POST需构造表单）。
6. 跨域（CORS）配置：后端CORS配置仅允许可信白名单域名，绝对禁止使用*（允许所有域名跨域，易被CSRF利用），同时限制跨域请求方法和请求头。

六、开发防御速查表（贴入项目规范，实操可用）

结合实际开发场景，提炼前端、后端、高危场景自查的核心要点，供开发、提测、上线前快速查阅，规避高频漏洞，可直接贴入项目开发规范。

（一）前端开发防御细则（核心：防注入、传验证、禁高危）

• 输入处理：所有用户输入先做基础过滤（后端最终校验，前端仅提升体验），剔除恶意标签和属性。
• 内容渲染：纯文本用textContent渲染，严禁用innerHTML；富文本用成熟插件（如TinyMCE），仅保留白名单标签。
• URL渲染：校验URL协议为http/https，禁止javascript:/data:协议，不直接拼接用户输入的URL。
• API请求：非GET请求必须在请求头携带CSRF Token，不拼在URL/参数中；GET请求仅做查询，禁止用于状态变更。
• Cookie配置：不通过JS存储敏感登录态，配合后端设置HttpOnly、Secure、SameSite属性。
• 高危API：禁用eval、document.write等，确需使用innerHTML的，先做后端全量转义+前端过滤。
• CSP配置：可通过meta标签快速配置（推荐后端通过HTTP头配置），限制脚本来源，禁止内联脚本/eval。

（二）后端服务防御细则（核心：终校验、强验证、控传输，后端是最后防线）

• XSS防御：所有用户输入做全局过滤（推荐工具：Java HuTool XssFilter、Python bleach、Node.js xss）；输出时强制HTML转义（富文本仅过滤标签，不转义）。
• CSRF防御：CSRF Token需满足唯一性、随机性、强绑定（与会话绑定），一次有效/短期有效，非GET请求必须校验；辅助做Referer/Origin校验。
• Cookie配置：敏感Cookie必须设置HttpOnly、Secure、SameSite、Path=/、Max-Age属性，生产环境仅用HTTPS传输。
• 跨域配置：CORS仅允许可信白名单域名，禁止*，限制跨域请求方法和请求头。
• 高危操作：转账、改密码等高危操作，除Token校验外，强制加二次验证，同时记录操作日志便于溯源。

（三）高危场景自查清单（提测/上线前必查）

1. XSS重灾区（内容输入/展示）

• 评论区、留言板：后端做输入过滤+输出转义，前端用textContent渲染；
• 搜索框：拼接URL时校验协议，禁止javascript:协议；
• 富文本编辑器：仅保留白名单标签，剔除事件属性；
• 动态渲染：未用innerHTML渲染用户输入，预编译模板不拼接用户输入。

2. CSRF重灾区（跨站/跨域请求）

• 非GET请求：均携带CSRF Token，且Token有效；
• GET请求：未用于任何状态变更操作；
• 跨域配置：为白名单域名，未用*，限制请求方法和请求头；
• 未通过<img>/<script>标签构造跨域状态变更请求。

3. 双漏洞叠加区（登录态/敏感信息）

• 登录态Cookie：已设置HttpOnly、Secure、SameSite属性，未通过JS存储；
• 高危操作：加了二次验证，非仅靠Cookie/Token校验；
• 敏感信息：未在URL中拼接token、手机号等敏感信息；
• 生产环境：所有接口均使用HTTPS，未混用HTTP。

（四）开发高频疑问速答

1. 前端已过滤，后端还要过滤吗？→ 必须要！前端过滤可被抓包绕过，后端是最后防线。
2. SameSite=Lax/Strict怎么选？→ 普通站点选Lax（兼容体验），金融/支付选Strict（最高安全）。
3. CSRF Token存在哪？→ 前端存DOM/本地存储，禁止存Cookie；后端存Session/Redis。
4. CSP和输入过滤哪个重要？→ 互补！输入过滤是源头防御，CSP是兜底防御，建议同时开启。
5. 如何测试防御有效？→ XSS测<script>alert(1)</script>是否被转义；CSRF测跨域POST请求是否被Token拒绝。

七、总结（3个核心点，永远不混淆）

1. 信任关系：XSS利用「用户信网站」，CSRF利用「网站信用户浏览器」；
2. 核心行为：XSS是「注入并执行恶意脚本」（偷凭证、冒充用户做事），CSRF是「构造并发送伪造请求」（借登录态、骗用户做事）；
3. 数据能力：XSS能读+写用户/网站数据，CSRF只能写（发请求），无法读任何数据。

实际开发中，二者的防御需要同时做，因为站点可能同时存在两种漏洞，且攻击者可能将二者结合（用XSS注入脚本，构造CSRF请求），危害翻倍。优先修复XSS漏洞，再完善CSRF防御，前后端协同，才能真正抵御这两种常见的跨站攻击。

版权所属：SO JSON在线解析

原文地址：https://www.sojson.com/blog/581.html

转载时必须以链接形式注明原始出处及本声明。

如果本文对你有帮助，那么请你赞助我，让我更有激情的写下去，帮助更多的人。

￥我需要走的更远，点击我 赞助。 如果还有疑问，点击我加群，为你提供最好的解答。