从实战到防御：BUUCTF Ezsql 加固靶场深度解析
1. 初识BUUCTF Ezsql靶场：从登录框到万能密码
第一次接触BUUCTF的Ezsql靶场时，那个看似普通的登录界面让我差点以为走错了片场。但当我尝试用经典的admin' or 1=1#作为用户名，随便输入密码后点击登录，页面竟然跳出了"登录成功"的提示——这感觉就像用万能钥匙打开了防盗门，暴露出最典型的SQL注入漏洞。
这个登录框背后是典型的动态SQL拼接问题。通过查看源码可以看到，开发者直接将用户输入的username和password拼接到SQL查询语句中：
$sql = "SELECT * FROM users WHERE username = '$username' AND password = '$password'";当输入admin' or 1=1#时，实际执行的SQL语句变成了：
SELECT * FROM users WHERE username = 'admin' or 1=1#' AND password = '任意密码'这里的#将后续语句注释掉，而or 1=1使条件永远为真，这就是所谓的"万能密码"攻击。我在本地测试时发现，类似的payload还有' or ''='、admin'--等变种，都能轻松绕过认证。
2. 漏洞代码深度解剖：为什么会被注入？
打开靶机的index.php文件，可以看到整个认证流程只有不到20行代码，却包含了三个致命问题：
首先是没有对输入进行任何过滤处理。$_GET参数直接拼接到SQL语句，这相当于把数据库大门敞开。我曾在实际项目中见过类似案例，某电商网站就因为这样的漏洞导致用户数据泄露。
其次是错误处理方式不当。虽然代码用error_reporting(0)关闭了错误显示，但die(mysqli_error($mysqli))的写法反而可能泄露数据库结构信息。有次我用'作为用户名尝试时，页面直接返回了MySQL语法错误详情。
最后是使用了不安全的查询方法。$mysqli->query()直接执行动态SQL，比预处理语句的风险高得多。记得去年审计某CMS系统时，就是因为这种写法导致全线沦陷。
3. 加固方案实战：从addslashes到预处理语句
3.1 快速修复方案：addslashes函数
最简单的加固方法就是使用addslashes函数对输入进行转义：
$username = addslashes($_GET['username']); $password = addslashes($_GET['password']);这个函数会在特殊字符（单引号、双引号、反斜杠和NULL）前添加反斜杠。测试时我发现，原先的admin' or 1=1#会被转义为admin\' or 1=1#，使SQL语句保持完整。
但这种方法有三个局限：
- 对数字型注入无效
- 依赖数据库连接的字符集设置
- 二次注入风险仍然存在
3.2 进阶方案：参数化查询
更专业的做法是使用预处理语句。修改后的代码应该是：
$stmt = $mysqli->prepare("SELECT * FROM users WHERE username=? AND password=?"); $stmt->bind_param("ss", $username, $password); $stmt->execute();我在本地测试时，即使用admin' or 1=1#尝试，系统也会严格将其作为普通字符串处理。这种方案就像给SQL语句和参数设置了专用通道，完全避免拼接带来的混肴。
3.3 防御升级：多层防护策略
在实际项目中，我通常会采用组合防御：
- 输入验证：检查用户名是否符合预期格式（如长度、字符类型）
- 预处理语句：确保SQL结构固定
- 最小权限原则：数据库用户只赋予必要权限
- 错误处理：自定义错误信息避免泄露细节
4. 验证与反思：构建完整安全闭环
完成加固后，我重新测试了各种攻击向量：
- 万能密码攻击：失效
- 布尔盲注：无法判断条件真假
- 时间盲注：响应时间恒定
- 联合查询：返回语法错误
通过Check服务的验证后，成功获取到flag。这个过程让我想起去年修复的一个生产环境漏洞——当时客户坚持认为"我们的系统很简单不会有问题"，直到我现场演示了数据导出才引起重视。
在安全领域，没有"简单的系统"，只有未被发现的漏洞。每次CTF挑战都是对实战能力的锤炼，而像Ezsql这样的靶场，正是从理论到实践的最佳桥梁。