Cookie能被用于SQL注入，因Request["key"]默认按QueryString→Form→Cookies→ServerVariables顺序取值，攻击者伪造Cookie即可绕过URL/表单过滤；必须禁用全局Request["xxx"]，改用明确来源（如Request.Cookies["token"]）并配合参数化查询与强类型校验。
为什么Cookie能被用来SQL注入
因为 Request["key"] 默认按 QueryString → Form → Cookies → ServerVariables 顺序查找，攻击者可伪造 Cookie 发送恶意值，绕过对 URL 和表单的过滤。比如页面用 Request["id"] 获取参数，但没限定来源，攻击者只要在浏览器里设一个 id=' OR 1=1-- 的 Cookie，就能触发注入。
必须禁用 Request[xxx] 全局取值
这是最常被忽略的根源性问题。所有使用 Request["xxx"] 的地方都存在风险，无论你是否对 QueryString 或 Form 做了过滤。
- 改用明确来源：读 URL 参数就写
Request.QueryString["id"]，读表单就写Request.Form["name"] - 读 Cookie 必须显式调用
Request.Cookies["token"]，且后续仍需校验和参数化 - 全局搜索项目中所有
Request["，逐个替换，不能只改一处
Cookie值必须走参数化查询，不能拼接
即使你从 Request.Cookies["uid"] 拿到了值，也绝不能把它直接拼进 SQL 字符串里。字符串拼接 + Cookie = 高危组合。
- 正确做法是把 Cookie 值转成强类型（如
int.TryParse或Guid.TryParse），再作为SqlParameter传入 - 示例：
cmd.Parameters.Add("@uid", SqlDbType.Int).Value = uidValue;，其中uidValue是已验证的整数 - 如果 Cookie 存的是用户名这类字符串，也要限制长度、过滤控制字符，并用
SqlDbType.NVarChar明确指定长度
别依赖“没报错就安全”这种幻觉
关闭自定义错误页、隐藏异常信息只是防暴露，不防注入。攻击者通过响应时间差（盲注）或布尔响应（比如“记录存在/不存在”页面差异）一样能猜出表结构和数据。
- 哪怕你用了
try/catch吞掉异常，只要逻辑分支受 Cookie 值影响（如if (userExists) { showAdminPanel(); }），就可能被利用 - 真正有效的防线只有两条：来源明确 + 参数化查询。其他都是辅助
- 特别注意登录态、权限判断、日志埋点等场景，这些地方常偷偷读 Cookie 又不做参数化
