为什么不要在SQL语句中直接拼接Cookie值_预防针对认证凭据的注入-SQL-PHP中文网

cookie值拼接进sql等于直接交出数据库钥匙，必须用参数化查询防御。攻击者可篡改cookie执行任意sql，base64或简单正则无法阻止绕过，签名仅防篡改不解决拼接问题，orm手动拼接同样中招。

为什么不要在sql语句中直接拼接cookie值_预防针对认证凭据的注入

SQL语句里拼接 `Cookie` 值等于主动交出数据库钥匙

直接把 Cookie 里的值（比如 session_id=abc123 或 user_token=xyz789）用字符串拼接进 SQL 查询，等同于让攻击者能任意控制查询逻辑。这不是“可能被注入”，而是“只要 Cookie 可篡改，就必然可注入”——因为 HTTP Cookie 完全由客户端控制，服务端未校验、未参数化时，它和用户输入没有任何区别。

`SELECT * FROM users WHERE token = '` + cookie_value + `'` 是典型高危写法

这种拼接常见于老式登录校验或会话查找逻辑，例如在 Node.js 中用 mysql 模块、PHP 中用 mysqli::query、Java 中用 Statement.execute 等非参数化方式构造 SQL。

攻击者只需在 Cookie 中传入 user_token=' OR '1'='1，整条语句就变成：

SELECT * FROM users WHERE token = '' OR '1'='1'

结果是匹配全部用户，甚至配合注释符 -- 或分号 ; 还能执行多语句（取决于驱动是否启用多语句模式）。

一个php类用于处理cookie会话

下载

即使 Cookie 值经过 base64 编码或简单正则过滤（如只允许字母数字），也挡不住绕过：base64 解码后仍是可控字符串，正则漏掉 '、;、/* 等关键字符很常见
部分框架对 Cookie 做了签名（如 Express 的 signedCookies），但签名只防篡改，不解决拼接本身的问题——一旦签名密钥泄露或验证逻辑被绕过，照样崩
ORM 如 Sequelize、TypeORM 默认也不自动防御拼接；若手动拼进 where 字段（如 where: `token = '${req.cookies.token}'`），照样中招

唯一安全做法：所有外部输入走参数化查询或预编译语句

无论来源是 URL、Body 还是 Cookie，只要是动态值，就必须脱离 SQL 字符串结构。

Node.js（pg）：用 client.query('SELECT * FROM users WHERE token = $1', [req.cookies.token])
Python（psycopg2）：用 cursor.execute("SELECT * FROM users WHERE token = %s", (request.cookies.get('token'),))
PHP（PDO）：用 $stmt = $pdo->prepare("SELECT * FROM users WHERE token = ?"); $stmt->execute([$token]);
Java（JDBC）：必须用 PreparedStatement，绝不用 Statement 拼接