当前位置：首页 > news >正文

Cookie注入攻击原理与防御：从SQL注入到Web安全实战

news 2026/6/28 22:05:47

1. 项目概述：从“登录框”到“数据金库”的隐秘通道

做安全测试这些年，我越来越觉得，那些最危险的漏洞，往往不是摆在明面上的。比如一个看似平平无奇的登录框，或者一个记录你浏览偏好的小文件，都可能成为攻击者撬开整个系统大门的支点。今天要聊的“Cookie注入”和“SQL注入”，就是这类“四两拨千斤”的典型。很多人一听到SQL注入，脑子里立马蹦出在登录框里输入‘ or ‘1’=’1的场景，这没错，但那是“显山露水”的字符型注入。而Cookie注入，则更像一个潜伏在暗处的“影子刺客”，它利用的是Web应用在处理用户身份标识（Cookie）时的不严谨，将恶意代码悄无声息地“夹带”进数据库查询中。

这个实验报告，就是一次对这种隐秘攻击手法的深度复盘。它不仅仅是记录一次成功的漏洞利用，更是要拆解清楚：为什么一个本该用于维持会话状态的小小Cookie，会成为致命的安全短板？攻击者是如何绕过前端的所有防护，直接与后端数据库“对话”的？我们通过搭建靶场环境（比如经典的DVWA或Pikachu），模拟攻击者的视角，从信息探测、漏洞判断、Payload构造，到最终的数据窃取或系统控制，完整地走一遍攻击链。同时，我也会对比手工注入与自动化工具（如SQLMap）的优劣，分享在实战中如何根据不同的WAF（Web应用防火墙）规则进行绕过。无论你是刚入门CTF（Capture The Flag）的新手，想搞懂那些Web题目的套路，还是负责开发运维，希望从攻击者角度加固自己的系统，这篇从一线实战中总结出的“攻防笔记”，都能给你带来实实在在的启发。

2. 漏洞原理深度剖析：不当信任引发的连锁反应

要理解Cookie注入，必须先吃透SQL注入的根。很多人会操作，但未必真明白背后的“为什么”。

2.1 SQL注入的核心：拼接信任的崩塌

SQL注入的本质，是程序将用户输入的数据，未经充分处理就直接拼接到了SQL查询语句中，从而改变了原语句的语义。想象一下，后端代码原本是这样写的：

$sql = “SELECT * FROM users WHERE username = ‘“ . $_POST[‘username’] . “‘ AND password = ‘“ . $_POST[‘password’] . “‘“;

这行代码的本意是验证用户名和密码。但当攻击者在用户名输入框填入admin‘ --（注意最后有个空格）时，拼接后的SQL语句就变成了：

SELECT * FROM users WHERE username = ‘admin‘ -- ‘ AND password = ‘...‘

在SQL中，--是注释符，这意味着它后面的所有内容都被注释掉了。于是，这个查询就变成了“查找用户名为admin的记录”，完全绕过了密码验证。这就是最经典的“万能密码”绕过登录的原理。字符型注入的关键在于闭合原语句中的引号，并插入新的逻辑。

而数字型注入则更简单，因为参数本身不需要引号包裹：

$id = $_GET[‘id‘]; // 假设id是数字 $sql = “SELECT * FROM articles WHERE id = “ . $id;

如果攻击者传入id=1 UNION SELECT username, password FROM users，语句就变成了联合查询，直接泄露用户表数据。

注意：这里演示的是最原始、最危险的情况。现在但凡有点经验的开发者都不会这么写，但理解这个原始模型是分析所有变种和绕过技术的基础。

2.2 Cookie注入：被遗忘的输入向量

那么，Cookie注入特殊在哪？关键在于输入来源。绝大多数开发者和初级WAF，会把防护重点放在明面的用户输入上，比如$_GET、$_POST、$_REQUEST。但Cookie（$_COOKIE）同样是一个可以被客户端完全控制的超全局变量，却常常被忽视。

一个典型的场景是：网站为了个性化展示，将用户的偏好设置（如user_id、theme）存放在Cookie中。后端代码可能这样使用：

$user_id = $_COOKIE[‘uid‘]; $sql = “SELECT * FROM user_prefs WHERE user_id = ‘“ . $user_id . “‘“;

攻击者根本不需要在网页表单上做任何操作。他只需要用浏览器插件（如EditThisCookie）或开发者工具，将Cookie中uid的值从正常的“123”修改为123‘ UNION SELECT database(), user(), version() --，然后刷新页面。后端程序会毫无戒备地将这个恶意值拼进SQL语句，执行攻击者预设的查询，返回数据库名、当前用户、版本等敏感信息。

Cookie注入的隐蔽性优势：

绕过前端验证：所有前端JavaScript验证形同虚设，因为攻击直接修改了HTTP请求头中的Cookie值。
日志污染小：攻击载荷存在于HTTP请求头而非URL或Body中，普通的访问日志可能不会详细记录头部信息，增加了溯源难度。
攻击入口多：任何读取Cookie进行数据库操作的地方都可能成为入口，不局限于某个特定功能页面。

2.3 与常见注入类型的关联与区别

从热词中可以看到很多注入类型，理解它们有助于我们精准判断漏洞点：

字符型 vs 数字型：最根本的区别在于参数是否被引号包裹。判断方法通常是传入参数后加单引号‘，看是否报错。报错通常是字符型，不报错但页面异常可能是数字型。
报错注入：利用数据库执行错误时，将错误信息（其中包含查询结果）回显到页面的特性进行数据窃取。常用函数如updatexml()、extractvalue()。
布尔盲注与时间盲注：当页面没有明确回显和报错时使用。通过构造SQL语句，让页面返回真/假（布尔盲注）或响应快/慢（时间盲注，用sleep()函数）两种状态，像猜谜一样一位一位地推断数据。
堆叠查询：利用分号;执行多条SQL语句。但并非所有数据库或连接驱动都支持。
二次注入：恶意数据先被存入数据库（第一次入库时可能被转义了），之后在另一个逻辑中从数据库取出并被使用，此时转义已被解除，造成注入。这是防御中最容易疏忽的环节。

Cookie注入可以是以上任何一种类型，它只是指明了攻击载荷的来源是Cookie，而不是其技术原理。

3. 实验环境搭建与手工注入实战

理论说再多，不如亲手试一次。我们选择一个经典且可控的环境——DVWA（Damn Vulnerable Web Application）作为靶场。它集成了多种漏洞，安全等级可调，非常适合学习。

3.1 靶场环境部署与配置

我习惯在本地用PHPStudy或Docker快速搭建一个LAMP（Linux+Apache+MySQL+PHP）环境。将DVWA源码放到Web目录后，有几个关键配置点：

数据库连接：修改config/config.inc.php，确保数据库地址、用户名、密码正确。DVWA默认使用MySQL。
安全等级设置：DVWA的核心特性。在首页下方可以设置安全等级为“Low”、“Medium”、“High”、“Impossible”。为了复现漏洞，我们首先设置为“Low”，这会关闭几乎所有服务端防护。
Cookie关键点：进入DVWA的“SQL Injection”模块。在Low安全等级下，它的漏洞代码是直接拼接$_GET[‘id‘]参数。但我们的目标是Cookie注入。所以我们需要先找到那些使用Cookie进行查询的地方。一个常见的思路是，网站可能用Cookie来保存上一次查询的ID或用户状态。虽然DVWA默认的SQL注入模块不直接演示Cookie注入，但我们可以通过修改其源码或寻找其他类似靶场（如Pikachu靶场，其“Cookie注入”关卡是经典教学案例）来模拟。为了实验的纯粹性，我们可以假设这样一个场景：页面通过Cookie中的id参数来展示对应文章，后端代码如下：
```
// 模拟漏洞代码 (vuln.php) $id = $_COOKIE[‘id‘]; // 危险！直接从Cookie取参 $query = “SELECT title, content FROM articles WHERE id = ‘$id‘“; $result = mysqli_query($conn, $query);
```

实操心得：在本地搭建靶场时，务必使用独立的数据库和虚拟主机，避免误操作影响其他项目。同时，将靶场的错误报告级别调至最高（error_reporting(E_ALL)），这样SQL语法错误会清晰地显示在页面上，便于我们判断注入点类型，这是手工注入的第一步。

3.2 手工注入四步法：探测、判断、利用、获取

假设我们已经找到了上述那个脆弱的vuln.php页面。现在，我们完全不知道它的SQL语句是什么，需要像侦探一样一步步推理。

第一步：探测与确认注入点

访问vuln.php页面。由于没有提供GET参数，页面可能显示默认文章或报错。我们用浏览器插件将名为id的Cookie值设为1。
刷新页面，假设它显示了ID为1的文章。
关键试探：将Cookieid的值改为1‘（数字1加一个单引号）。刷新页面。
- 如果页面返回数据库错误（如“You have an error in your SQL syntax...”），这几乎可以肯定存在字符型SQL注入漏洞，并且错误回显打开了，这是最理想的情况。
- 如果页面空白、与原页面不同或异常，也可能存在注入，需要进一步盲注测试。
- 如果页面正常显示ID为1的内容，那可能不存在注入，或者是数字型注入（数字型加单引号会破坏语法，但若原语句无引号，1‘会被转换成数字1，部分环境可能不报错）。此时可尝试1 and 1=2，如果正常内容消失，则说明注入存在。

第二步：判断字段数（为UNION查询做准备）UNION查询要求前后SELECT语句的列数一致。我们使用ORDER BY子句来猜测。

将Cookieid的值改为1‘ order by 1 --。页面正常。
改为1‘ order by 2 --。页面正常。
改为1‘ order by 3 --。如果此时页面报错或异常，说明原查询结果只有2列。因为order by 3意味着按第3列排序，而查询结果没有第3列，所以出错。我们不断递增数字，直到找到那个出错的临界点。

第三步：确定回显点知道有2列后，我们用UNION SELECT来探测哪一列的内容会显示在页面上。

将Cookieid的值改为-1‘ union select 1,2 --。
- 这里id=-1确保原查询不返回结果（因为通常没有id为负的文章），这样页面就会完整显示我们UNION查询的结果。
- 如果页面某处显示了数字“1”和“2”，就说明这两列都是回显点。可能只显示其中一个数字，记下显示的位置和对应的列序号。

第四步：信息收集与数据窃取现在，我们可以把回显点上的数字，替换成我们想查询的数据库函数或语句。

查询基础信息：假设第2列是回显点。将Payload改为：-1‘ union select 1, database() --页面会显示当前数据库名。同理，可以查询user()（当前数据库用户）、version()（数据库版本）。这些信息对后续选择利用方式至关重要（例如，不同数据库的语法和系统表名不同）。
查询表名：以MySQL为例，信息存储在information_schema数据库中。-1‘ union select 1, group_concat(table_name) from information_schema.tables where table_schema=database() --group_concat()函数会将所有结果合并成一行，方便查看。执行后，页面会显示当前数据库下的所有表名，比如users,articles,config。
查询列名：假设我们对users表感兴趣。-1‘ union select 1, group_concat(column_name) from information_schema.columns where table_schema=database() and table_name=‘users‘ --页面会显示users表的所有列，如id,username,password,email。
最终拖库：获取想要的列数据。-1‘ union select 1, concat(username, ‘:‘, password) from users --这样就能把用户名和密码（可能是哈希值）一起显示出来。

注意事项：在整个手工注入过程中，要密切注意URL编码问题。Cookie值在HTTP请求头中传输，空格、单引号、井号等特殊字符可能需要编码。例如，空格在Cookie中有时需要编码为%20或+，而--后面的空格是必须的。浏览器的开发者工具在修改Cookie时通常会帮你处理，但如果使用命令行工具（如cURL）进行测试，就必须手动处理编码。

4. 自动化工具利用与高级绕过技巧

手工注入能让我们透彻理解原理，但效率太低，尤其是在盲注场景下。在实际渗透测试中，SQLMap这样的自动化工具是必备神器。但工具不是万能的，面对一些简单的过滤，它可能“死”得很直接。这时就需要我们手动干预，或者使用工具的高级特性。

4.1 SQLMap基础使用：效率倍增器

还是针对我们假设的vuln.php，它通过Cookieid传参。用SQLMap检测非常简单：

sqlmap -u “http://your-target/vuln.php“ --cookie=“id=1“ --level=2

-u: 指定目标URL。
--cookie: 指定Cookie，工具会识别其中的参数进行测试。
--level=2: 提高测试等级，会检测Cookie注入（等级1默认不检测Cookie）。

如果检测到注入，SQLMap会询问你是否要进一步探测。你可以：

枚举所有数据库：--dbs
枚举当前数据库的所有表：--tables
枚举指定表的所有列：-D database_name -T table_name --columns
导出表数据：-D database_name -T table_name -C “username,password“ --dump

SQLMap的“智能”之处在于它能自动识别数据库类型、注入类型（布尔盲注、时间盲注等），并采用相应的Payload。对于时间盲注，它会像“挤牙膏”一样，通过响应时间的差异一点点猜出数据，这个过程虽然慢，但完全自动化。

4.2 常见WAF绕过手法实录

当靶场安全等级调到“Medium”或“High”，或者遇到真实的WAF时，简单的‘和UNION可能立刻被拦截。这时就需要一些“花招”。

1. 大小写/关键字混淆

原理：简单的WAF可能只匹配大写或小写关键字。
Payload示例：UnIoN SeLeCt 1,2或uNiOn sElEcT 1,2
SQLMap参数：--tamper=randomcase.py(SQLMap内置的脚本，随机化大小写)

2. 等价函数/语句替换

原理：用功能相同的其他函数或语法替换被拦截的关键字。
示例：
- 空格被过滤：用/**/（注释符）、%0a（换行符）、%0d（回车符）、%09（制表符）代替。
- and被过滤：用&&代替（MySQL中）。
- or被过滤：用||代替。
- =‘value‘被过滤：用like ‘value%‘或in (‘value‘)代替。
- union select被过滤：尝试union all select。

3. 编码与双重编码

原理：WAF可能只解码一次，而应用服务器会解码两次。
示例：将单引号‘进行URL编码一次是%27，编码两次是%2527（因为%的编码是%25）。如果WAF只检查%27，那么%2527传到服务器端解码两次后，又变回了‘，成功绕过。
SQLMap参数：可以尝试结合--hex或--tamper脚本进行编码。

4. 注释符分割

原理：用注释符将关键字拆散，干扰WAF的正则匹配。
Payload示例：UNI/**/ON SEL/**/ECT 1,2。对于数据库，/**/是注释，会被忽略，所以实际执行还是UNION SELECT 1,2。

5. 缓冲区溢出（古老但特定环境有效）

原理：一些古老的WAF或应用对超长字符串处理不当，可能导致检测逻辑被绕过。但现代系统已很少见。

实操心得：面对WAF，最好的方法是“探针测试”。先发送一个极其简单的测试Payload（如id=1‘），观察拦截页面或响应码。然后逐步增加复杂度，比如加注释、编码、拆分，看哪种方式能“溜过去”。SQLMap的--tamper参数集成了很多这类脚本（如space2comment.py,between.py），可以自动尝试多种绕过方式。但切记，自动化工具动静大，在真实授权测试中，应谨慎使用--level和--risk参数，避免对生产数据库造成过大压力或触发警报。

5. 从攻击到防御：安全开发实践指南

站在攻击者的角度搞明白了漏洞如何产生，我们才能更好地构建防御。防御SQL注入，尤其是Cookie注入这类隐蔽变种，必须建立纵深防御体系。

5.1 根本解决方案：参数化查询（预编译语句）

这是唯一被公认为能从根本上杜绝SQL注入的方法。它的原理是将SQL语句的结构（模板）与数据（参数）分开发送至数据库服务器。数据库先编译语句结构，再将参数作为纯数据处理，无论参数内容是什么，都无法改变语句的语义。

PHP (PDO) 示例：

$stmt = $pdo->prepare(“SELECT * FROM articles WHERE id = :id“); $stmt->execute([‘id‘ => $_COOKIE[‘id‘]]); // 安全！即使id包含‘ or ‘1‘=‘1，也会被当作普通字符串 $results = $stmt->fetchAll();

Python (SQLAlchemy) 示例：

from sqlalchemy import text stmt = text(“SELECT * FROM articles WHERE id = :id“) result = connection.execute(stmt, {‘id‘: request.cookies.get(‘id‘)})

重要提示：不要使用字符串拼接（如f“...{var}...”或“...“ + var + “...”）来构造SQL语句，无论你之前对变量做了多少重过滤和转义。参数化查询是黄金准则。

5.2 输入验证与过滤：必要的补充防线

虽然不能单独依赖，但作为辅助手段至关重要。

白名单验证：对于已知有限集合的值（如状态码、类型），严格限定输入范围。

$allowed_themes = [‘light‘, ‘dark‘, ‘blue‘]; $theme = $_COOKIE[‘theme‘]; if (!in_array($theme, $allowed_themes)) { $theme = ‘light‘; // 赋予默认安全值 }

类型强制转换：对于数字型的Cookie值，直接转换为整数。

$id = (int) $_COOKIE[‘id‘]; // 非数字会变成0 if ($id <= 0) { die(‘Invalid ID‘); }

最小权限原则：用于连接数据库的账户，不应具有DROP、FILE、GRANT等高级权限。通常只赋予SELECT、INSERT、UPDATE、DELETE等必要权限。

5.3 针对Cookie的专项安全加固

HttpOnly标志：设置Cookie时添加HttpOnly属性，可以阻止JavaScript通过document.cookie访问该Cookie。这能有效防御XSS攻击窃取Cookie，但对于直接修改HTTP请求头的攻击（如我们本次实验）无效。
签名与加密：对于存储在Cookie中的敏感数据（如用户ID），不要明文存储。可以采用“签名”方式（如HMAC），服务器端验证Cookie值的完整性；或对值进行加密（如AES），确保客户端无法篡改或理解其内容。
不要信任任何客户端数据：这是安全开发的铁律。无论是GET、POST、还是COOKIE，都应视为不可信的。所有用于数据库查询、系统命令、文件路径的数据，都必须经过严格的验证、过滤或使用安全的API（如参数化查询）。

5.4 漏洞排查与应急响应

即使代码写好了，定期审计和监控也必不可少。

代码审计：使用自动化工具（如SonarQube、Fortify SCA）扫描源代码，查找潜在的SQL拼接点。但工具会有误报和漏报，最终需要人工复审。
Web应用防火墙 (WAF)：部署WAF可以在网络层拦截常见的攻击模式，为修复漏洞争取时间。但WAF是“治标”，不能替代安全的代码（“治本”）。
入侵检测与日志分析：确保数据库的审计日志和Web服务器的访问日志被完整记录，并集中到一个安全的位置进行分析。监控异常的SQL语句模式（如大量出现UNION、SELECT系统表）或来自单一IP的高频错误请求。

最后，我个人在多年的渗透测试和代码审计中最大的体会是：安全是一个持续的过程，而不是一个可以一劳永逸的状态。Cookie注入这类漏洞之所以长期存在，根源在于开发阶段对“数据源”的狭隘认知。把“所有用户输入皆不可信”这句话刻在脑子里，并在每一个从请求到数据库的路径上，都严格践行参数化查询，这才是构筑应用安全防线的基石。在下次你编写从Cookie中读取数据的代码时，不妨先停一秒，问问自己：“这里，我信任它了吗？”

查看全文

http://www.cnnetsun.cn/news/3043742.html