1. 项目概述从“登录框”到“数据金库”的隐秘通道做安全测试这些年我越来越觉得那些最危险的漏洞往往不是摆在明面上的。比如一个看似平平无奇的登录框或者一个记录你浏览偏好的小文件都可能成为攻击者撬开整个系统大门的支点。今天要聊的“Cookie注入”和“SQL注入”就是这类“四两拨千斤”的典型。很多人一听到SQL注入脑子里立马蹦出在登录框里输入‘ or ‘1’’1的场景这没错但那是“显山露水”的字符型注入。而Cookie注入则更像一个潜伏在暗处的“影子刺客”它利用的是Web应用在处理用户身份标识Cookie时的不严谨将恶意代码悄无声息地“夹带”进数据库查询中。这个实验报告就是一次对这种隐秘攻击手法的深度复盘。它不仅仅是记录一次成功的漏洞利用更是要拆解清楚为什么一个本该用于维持会话状态的小小Cookie会成为致命的安全短板攻击者是如何绕过前端的所有防护直接与后端数据库“对话”的我们通过搭建靶场环境比如经典的DVWA或Pikachu模拟攻击者的视角从信息探测、漏洞判断、Payload构造到最终的数据窃取或系统控制完整地走一遍攻击链。同时我也会对比手工注入与自动化工具如SQLMap的优劣分享在实战中如何根据不同的WAFWeb应用防火墙规则进行绕过。无论你是刚入门CTFCapture 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;如果攻击者传入id1 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. 实验环境搭建与手工注入实战理论说再多不如亲手试一次。我们选择一个经典且可控的环境——DVWADamn Vulnerable Web Application作为靶场。它集成了多种漏洞安全等级可调非常适合学习。3.1 靶场环境部署与配置我习惯在本地用PHPStudy或Docker快速搭建一个LAMPLinuxApacheMySQLPHP环境。将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 12如果正常内容消失则说明注入存在。第二步判断字段数为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_schemadatabase() --group_concat()函数会将所有结果合并成一行方便查看。执行后页面会显示当前数据库下的所有表名比如users,articles,config。查询列名假设我们对users表感兴趣。-1‘ union select 1, group_concat(column_name) from information_schema.columns where table_schemadatabase() 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“id1“ --level2-u: 指定目标URL。--cookie: 指定Cookie工具会识别其中的参数进行测试。--level2: 提高测试等级会检测Cookie注入等级1默认不检测Cookie。如果检测到注入SQLMap会询问你是否要进一步探测。你可以枚举所有数据库--dbs枚举当前数据库的所有表--tables枚举指定表的所有列-D database_name -T table_name --columns导出表数据-D database_name -T table_name -C “username,password“ --dumpSQLMap的“智能”之处在于它能自动识别数据库类型、注入类型布尔盲注、时间盲注等并采用相应的Payload。对于时间盲注它会像“挤牙膏”一样通过响应时间的差异一点点猜出数据这个过程虽然慢但完全自动化。4.2 常见WAF绕过手法实录当靶场安全等级调到“Medium”或“High”或者遇到真实的WAF时简单的‘和UNION可能立刻被拦截。这时就需要一些“花招”。1. 大小写/关键字混淆原理简单的WAF可能只匹配大写或小写关键字。Payload示例UnIoN SeLeCt 1,2或uNiOn sElEcT 1,2SQLMap参数--tamperrandomcase.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如id1‘观察拦截页面或响应码。然后逐步增加复杂度比如加注释、编码、拆分看哪种方式能“溜过去”。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中读取数据的代码时不妨先停一秒问问自己“这里我信任它了吗”