3. 输入验证与输出编码工程实践
注入与跨站脚本之所以长期占据漏洞榜前列，根本原因往往不是开发者不知道要过滤，而是把"过滤"当成了一个可以随意摆放的孤立动作。真正可靠的工程做法是：在数据进入系统的每一个真实入口处做输入验证，在数据离开系统进入不同解释器之前做输出编码，两者分工明确、缺一不可。本节围绕用户输入、文件上传、API 参数三类典型入口，给出可落地的白名单校验、类型约束、长度限制与上下文输出编码方案。
一、先分清两个边界：入口验证与出口编码
输入验证的目标是"只让符合预期形态的数据进入业务逻辑"，它回答的是"这个值是否合法"。输出编码的目标是"让数据在目标上下文中不被当作代码执行"，它回答的是"这个值放到 HTML、SQL、URL、JS 里是否安全"。二者不能互相替代：一个通过了白名单校验的用户昵称，仍然可能包含 < 或引号，直接拼进 HTML 就会造成 XSS；反过来，做了 HTML 转义的数据直接拼进 SQL 语句，依然会被注入。
因此工程上应遵循两条原则：验证在入口、编码在出口；编码必须与目标上下文匹配。下面这张图展示了从外部输入到最终落点的完整链路，以及每一环该做什么。
二、白名单校验：从"禁止什么"转向"允许什么"
黑名单（禁止 <script>、禁止 ' OR 1=1）几乎必然被绕过，因为攻击者可以用编码、大小写、注释、Unicode 变体构造无穷多等价形式。白名单的思路是：先明确该字段的合法取值空间，再拒绝一切不在空间内的输入。
以用户注册接口为例，字段与规则可以这样定义：
| 字段 | 类型 | 白名单/格式 | 长度 | 失败处理 |
|---|---|---|---|---|
| username | string | ^[A-Za-z0-9_]{3,20}$ | 3–20 | 400 + 字段名 |
| age | int | 1 ≤ age ≤ 120 | — | 400 |
| role | enum | {user, editor, admin} | — | 400 |
| string | RFC 5322 简化正则 | ≤ 254 | 400 | |
| avatar | file | MIME ∈ {png,jpeg} 且魔数匹配 | ≤ 2 MB | 400 |
实现时要注意三点。第一，类型约束优先于格式约束：如果 age 声明为整数，就应先做类型转换并捕获异常，而不是用正则去匹配字符串。第二，长度限制必须在解析前生效：对 JSON 请求体设置最大字节数（如 64 KB），对单个字段设置最大长度，避免超长输入触发正则回溯或内存膨胀。第三，校验失败要统一返回 400 并记录字段名，不要回显原始输入，否则错误页本身可能成为反射型 XSS 的载体。
// Node.js + express-validator 示例（教学示例）
const rules = [
body('username').isString().trim()
.matches(/^[A-Za-z0-9_]{3,20}$/),
body('age').isInt({ min: 1, max: 120 }).toInt(),
body('role').isIn(['user', 'editor', 'admin']),
body('email').isEmail().isLength({ max: 254 }),
];
app.post('/register', rules, (req, res) => {
const errors = validationResult(req);
if (!errors.isEmpty()) {
return res.status(400).json({ fields: errors.array().map(e => e.path) });
}
// 进入业务逻辑
});三、文件上传：三重校验缺一不可
文件上传是输入验证中最容易被忽视的入口。仅检查扩展名或仅检查 Content-Type 都不够，因为两者都由客户端提供、可被伪造。工程上应做三重校验：
- 扩展名白名单：只允许
.png、.jpg、.jpeg，拒绝.php、.jsp、.svg（SVG 可内嵌脚本）等。 - MIME 类型白名单：服务端读取请求头中的
Content-Type，只接受image/png、image/jpeg。 - 文件魔数校验：读取文件前若干字节，PNG 应为
89 50 4E 47，JPEG 应为FF D8 FF。这一步能识破"改扩展名"的伪装。
此外，上传目录必须放在 Web 根目录之外，或通过反向代理禁止该目录执行脚本；文件名要重命名为随机 UUID，避免路径穿越（../../etc/passwd）和覆盖攻击。若业务确实需要展示用户上传的图片，应通过独立的静态资源域名提供，并设置 Content-Disposition: attachment 或严格的 Content-Security-Policy。
四、API 参数：结构化校验与参数化查询
API 参数常见于 JSON 请求体、查询字符串和路径变量。对 JSON，应使用 Schema 校验（如 JSON Schema、Zod、Joi），把类型、必填、枚举、嵌套结构一次性声明清楚；对查询字符串，注意数组参数（?id=1&id=2）和重复键的处理，避免解析歧义。
SQL 注入的根本解法是参数化查询，而不是对输入做转义。下面两段代码对比了错误与正确做法：
// 错误：字符串拼接，即使做了转义也可能被绕过
const sql = `SELECT * FROM users WHERE name = '${name}'`;
// 正确：参数化查询，数据库驱动负责绑定
const sql = 'SELECT * FROM users WHERE name = ?';
db.query(sql, [name]);对于 ORDER BY、表名、列名这类无法参数化的位置，必须使用白名单映射：把用户传入的 sort 值映射到预定义的列名集合，映射失败则使用默认值，绝不能直接拼接。
五、输出编码：按上下文选择转义方式
输出编码的关键是"看落点"。同一个用户昵称，放到不同位置需要不同的处理：
- HTML 文本节点：转义
& < > " '，或使用模板引擎的自动转义（如 Jinja2、React JSX 默认转义）。 - HTML 属性：除上述字符外，属性值必须加引号，避免未加引号时通过空格注入新属性。
- JavaScript 上下文：使用
JSON.stringify并转义</script>，或使用textContent而非innerHTML。 - URL 参数：使用
encodeURIComponent，不要手工拼接。 - CSS 上下文：对非字母数字字符做十六进制转义，避免
expression()等历史漏洞。
六、把规则固化为可复用的检查清单
为了让上述实践在团队中稳定落地，可以把入口验证与出口编码整理成一份可勾选的检查表，在代码评审和上线前逐项确认：
| 检查项 | 判断依据 | 通过标准 |
|---|---|---|
| 所有入口字段是否有类型与长度约束 | 接口文档 / Schema 定义 | 无遗漏字段 |
| 枚举字段是否使用白名单集合 | 代码中的 isIn / enum | 无自由文本枚举 |
| SQL 是否全部参数化 | 代码扫描 ${ 拼接 | 无字符串拼接 SQL |
| 动态排序/列名是否白名单映射 | 映射表存在且默认值安全 | 映射失败走默认 |
| 文件上传是否三重校验 | 扩展名 + MIME + 魔数 | 三项均实现 |
| 输出点是否按上下文编码 | 模板自动转义 / 手动编码函数 | 无 innerHTML 直插 |
| 错误响应是否避免回显原始输入 | 错误页内容检查 | 只返回字段名与错误码 |
需要强调的是，输入验证与输出编码不是一次性的开发任务，而是需要持续维护的工程约束。每当新增一个接口、一个上传入口或一个前端渲染点，都应回到这份清单上确认对应规则是否覆盖。只有把"验证在入口、编码在出口"变成默认习惯，注入与 XSS 才会从"偶发漏洞"变成"结构性不可能"。