cookie注入漏洞根源在于$_cookie参数未过滤、未类型转换、未参数化即拼入sql，修复必须用intval()强转、预处理语句或白名单校验，仅过滤单引号无效且易被绕过。
直接修复 $_COOKIE 取值拼接SQL的代码
绝大多数 Cookie 注入漏洞，根源在于 PHP 中类似这样的写法：$id = $_COOKIE['id']; $sql = "SELECT * FROM users WHERE id = $id";。变量未过滤、未类型转换、未参数化，直接进 SQL 字符串——这是最危险的模式。
必须立刻替换为以下任一方式：
- 整数型参数：用
(int)或intval()强制转整，再判断是否为正数，如$id = (int)$_COOKIE['id']; if ($id - 字符串型参数：绝不用
mysql_real_escape_string（已废弃），改用 PDO 预处理，$stmt = $pdo->prepare("SELECT * FROM users WHERE name = ?"); $stmt->execute([$_COOKIE['name']]); - 白名单校验：若参数是状态码、类型标识等有限取值，直接比对数组，如
in_array($_COOKIE['role'], ['admin', 'user', 'guest'])
为什么不能只过滤单引号？
只对 $_COOKIE 值做 str_replace("'", "''", $val) 或正则删引号，根本无效。攻击者可绕过：id=1 OR 1=1 不含引号照样执行；id=1 UNION SELECT 1,2,3 同样不依赖引号；MySQL 还支持反引号、十六进制编码（0x61646d696e）、宽字节截断等绕过手段。
过滤是防御下限，不是解决方案。只要拼接字符串，就存在被绕过风险。唯一可靠路径是彻底隔离数据与逻辑——即预处理语句或强类型转换。
ASP/ASP.NET 中 Request("xxx") 的隐患怎么清？
ASP 经典环境下，Request("id") 默认按 QueryString → Form → Cookies → ServerVariables 顺序取值，极易被 Cookie 覆盖而绕过前端校验。这不是“功能”，是设计缺陷。
修复动作很明确：
- 全部显式调用
Request.QueryString("id")或Request.Form("id")，禁止使用无集合名的Request("id") - 若必须从 Cookie 读，明确写
Request.Cookies("id")，并在取值后立即做IsNumeric()或正则校验 - 在 IIS 全局或应用层配置中禁用
EnableParentPaths和不安全的脚本映射，减少攻击面
测试时容易漏掉的 Cookie 注入点
开发常以为“没显式读 Cookie 就安全”，但真实漏洞常藏在间接路径里：
- 登录态校验中间件自动解析
session_id并查库，而该 session_id 来自 Cookie 且未校验长度/格式 - 前端埋点 SDK 上传的
uid、device_id被后端日志模块或风控接口直接拼进审计 SQL - CDN 或 WAF 透传了原始 Cookie，但业务代码误把
X-Forwarded-For头里的伪造 Cookie 当真实值用
真正要扫全，得抓包看所有请求头中的 Cookie: 字段，再逆向追踪每个键名在代码中是否被用于构造 SQL —— 不是看有没有 $_COOKIE，而是看有没有“未经清洗的数据流进了查询语句”。
