文章目录一、先建立正确心智XSS 伤的是谁二、三类 XSS一张表建立直觉三、反射型 XSS实战演示思路1. 它长什么样2. 演示路径请在靶场做3. 位置比 payload 重要4. 反射型的修复直觉四、存储型 XSS实战演示思路1. 它为什么更凶2. 演示路径靶场3. 富文本存储型的重灾区4. 存储型修复直觉五、DOM 型 XSS实战演示思路1. 为什么说“服务端可能是清白的”2. 演示路径自建一小页即可3. 现代前端里的变体4. DOM 型修复直觉六、串起来的一条“实战演示”主线适合内训七、测试方法论比收藏 payload 重要1. 找入口2. 探针优先3. 看上下文再构造4. 双浏览器 / 双账号5. 自动化辅助人工收口八、防御全解分层才像会打仗1. 输出编码第一原则2. 输入校验辅助3. 富文本清理4. CookieHttpOnly、Secure、SameSite5. CSPContent Security Policy6. 框架与危险 API 纪律7. 安全头与其它九、和 OWASP Top 10 的关系十、常见误区十一、收尾XSSCross-Site Scripting跨站脚本听起来像某种高深的“跨站黑科技”真落到业务里多半是一句很土的话页面把用户可控的内容当成了脚本执行了。可能是搜索框把关键字原样写回 HTML可能是评论区存了一段script谁打开谁中招也可能是前端用innerHTML拼了个 URL 参数压根没经过服务端。三种常见面孔——反射型、存储型、DOM 型——本质同一类病不可信数据进了浏览器的“代码语境”。另外说句实在话现在 HttpOnly、框架自动转义、CSP 越来越普及有人宣布 XSS 已死。然后每年还能在重要系统里看见评论区、富文本、运营配置后台、老 jQuery 页面中招。死的是“无脑scriptalert(1)”不是整个问题域。一、先建立正确心智XSS 伤的是谁SQL 注入主要伤服务器和数据XSS 主要伤正在用浏览器的人。脚本跑在受害者浏览器里能做的事情取决于页面所处的源origin和页面能力常见包括偷当前站可用的数据若 Cookie 非 HttpOnly可能读到会话 CookieHttpOnly 则改走其它路以受害者身份发请求改邮箱、转账、发帖也就是挂着用户会话的 CSRF 式操作钓鱼在真域名下画假登录框配合其它洞做跳板。所以评估 XSS 时别停在alert(1)。alert只是证明“我能执行脚本”。真正的问题是在谁的浏览器里、以谁的身份、能碰到什么功能。二、三类 XSS一张表建立直觉类型脚本从哪来典型触发测试时盯什么反射型当前请求参数被立刻写进页面点开带毒链接URL/表单参数是否进 HTML存储型先存进服务器以后每次打开都带出来看帖、看消息、看后台存储内容再展示的路径DOM 型主要在前端 JS 里改 DOM改 hash/参数即可innerHTML、eval、危险 sink一句话区分反射请求里来响应里走多半不进库存储进库或进能持久的地方别人也会中DOM服务端可能完全干净锅在前端。三、反射型 XSS实战演示思路1. 它长什么样最典型搜索页。你搜hello页面显示“您搜索的是hello”。若后端或模板把关键字不经编码塞进 HTML把关键字换成可执行的 HTML/JS浏览器就会执行。受害者通常需要打开攻击者构造好的链接或被钓鱼点开。所以反射型常和社工、短链、广告投放一起出现。2. 演示路径请在靶场做环境DVWA 反射型关卡或自己写一个“回显参数”的页面。步骤大致是找一个参数它的值会出现在响应 HTML 里先提交一个无害标记例如xss_probe_12345确认它原样出现在哪里标题、属性、正文、脚本块里位置不同手法不同根据位置尝试能否形成可执行上下文——例如是否进了标签体、是否进了属性、是否进了 JavaScript 字符串用最简单的执行证明教学上常用弹窗证明脚本执行再讨论若 Cookie 无 HttpOnly 会怎样演示到“能读到什么”为止别对外打真实账号。3. 位置比 payload 重要同样是“注入字符串”落点不同难度差很多落在 HTML 文本节点常要形成标签落在属性值要考虑引号闭合、事件属性落在已有script字符串里要考虑引号与编码落在 URL 属性可能变成javascript:协议问题。老手第一件事不是砸字典是看回显点源码上下文。Chrome F12 比一百条盲打有用。4. 反射型的修复直觉模板引擎默认转义输出到 HTML 用对应编码能用纯文本就别用“可解析 HTML”。业务若必须允许链接用白名单标签的清理库别自己写正则“过滤 script”。四、存储型 XSS实战演示思路1. 它为什么更凶脚本躺在服务器上评论、文章、用户简介、工单回复、后台配置。受害者只要正常浏览就可能中招——不一定非要点奇怪链接。管理员一打开“用户反馈”管理会话就可能交代。所以存储型在危害评级里通常高于同类反射型影响面是“谁会看到这条数据”。2. 演示路径靶场找会保存并再展示的功能留言板最经典提交探针字符串保存后打开详情页看是否原样进 HTML换成可执行证明用另一个浏览器配置/另一个账号打开确认“存储后触发”观察触发角色普通用户互看还是仅管理员后台预览角色决定危害。3. 富文本存储型的重灾区产品经理常说“评论要支持加粗和图片。”于是上线富文本编辑器服务端若只做半吊子过滤攻击者就能塞事件属性、畸形标签、svg onload 之类。这里有个残酷事实自己写 HTML 过滤器几乎必输。用成熟的、默认安全的清理库并保持更新白名单标签与属性去掉事件处理器和危险协议。4. 存储型修复直觉存可以存原文出必须按上下文编码或存之前就清理成安全子集管理端预览也要走同一套安全输出别“后台信任自己人”。五、DOM 型 XSS实战演示思路1. 为什么说“服务端可能是清白的”DOM XSS 的数据流主要在浏览器里源sourcelocation、hash、referrer、postMessage… ↓ 前端 JS 处理 汇sinkinnerHTML、document.write、eval、$(...).html()…服务端返回的 HTML 可能完全固定脚本执行是前端自己用不可信数据去喂了危险 API。传统只抓包看响应的测试会漏掉 DOM XSS。要用浏览器调试看参数进了哪段 JS。2. 演示路径自建一小页即可很多教程会写一个糟糕页面从location.hash取字符串赋给innerHTML。你改 URL 的#后面内容页面就会执行。练习时建议你亲自写坏再修好先复现危险写法改成textContent或明确创建文本节点若必须插 HTML用经过清理的结果并考虑 CSP。3. 现代前端里的变体前端路由把 query 写进页面postMessage没验 origin从localStorage读出以前存的脏数据再innerHTML第三方小部件配置项进 DOM。SPA 流行后DOM XSS 的占比其实上升了——只是名字不总叫“跨站”而叫“前端漏洞”。4. DOM 型修复直觉危险 sink 清单贴在团队 Wiki禁止对不可信数据用innerHTML/document.write/ 拼on*属性。React 默认文本转义有帮助但dangerouslySetInnerHTML就是明示危险Vue 的v-html同理。用之前问数据从哪来六、串起来的一条“实战演示”主线适合内训如果你要做一场两小时内部演示我建议别三类各打一遍字典而是讲一个故事场景一个带搜索、评论、前端高亮关键词的小站点。反射搜索关键词回显 → 证明反射型存储评论保存恶意内容 → 另一账号打开帖子中招DOM前端用 URL 参数高亮关键词却innerHTML→ 服务端已转义仍中招。同一业务三种洞学员一下就懂“输出编码要按场景做前端也是战场”。演示结束一定留 15 分钟讲修复提交模板转义、评论清理、前端改textContent、加一层 CSP。否则演示就是表演玩火。七、测试方法论比收藏 payload 重要1. 找入口所有用户可控且可能被展示的地方参数、表单、上传文件名、头像 URL、回调地址、邮件模板、运营配置。别忽略“只有管理员能看的数据”——那经常是存储型高危。2. 探针优先先用独一无二的字符串确认数据流再谈执行。乱砸 payload 会被 WAF 干扰你也分不清是没回去还是被过滤。3. 看上下文再构造进 HTML、属性、JS、CSS、URL编码方式不同。“万能 payload”是幻觉上下文才是地图。4. 双浏览器 / 双账号存储型必须验证“他人视角”。反射型验证“换个未登录/另一用户点链接”。5. 自动化辅助人工收口爬虫式 XSS 扫描器能找简单反射DOM 与业务型存储仍靠人。扫出来的东西要人工确认减少把标签过滤误报当战果。八、防御全解分层才像会打仗1. 输出编码第一原则数据离开信任边界、进入 HTML/属性/JS 时做对应上下文的编码。在现代框架里优先用默认转义的模板绑定少拼原始 HTML。2. 输入校验辅助长度、格式、白名单字符——能减少垃圾不能当唯一防线。攻击者编码花样太多。3. 富文本清理成熟库 白名单升级跟依赖 SLA 走。允许的标签里不要留事件属性URL 只允许 http(s)。4. CookieHttpOnly、Secure、SameSiteHttpOnly 让 JS 读不到会话 Cookie能挡一类偷票不挡以用户身份发请求的那类攻击所以还要配合 CSRF 防护与敏感操作二次确认。5. CSPContent Security PolicyCSP 像给浏览器下“脚本纪律”默认禁止乱七八糟的内联脚本与陌生域脚本时XSS 成功率会断崖下降。落地难在兼容要先 Report-Only 观察再 enforce尽量配合非ce 降低绕过。别指望一天全站完美 CSP但关键登录域值得先做。6. 框架与危险 API 纪律禁止清单比鼓励清单好使Code Review 扫dangerouslySetInnerHTML、v-html、innerHTML。发现一处问数据源。7. 安全头与其它X-Content-Type-Options: nosniff等减少浏览器猜类型带来的意外。完整安全头方案可另开一篇这里只强调XSS 不是只靠一个头解决。九、和 OWASP Top 10 的关系XSS 在旧版 Top 10 里单列多年2021 起更多并入注入/其它类别的讨论但业务上它仍独立存在。和 A01 越权常联动先 XSS 管理员再改配置和 A07 认证失败也联动伪造登录框收口令。修 XSS 时顺手看敏感操作有没有二次验证性价比很高。十、常见误区“我们过滤了 script 关键字。”大小写、编码、标签变形、事件属性、SVG正则防 XSS 历史记录不太光彩。“框架默认防 XSS所以没事。”直到有人用了危险 API或把用户 HTML 当可信。“有 WAF。”WAF 挡一部分反射存储与 DOM 经常绕开它的舒适区。“HttpOnly 了XSS 没用。”攻击者仍可以让浏览器自己去点“删除账号”“导出数据”。“内部系统不需要防 XSS。”内部系统才常有高权限用户存储型更值钱。十一、收尾反射型像钓鱼链接上的一次性炮弹存储型像埋在业务数据里的地雷DOM 型像前端自己挖的坑服务端查岗都可能查不到。攻的一方授权测试要会看上下文、会追数据流、会换角色验证防的一方要把输出编码、富文本纪律、危险 sink、CSP、Cookie 属性做成默认而不是出了事再救火。今晚若只做一件事打开你们站点一个“用户输入会显示出来”的页面在测试环境提交一个独一无二的探针字符串然后View Source看它落在谁家里——标签体、属性还是进了某段前端模板。认清落点之后你对 XSS 的理解会比背十个弹窗字符串扎实得多。三类演示都走通以后你会发现所谓“全解”其实不神秘数据在哪里变成了代码就在哪里设防。