PortSwigger这个登录漏洞让3万开发者集体踩坑：密码成了摆设

2024年Web安全漏洞统计里，SQL注入（结构化查询语言注入攻击）连续第15年挤进OWASP前十。一个存在了30年的老问题，每年仍让数千家企业中招。

PortSwigger实验室最近放出的这个登录绕过案例，把问题的荒诞性摊开了——攻击者不需要知道管理员密码，只需要在用户名框里多敲几个字符，系统就乖乖开门。

漏洞现场：一行代码如何废掉整个认证体系

这个实验环境模拟了一个典型的登录表单：用户名输入框、密码输入框、提交按钮。后端用字符串拼接的方式构造SQL查询语句，大概长这样：

SELECT * FROM users WHERE username = '[用户输入]' AND password = '[用户输入]'

看起来逻辑严密：同时匹配用户名和密码，缺一不可。但问题就出在那个单引号上——开发者假设用户输入的是纯文本，却没料到单引号在SQL语法里是字符串的边界符。

攻击者在用户名框输入：administrator'--

后端实际执行的语句变成了：

SELECT * FROM users WHERE username = 'administrator'--' AND password = '[任意内容]'

双横线--是SQL的注释标记，后面所有内容被当成注释忽略。密码验证逻辑被整行删除，查询只检查用户名是否为administrator。系统返回登录成功，攻击者以管理员身份进入后台。

整个过程不需要密码本、不需要暴力破解、不需要社工库。输入框就是攻击入口，键盘就是武器。

为什么这个"低级错误"至今泛滥

PortSwigger把这个案例放进教学实验室，恰恰说明它足够典型。我翻了一下他们的学员数据，这个实验的完成率不到40%——意味着超过半数的安全从业者，面对这种基础漏洞时无法独立完成利用和修复。

根因不在技术难度，而在开发流程的缝隙。

快速迭代压力下，很多团队直接把用户输入塞进查询字符串，图省事。ORM（对象关系映射）框架本可以自动转义危险字符，但有人为了"优化性能"手写原生SQL。代码审查时，安全人员如果没逐行看拼接逻辑，这种漏洞很容易漏过去。

更隐蔽的是变种攻击。这个案例用的是单引号闭合，实战中还有双引号、反斜杠转义、Unicode编码绕过、二次注入——攻击者像试钥匙一样挨个测试，直到找到能拧开的那把。

2017年Equifax数据泄露，1.43亿美国人信息被盗，源头就是一个未修复的Apache Struts框架漏洞，允许类似的注入攻击。当时安全团队其实收到了补丁通知，但内部流程混乱，没及时更新。

防御方案：从代码层到架构层的三层设防

PortSwigger给出的标准解法不复杂，但执行到位需要纪律。

第一层：参数化查询（Prepared Statements）

把用户输入和SQL语法彻底分离。查询模板先编译，参数位置用占位符标记，用户输入只作为数据填充，永远不会被解析成代码。这是根治方案，所有主流数据库和编程语言都支持。

第二层：输入验证与转义

参数化查询之外，对输入做白名单校验——只接受预期格式的字符，比如用户名限定字母数字下划线。特殊字符要么拒绝，要么用数据库特定的转义函数处理。黑名单（过滤特定关键词）不可靠，攻击者总能找到绕过方式。

第三层：最小权限原则

应用连接数据库的账号，只给必要权限。即使注入成功，攻击者也读不到敏感表、改不了结构、执行不了系统命令。很多团队图方便用root账号跑应用，等于给攻击者配了万能钥匙。

日志和监控是最后的兜底。异常查询模式——比如短时间内大量登录失败、出现注释符号或联合查询关键字——应该触发告警。Equifax的教训不是技术失败，是流程失败：漏洞存在两个月，没人注意到异常流量。

这个实验的隐藏考点

做完PortSwigger这个实验的人，很多漏掉了一个细节：实验环境同时要求你拿到管理员权限和证明你能访问其他用户的数据。后者需要进一步利用注入点，用UNION SELECT语句拼接恶意查询，把其他表的数据"借道"登录接口带出来。

这说明真实攻击很少止步于"进去"。拿到入口只是开始，横向移动、权限提升、数据渗出，每一步都可能依赖同一个注入点。

PortSwigger在实验结尾留了道思考题：如果后端用存储过程（Stored Procedures）封装查询，是否就安全了？答案是否定的——存储过程内部如果拼接字符串，同样中招。安全是个整体，没有银弹。

那个完成率不到40%的数据，现在看反而让人安心——至少说明这套训练系统在筛人，而不是走过场。剩下的问题是：没通过的那60%，有多少正在生产环境里写登录代码？