如何防范SQL注入的数据污染_使用参数绑定的插入操作-SQL-PHP中文网

python的sqlite3不能用字符串拼接写insert，因会引发sql注入；必须用?占位符配合元组/列表参数绑定，且表名列名需白名单校验。

如何防范sql注入的数据污染_使用参数绑定的插入操作

Python 的 `sqlite3` 为什么不能用字符串拼接写 `INSERT`

因为拼接会把用户输入直接塞进 SQL 字符串里，数据库根本分不清哪是字段名、哪是恶意代码。比如用户输 ' OR '1'='1，拼出来可能变成：INSERT INTO users (name) VALUES ('' OR ''1''=''1')——这条语句语法合法，但逻辑已失控。

真正起作用的是参数绑定机制：驱动层把值当纯数据传给数据库，不参与 SQL 解析。哪怕值里含分号、单引号、-- 注释符，数据库也只认它是“一个字符串值”，不会执行。

sqlite3 只支持 ? 占位符（位置绑定），不支持命名绑定（如 :name）
值必须以元组或列表传入 execute()，单个值也要写成 (value,)，漏逗号会报 TypeError: parameters are of unsupported type
表名、列名不能参数化——它们属于 SQL 结构，必须提前校验或白名单控制

PHP 的 `PDO::prepare()` 绑定失败的典型表现

常见错误不是报“SQL 注入”，而是 SQLSTATE[HY093]: Invalid parameter number 或插入空值/默认值。这通常是因为占位符数量和 bindValue() 次数对不上，或者用了命名绑定但名字拼错（比如写成 :user_name 却传 user_name）。

更隐蔽的问题是类型强制：PDO 默认把所有绑定值当字符串处理。如果字段是 INT，而你传了字符串 "123"，某些数据库（如 MySQL）会静默转类型，但 PostgreSQL 可能直接报错 ERROR: column "id" is of type integer but expression is of type text。

用 PDO::PARAM_INT 显式声明整型参数，避免隐式转换风险
命名绑定时，占位符必须带冒号：:email，但 bindValue() 第一个参数要写 ":email"（带引号）或 email（不带引号，取决于调用方式）
批量插入用 execute($array) 时，数组键名必须严格匹配 SQL 中的命名占位符

Java 的 `PreparedStatement` 设置 `NULL` 值的坑

直接传 null 给 setString() 等方法是合法的，但有些 JDBC 驱动（尤其是旧版 MySQL Connector/J）在遇到 NULL 且字段有 NOT NULL 约束时，不报错反而插进空字符串或默认值，导致数据污染难以追溯。

根本原因是：JDBC 规范允许驱动对 NULL 做自定义处理，而业务代码又没做字段可空性校验。结果就是前端传了个空邮箱，后端绑定了 null，数据库却存了 ""，后续按 IS NULL 查询永远查不到。

对可能为 NULL 的字段，优先用 setNull(int parameterIndex, int sqlType)，明确告知数据库这是 SQL NULL
sqlType 必须和字段实际类型一致，比如 Types.VARCHAR 对应 VARCHAR，Types.INTEGER 对应 INT
插入前检查字段约束：如果数据库字段定义为 NOT NULL，代码里就不该允许传 null，而应抛异常或走默认值逻辑

Node.js 的 `pg` 模块如何安全传数组参数

PostgreSQL 支持数组类型（如 TEXT[]），但 pg 默认不展开 JS 数组。如果你写 INSERT INTO t(a) VALUES ($1) 并传 ['a','b']，它会尝试把整个数组当单个字符串插进去，报错 malformed array literal。

正确做法是让 pg 把 JS 数组序列化为 PG 数组字面量，靠的是参数类型自动推导 + 显式类型标注。否则，即使 SQL 语法对，数据格式也不被识别。

传数组时，SQL 占位符保持 $1 不变，但值必须是 JS 数组（如 ['x','y','z']），不能是字符串 "{x,y,z}"
如果字段是 TEXT[]，pg 通常能自动识别；但对 INT[] 等类型，建议加类型标注：{ text: 'INSERT...', values: [arr], types: ['int4[]'] }
慎用 pg-format 这类字符串格式化库——它本质还是拼接，绕过了参数绑定，一旦用于动态列名或条件就立刻破防