如何校验SQL输入合法性_检查JSON/XML数据结构

2次阅读

校验需结合执行上下文：SQL 动态标识符用白名单，条件参数化；JSON 需检查错误码、深度限制与大整数处理；XML 要捕获 libxml 错误并禁用外部实体。

如何校验 SQL 输入合法性_检查 JSON/XML 数据结构

SQL 注入不是靠一个 preg_match 就能拦住的。真正有效的校验必须绑定具体使用场景——是拼进 WHERE 子句的字符串？还是作为表名动态传入？前者可用参数化绕过校验，后者根本不能参数化，必须白名单控制。

动态表名、列名、排序字段（ORDER BY 后）必须用预定义枚举或严格白名单，比如只允许 ['id', 'created_at', 'status']
用户输入用于 WHERE 条件时，优先走参数化查询（PDO::prepare 或 mysqli->prepare），而不是“校验后拼接”
真要校验原始 SQL 片段（如管理后台的即席查询），用现成解析器比正则靠谱：PHP 可用 sql-parser 库做语法树分析，检查是否含 UNION、SELECT 嵌套、子查询等高风险结构
常见错误：用 stripslashes + addslashes 当防护，这在多字节编码或宽字符场景下形同虚设

if (!in_array($sort_field, ['name', 'email', 'updated_at'], true)) {throw new InvalidArgumentException('Invalid sort field'); }

json_decode($input, true) 返回 null 只说明解析失败，但不告诉你为什么失败——是编码问题？还是超深嵌套？还是循环引用（虽然 JSON 本身不允许）？更关键的是，它完全不验证业务结构。

先确保 json_last_error() 是 JSON_ERROR_NONE，再检查 json_last_error_msg()，有些错误（如 JSON_ERROR_DEPTH）会被静默吞掉
结构校验别手写 isset() 套娃，用 webmozart/assert 或原生 filter_var($data, FILTER_VALIDATE_REGEXP, [……]) 配合 JSON Schema（推荐 justinrainbow/json-schema）
注意 json_decode 默认把数字全转成 float，大整数（如微信 openid、雪花 ID）会丢失精度；加第二个参数 true 和第三个参数 JSON_BIGINT_AS_STRING 才安全
常见错误：收到空字符串或空白符就直接 json_decode，结果返回 null 却没检查 json_last_error()，误判为合法 JSON

json_decode($input, true, 512, JSON_BIGINT_AS_STRING) —— 深度 512 是防爆栈，JSON_BIGINT_AS_STRING 防 ID 截断

DOMDocument::loadXML() 报错可能是 DTD 不可达、外部实体开启、编码声明错位，甚至只是某处多了个 & 符号。它不区分“格式错误”和“加载失败”。

加载前先用 libxml_use_internal_errors(true) 拦住警告，再调 libxml_get_errors() 拿具体错误码，比如 XML_ERR_UNCLOSED_TOKEN 才是真语法错，XML_ERR_NAME_REQUIRED 可能只是开头缺 XML 声明
业务级结构校验靠 XSD：用 DOMDocument::schemaValidate()，但注意 PHP 的 libxml 对 XSD 1.1 支持有限，别用 assertions 类特性
禁用外部实体（防 XXE）必须显式调 libxml_disable_entity_loader(true)（PHP < 8.0）或设 LIBXML_NONET | LIBXML_NOENT 标志，否则校验过程本身就有风险
常见错误：用 simplexml_load_string() 替代 DOMDocument，它对错误容忍过高，<foo>&</foo> 这种会静默丢掉 & 后所有内容