17370845950

SQL参数化查询是防止SQL注入最有效、最基础的手段，核心在于让数据与SQL逻辑彻底分离：用户输入永远作为“值”传入，绝不会被数据库当作SQL代码执行；需严格区分拼接与参数化，所有动态值必须参数化，表名列名等非值内容须用白名单校验，并配合最小权限、输入校验、错误脱敏等多重防御。

SQL参数化查询是防止SQL注入最有效、最基础的手段，核心在于让数据与SQL逻辑彻底分离：用户输入永远作为“值”传入，绝不会被数据库当作SQL代码执行。

明确区分“拼接”和“参数化”

错误做法（字符串拼接）：
危险！直接拼接用户输入，极易被注入

string sql = "SELECT * FROM users WHERE username = '" + username + "'";

正确做法（使用参数占位符）：
数据库驱动自动处理类型、转义和上下文隔离

• SQL Server（C#）：cmd.Parameters.AddWithValue("@name", username);
• MySQL（Python/PyMySQL）：cursor.execute("SELECT * FROM users WHERE id = %s", (user_id,))
• PostgreSQL（Node.js/pg）：client.query('SELECT * FROM logs WHERE level = $1', ['error'])

所有动态值都必须参数化，不放过任何例外

常见误区：只对WHERE条件参数化，忽略ORDER BY字段、LIMIT数量、表名或列名——这些不能参数化，需用白名单校验

• ✅ 允许参数化的：WHERE值、INSERT值、UPDATE SET值、IN列表中的每个元素（用对应数量占位符）
• ❌ 不允许参数化的：表名、列名、排序方向（ASC/DESC）、分页偏移量（需整型强转+范围检查）
• ? 替代方案：用预定义白名单映射用户输入，例如：sortCol = {"name": "user_name", "time": "created_at"}.get(userSort, "id")

使用预编译语句（Prepared Statement）并复用

多数数据库驱动在首次执行带参数的SQL时会自动预编译，后续执行仅传参，既提升性能又增强安全性

• 避免每次查询都新建SQL字符串，尤其在循环中
• ORM如Entity Framework、Django ORM、MyBatis默认启用参数化，但需确认未开启“原始SQL拼接”开关
• 警惕ORM中的raw()、execute()、$sql等绕过机制——它们仍需手动参数化

配合其他防御层，不依赖单一手段

参数化是基石，但不是万能解药。需叠加最小权限、输入校验、错误信息脱敏等措施

• 数据库账号仅授予必要权限（如不用root连接应用）
• 前端+后端双重校验输入格式（如手机号正则、ID长度限制），虽不防注入但可快速拦截异常请求
• 生产环境关闭详细SQL错误提示，避免暴露表结构或数据库版本