XSS 漏洞排查清单：从前端代码到模板渲染

XSS（跨站脚本攻击）依然是 Web 安全领域最常见的漏洞类型之一。它的核心逻辑并不复杂：攻击者将恶意脚本注入到页面中，当其他用户访问该页面时，脚本在用户浏览器中执行，从而窃取 Cookie、会话令牌、甚至发起蠕虫式传播。但真正棘手的地方在于，XSS 的注入点遍布前端代码、后端模板、API 响应、富文本编辑器等各个环节，排查时容易顾此失彼。本文整理了一份从浏览器端到服务端的排查清单，并附带 SQL 注入防护与 Linux 服务器加固的实用建议，供开发和运维同学对照使用。

一、XSS 的常见注入方式

在排查之前，先明确攻击者通常从哪里下手：

• 反射型 XSS：恶意脚本作为请求参数传入，服务端未过滤直接拼接到 HTML 中返回。常见于搜索框、错误提示页、跳转链接。
• 存储型 XSS：恶意内容被存入数据库（如评论、昵称、文章），其他用户访问时触发。危害最大，可持久化传播。
• DOM 型 XSS：不经过服务端，前端 JavaScript 直接从 location.hash、document.referrer、innerHTML 等来源读取数据并插入 DOM。
• 基于 mutation 的 XSS：利用浏览器解析差异，例如 <noscript> 标签内的内容在某些浏览器中仍会被解析执行。

二、前端代码排查清单

前端是 XSS 防御的第一道防线，重点检查所有“把数据当代码执行”的操作：

1. 危险的 DOM 操作：搜索代码中所有 innerHTML、outerHTML、document.write、insertAdjacentHTML 的使用。如果插入的内容包含用户输入，必须改用 textContent 或先做转义。
2. URL 与事件属性：检查 href、src、onclick 等属性是否直接拼接用户数据。javascript: 伪协议是常见绕过方式，应使用白名单校验协议。
3. eval 与 Function 构造器：eval()、new Function()、setTimeout(string) 都可能执行字符串代码，尽量避免使用。
4. 前端框架的转义机制：React 默认对 JSX 中的变量做转义，但 dangerouslySetInnerHTML 会绕过；Vue 的 v-html 同样危险。排查这些“逃生舱”的使用场景。
5. 第三方库与 CDN：引入的第三方脚本是否来自可信源？是否使用了 SRI（子资源完整性）校验？

三、模板渲染与服务端排查清单

服务端模板引擎的自动转义能力参差不齐，需要逐项确认：

• 模板引擎配置：Jinja2、Twig、Handlebars 等默认开启自动转义，但 |safe、{{{ }}}、{!! !!} 会关闭转义。检查这些标记是否被滥用。
• 输出编码上下文：HTML 正文、HTML 属性、JavaScript 变量、CSS、URL 各自需要不同的编码方式。只做 HTML 实体编码并不足以覆盖所有场景。
• HTTP 响应头：设置 Content-Type: text/html; charset=utf-8，避免浏览器将 JSON 误判为 HTML。同时配置 X-Content-Type-Options: nosniff。
• CSP 策略：内容安全策略是纵深防御的关键。至少设置 default-src 'self'，禁止 unsafe-inline 和 unsafe-eval。CSP 不能替代输入过滤，但能大幅降低 XSS 成功后的危害。
• Cookie 安全属性：为会话 Cookie 设置 HttpOnly（阻止 JS 读取）、Secure（仅 HTTPS 传输）、SameSite=Lax 或 Strict。
• 富文本处理：如果业务允许用户提交 HTML，必须使用成熟的白名单过滤库（如 DOMPurify），而不是自己写正则。

四、MySQL 防止 SQL 注入的几种写法

XSS 与 SQL 注入常在同一入口出现，防护思路可以互相参照。MySQL 场景下推荐以下写法：

1. 预处理语句（Prepared Statement）：这是最可靠的方式。以 PHP PDO 为例：

$stmt = $pdo->prepare('SELECT * FROM users WHERE email = :email');
$stmt->execute(['email' => $email]);

参数与 SQL 结构分离，数据库不会将用户输入当作 SQL 语法解析。

2. 参数化查询（各语言通用）：Java 的 PreparedStatement、Python 的 cursor.execute(sql, params)、Node.js 的 mysql2 占位符，原理相同。

3. ORM 框架：Django ORM、SQLAlchemy、Eloquent 等默认使用参数绑定，但要注意 raw()、extra()、whereRaw() 等原生 SQL 接口。

4. 输入校验与最小权限：对类型、长度、格式做白名单校验；数据库账号只授予必要权限，禁止使用 root 连接应用。

5. 避免拼接：永远不要用字符串拼接构造 SQL，包括表名和字段名——这些位置无法用占位符，必须用白名单映射。

五、Linux 服务器安全加固清单

即使应用层防护到位，服务器本身的安全基线也不能忽视：

• 账户与权限：禁用 root 远程登录，使用 SSH 密钥认证，关闭密码登录；为每个服务创建独立低权限用户。
• 补丁与更新：定期更新内核、OpenSSH、Nginx/Apache 等组件，订阅安全公告。
• 防火墙与端口：使用 ufw 或 firewalld 仅开放必要端口；数据库端口不对公网暴露。
• 日志与监控：开启 auditd 或 fail2ban，监控异常登录和提权行为；集中收集应用与系统日志。
• 文件权限：Web 目录禁止执行上传的脚本文件；敏感配置文件权限设为 600。
• 备份与恢复：定期备份关键数据，并验证恢复流程可用。

结语

XSS 排查不是一次性的任务，而是贯穿开发、测试、上线、运维的持续过程。前端要管住 DOM 操作，后端要管住模板转义和响应头，运维要管住服务器基线。把这份清单纳入代码审查和上线检查流程，能挡住绝大多数常见攻击。安全没有银弹，但系统化的排查习惯，本身就是最有效的防线。

未经允许不得转载：任鹏个人博客 » XSS 漏洞排查清单：从前端代码到模板渲染