CTF实战：从SQL注入原理到手工与自动化漏洞利用

1. 靶场环境与目标分析拿到这道题第一反应是看题目名字和描述。[极客大挑战 2019]LoveSQL 1典型的CTF Web题目命名风格结合“LoveSQL”这个关键词几乎可以断定核心考点是SQL注入。这类题目通常模拟一个存在漏洞的Web应用我们的目标就是利用这个漏洞从数据库中获取到隐藏的Flag。首先我们需要访问题目提供的环境。通常这类在线靶场会给出一个URL。假设我们拿到的地址是http://challenge-ip:port/。打开后呈现的很可能是一个简单的登录页面或者是一个信息查询页面页面上可能会有“搜索用户”、“登录”、“查看详情”等交互功能。作为解题者我们的任务不是正常使用这个功能而是“攻击”它测试其是否存在SQL注入漏洞并利用漏洞逐步深入数据库最终找到存储Flag的表和字段。在开始“盲注”之前我们需要对目标进行基础信息收集。这包括前端观察查看网页源代码寻找注释、隐藏表单、JS文件中的线索。HTTP响应头查看服务器返回的Server、X-Powered-By等字段初步判断后端技术栈如Apache/Nginx, PHP/Python。参数探测找到所有可能与后端数据库交互的输入点如?id1中的id登录表单中的username和password。根据网络热词中频繁出现的“MariaDB”我们可以合理推测这个靶场后端数据库是MariaDBMySQL的一个流行分支。这很重要因为不同数据库如MySQL、PostgreSQL、SQL Server的注入语法、系统函数和元数据库结构会有差异。确认数据库类型能让我们使用正确的Payload。注意在实际CTF或渗透测试中信息收集是第一步也是至关重要的一步。它决定了后续攻击链的构建是否精准有效。不要一上来就扔万能密码先搞清楚目标是什么。2. SQL注入漏洞原理与类型判断SQL注入之所以发生根本原因在于程序将用户输入的数据直接“拼接”到了SQL查询语句中而没有进行充分的过滤或使用安全的参数化查询。例如一个简单的登录查询可能是这样的SELECT * FROM users WHERE username ‘$username’ AND password ‘$password’如果用户输入的username是admin’ --那么拼接后的SQL语句就变成了SELECT * FROM users WHERE username ‘admin’ -- ’ AND password ‘$password’在SQL中--是注释符它会将其后的所有内容注释掉。于是这个查询就变成了“查找用户名为admin的用户”完全绕过了密码验证。这就是经典的“万能密码”绕过原理。对于这道题我们需要判断注入点的类型。常见的类型有数字型注入参数直接被用作数字如?id1。测试方法输入1 and 11和1 and 12观察页面返回是否不同。字符型注入参数被引号包裹如?nameadmin。测试方法输入admin’ and ‘1’’1和admin’ and ‘1’’2或使用admin’尝试触发语法错误。搜索型注入参数用于LIKE语句通常涉及%和_通配符。POST注入注入点在POST请求的Body中如表单提交的username和password。根据“LoveSQL”这个温馨的名字以及常见的出题套路注入点很可能在登录框的username或password字段或者是一个用户查询框。我们首先尝试最经典的Payload进行快速探测。在用户名或查询框输入‘ or 11 --或者它的变种‘ or ‘1’’1‘ --如果页面逻辑是“查询用户是否存在”那么11这个永真条件会导致查询返回所有用户数据可能表现为登录成功、显示所有用户列表或页面内容发生显著变化。如果输入‘ or 12 --页面返回异常或为空则进一步证实了注入漏洞的存在。这一步我们不仅验证漏洞也在确认注入的类型是字符型并且注释符--后面通常需要跟一个空格生效。实操心得在测试时浏览器的开发者工具F12中的“网络(Network)”标签页是我们的好朋友。提交Payload后在这里可以看到完整的HTTP请求和响应有时后端错误信息会直接返回在响应里这能提供数据库类型、SQL语句结构等宝贵信息。如果页面是JavaScript动态加载的也要注意查看XHR请求。3. 手工注入流程从信息获取到数据提取确认存在字符型注入并可以注释后续语句后我们就可以开始系统性的手工注入攻击了。这个过程就像侦探破案一步步从数据库里套取信息。手工注入能让我们更深刻地理解漏洞原理也是自动化工具无法完全替代的。3.1 确定字段数ORDER BY在联合查询UNION之前我们必须知道当前查询语句返回的字段数量。我们使用ORDER BY子句来探测。ORDER BY用于对结果集按指定列排序。ORDER BY 1表示按第一列排序ORDER BY 2按第二列以此类推。如果指定的列号超过了实际列数数据库就会报错。我们在注入点输入‘ ORDER BY 1 -- ‘ ORDER BY 2 -- ‘ ORDER BY 3 -- ‘ ORDER BY 4 -- ...当页面正常返回时说明这个列号存在。当页面返回错误可能是SQL错误也可能是页面布局崩坏或空白时说明列号超出了范围。假设ORDER BY 3正常ORDER BY 4报错那么字段数就是3。3.2 探测回显点UNION SELECT知道字段数后我们就可以使用UNION SELECT进行联合查询。UNION操作符用于合并两个或多个SELECT语句的结果集前提是每个SELECT语句必须拥有相同数量的列且列的数据类型相似。我们的目标是让数据库执行我们自定义的查询并将结果“回显”在页面上。我们需要找到页面上哪个位置显示了数据库查询的结果。通常页面上的用户名、邮箱、描述等信息可能就是查询结果的回显位置。我们构造这样的Payload‘ UNION SELECT 1,2,3 --如果注入成功且页面有回显我们可能会在页面的某些位置看到数字“1”、“2”、“3”被显示出来。假设数字“2”和“3”显示在了页面的显眼位置那么这两个位置就是我们后续注入数据可以“冒出来”的地方我们称之为“回显点”。3.3 获取数据库信息现在我们可以把回显点比如第2、3列替换成我们想要查询的数据库函数。第一步查当前数据库名MariaDB/MySQL中database()函数返回当前使用的数据库名。‘ UNION SELECT 1, database(), 3 --假设返回了geek。第二步查数据库版本和用户‘ UNION SELECT 1, version(), user() --这能帮助我们确认数据库版本如10.3.39-MariaDB和当前连接的用户为后续可能的提权或利用做准备。第三步查所有数据库名在MySQL中有一个名为information_schema的系统数据库它存储了所有其他数据库的元数据如表、列信息。SCHEMATA表里存放了所有数据库的名字。‘ UNION SELECT 1, group_concat(schema_name), 3 FROM information_schema.schemata --group_concat()函数非常有用它能把多行查询结果合并成一个字符串用逗号分隔方便我们一次性查看。执行后我们可能会看到类似information_schema,geek,mysql,performance_schema的结果。其中geek很可能就是我们的目标数据库。3.4 获取表名和列名现在我们深入geek数据库。第一步查geek数据库中的所有表名表信息存储在information_schema.tables中。‘ UNION SELECT 1, group_concat(table_name), 3 FROM information_schema.tables WHERE table_schema‘geek’ --假设返回了geekuser, l0ve1ysq1。geekuser看起来像用户表而l0ve1ysq1这个表名非常可疑很可能就是存放Flag的表CTF题目经常用这种看起来像乱码或彩蛋的名字。第二步查l0ve1ysq1表的所有列名列信息存储在information_schema.columns中。‘ UNION SELECT 1, group_concat(column_name), 3 FROM information_schema.columns WHERE table_schema‘geek’ AND table_name‘l0ve1ysq1’ --假设返回了id, username, password。这里password字段很可能存储的就是Flag或者Flag就藏在某条记录的password值里。3.5 最终提取Flag最后一步查询目标表中的数据。‘ UNION SELECT 1, username, password FROM l0ve1ysq1 --或者如果我们只关心password列‘ UNION SELECT 1, 2, password FROM l0ve1ysq1 --又或者使用group_concat一次性查看所有password‘ UNION SELECT 1, 2, group_concat(password) FROM l0ve1ysq1 --执行后我们很可能在页面的回显位置看到一串由数字和字母组成的、格式符合该CTF平台要求的字符串例如flag{xxxx-xxxx-xxxx-xxxx}或ctfshow{xxxxxxxx}这就是我们要找的Flag。注意事项在实际操作中可能会遇到一些“小麻烦”。比如页面可能只回显查询结果的第一行。这时我们可以用LIMIT子句来逐行查看。例如‘ UNION SELECT 1, username, password FROM l0ve1ysq1 LIMIT 0,1 --查看第一行LIMIT 1,1查看第二行以此类推。另外如果单引号被过滤可以尝试使用十六进制编码如0x6765656b表示geek或使用CHAR()函数来绕过。4. 工具辅助与自动化注入思路虽然手工注入是理解原理的根本但在时间紧张的CTF比赛或复杂的实战中使用工具可以极大提升效率。最著名的SQL注入工具非sqlmap莫属。它是一个开源的渗透测试工具可以自动检测和利用SQL注入漏洞。对于这道题如果我们已经找到了注入点比如是/check.php?usernamexxx并且确认是字符型注入我们可以使用sqlmap进行快速攻击。基本的使用命令如下sqlmap -u “http://challenge-ip:port/check.php?usernameadmin” --batch-u指定目标URL。--batch以非交互模式运行所有提示都选择默认选项。sqlmap会自动进行以下工作检测注入使用各种Payload测试参数是否存在注入点并判断注入类型、数据库类型。枚举信息一旦确认注入可以枚举当前数据库名、所有数据库名、当前用户等。枚举表名指定数据库如-D geek来枚举其中的所有表。枚举列名指定数据库和表如-D geek -T l0ve1ysq1来枚举表中的所有列。dump数据指定数据库、表和列如-D geek -T l0ve1ysq1 -C password来导出数据。例如一条命令直接获取geek数据库下l0ve1ysq1表的所有数据sqlmap -u “http://challenge-ip:port/check.php?usernameadmin” -D geek -T l0ve1ysq1 --dump --batch踩坑记录sqlmap虽然强大但并非万能。在以下情况需要特别注意WAF/过滤靶场可能设置了简单的过滤规则sqlmap的默认Payload可能被拦截。这时需要调整级别--level、风险--risk或使用--tamper参数加载脚本对Payload进行混淆如space2commentrandomcase。Cookie/Session如果目标需要登录可能需要使用--cookie参数附上你的会话Cookie。POST请求对于POST注入需要使用--data参数指定POST数据如--data“usernameadminpasswordtest”。延迟与线程为了避免被靶场的防护机制封IP或对靶场造成过大压力可以适当增加延迟--delay1或减少线程--threads1。结果解读sqlmap的输出信息量很大要重点关注[INFO]和[CRITICAL]级别的日志它们包含了注入是否成功、获取到的关键数据等信息。5. 防御措施与安全编程思考作为开发者了解攻击手段是为了更好地防御。SQL注入的防御核心原则是永远不要信任用户输入对输入进行严格的校验和过滤并使用安全的数据库访问方式。1. 使用参数化查询预编译语句这是最有效、最根本的防御手段。参数化查询将SQL语句的结构命令与数据参数分开发送给数据库。数据库会先编译SQL结构再将参数作为纯粹的数据来处理即使参数中包含SQL元字符如单引号也只会被当作数据内容而不会被解释为SQL指令。以PHP的PDO为例$stmt $pdo-prepare(“SELECT * FROM users WHERE username :username AND password :password”); $stmt-execute([‘:username’ $username, ‘:password’ $password]); $user $stmt-fetch();这样无论$username输入什么‘ or 11 --它都只会被当作查找的用户名字符串而不会改变SELECT语句的语义。2. 对输入进行严格的校验和过滤白名单校验对于已知有限集合的输入如性别、状态只接受预定义的值。类型转换对于数字型参数在拼接SQL前强制转换为整数型如$id (int)$_GET[‘id’];。转义特殊字符如果因历史原因必须使用字符串拼接务必使用数据库驱动提供的专用转义函数如MySQL的mysqli_real_escape_string()。但请注意这不是绝对安全的且依赖于数据库字符集。3. 最小权限原则为Web应用连接数据库的账户分配最小必要的权限。通常只授予其SELECT、INSERT、UPDATE、DELETE等业务必需权限绝不授予DROP、CREATE DATABASE、FILE、PROCESS等高危权限。这样即使发生注入攻击者能造成的破坏也有限。4. 避免直接显示错误信息将生产环境的PHP错误显示关闭display_errors Off或使用自定义的错误页面。防止数据库错误信息包含表名、字段名、SQL语句片段直接泄露给攻击者这相当于给了他们一张“地图”。5. 使用Web应用防火墙WAF在应用前端部署WAF可以识别并拦截常见的SQL注入攻击模式作为一道额外的防线。但WAF可能存在绕过风险不能替代安全的代码编写。通过解这道“LoveSQL”题目我们完整地走通了一次基于联合查询的字符型SQL注入攻击链。从最初的漏洞探测、信息收集到手工一步步获取数据库、表、列信息最终提取Flag每一个步骤都紧密关联着数据库的基本原理。理解这个过程不仅能帮助我们在CTF中解题更重要的是让我们以攻击者的视角审视自身代码的安全性从而写出更健壮、更安全的程序。安全是一个持续的过程而非一劳永逸的状态。