如何确保SQL查询安全_采用白名单机制校验数据类型-SQL-PHP中文网

参数化查询不能替代白名单校验，因其仅防止sql注入，不校验参数值本身合法性；白名单需在数据库操作前用硬编码枚举或正则等规则严格校验字段是否符合业务预期。

如何确保sql查询安全_采用白名单机制校验数据类型

SQL参数化查询不能代替白名单校验

参数化查询（如 PreparedStatement）能防注入，但只管「值」的拼接安全，不管「值本身是否合法」。比如用户传入 "123" 是合法ID，但传入 "admin'--" 虽被当字符串字面量处理不触发注入，却可能绕过业务逻辑——如果后端没校验这个字符串是否真属于预设的枚举值、是否符合ID格式、是否在允许的租户范围内，照样出问题。

白名单校验是补位动作：它不依赖SQL引擎，而是在进入数据库操作前，用明确规则筛掉非法输入。

常见错误现象："WHERE status = ?" 用了参数化，但 ? 值是用户提交的任意字符串，结果查出不该看的数据（如 status=“deleted” 被恶意构造为 “pending,deleted” 或 JSON 字符串）
使用场景：字段值来自有限集合（如 status 只能是 "active"、"inactive"）、ID 必须为正整数、时间范围必须是 ISO8601 格式等
性能影响极小，通常只是一次字符串比对或正则匹配，远低于一次DB查询开销

用枚举类或常量数组做最简白名单

别用配置文件或数据库表存白名单值——加载慢、难校验、易被绕过。硬编码在代码里反而最可控，尤其对不变的业务状态码。

以 Java 为例，校验 status 参数：

public static boolean isValidStatus(String status) {
    return "active".equals(status) || "inactive".equals(status) || "pending".equals(status);
}

Python 更直接：

VALID_STATUSES = {"active", "inactive", "pending"}
if status not in VALID_STATUSES:
    raise ValueError("Invalid status")

避免用 switch 或 if-else 链判断，容易漏写、难维护
不要用 contains() 检查子串（如 "admin".contains("ad")），这是黑名单思维
注意大小写：统一转小写再比对，或白名单本身全小写，避免 "ACTIVE" 被放过

数字/ID类字段必须双重校验类型和范围

用户传 "123" 是字符串，但业务上它得是正整数且在合理区间。只转 Integer.parseInt() 不够——会抛异常，但没拦住负数、超大数、科学计数法（如 "1e5"）。

先用正则粗筛：^\d+$ 确保纯数字字符串（不含符号、小数点、空格）
再转数值并检查范围：Long.parseLong(idStr) > 0 && Long.parseLong(idStr)
别信 Integer.valueOf() 的缓存机制，它不校验业务意义；Long.MAX_VALUE 对业务ID毫无意义，按实际表主键上限设
ORM 框架（如 MyBatis）的 <if test="id != null and id > 0"></if> 只是模板逻辑，不阻止恶意构造的 id=0.1 或 id=-1 进入上下文

动态表名/列名必须严格映射到预定义键

SQL里没法参数化表名或列名，所以常见做法是让用户传一个标识符（如 "user_report"），后端查白名单Map映射成真实表名（"t_user_daily_report"）。这比拼字符串安全得多。

示例（Go）：

var tableMap = map[string]string{
    "user_report": "t_user_daily_report",
    "order_summary": "t_order_monthly_summary",
}
if realTable, ok := tableMap[userInput]; ok {
    query := "SELECT * FROM " + realTable + " WHERE ..."
}

绝对不要用 strings.Contains() 或 strings.Replace() 处理表名——"user_report" 被替换成 "t_user_daily_report" 后，攻击者传 "user_report; DROP TABLE t_user_daily_report" 就直接执行了
映射Key必须全小写、无符号、长度限制（如 ≤32字符），防止用 Unicode 零宽字符绕过
如果支持多租户，白名单还必须绑定租户ID，不同租户看到的 "report" 映射的物理表不同

真正麻烦的不是写几行校验代码，而是每次加新字段、新状态、新报表类型时，都得同步更新白名单——漏一处，防线就破一个口子。