任意密码登录漏洞

登录框里输入 admin' or 任意'1'='1，密码随便填，密码回车——进去了。登录这不是漏洞电影桥段，是任意我上周在一个客户的后台系统里真实碰到的事。更离谱的密码是，这套系统还在对外提供服务，登录日活用户大概两千多。漏洞

任意密码登录，任意说白了就是密码验证逻辑写废了。开发人员可能想省事，登录SQL 查询拼字符串的漏洞时候没做转义，攻击者构造一个恒真条件，任意数据库就把整张用户表的密码第一条记录返回给你。你以为自己在登录，登录其实数据库在说：“行吧，你说啥就是啥。”

我见过最粗糙的实现是这样的：后端拿用户名和密码直接拼成 SELECT * FROM users WHERE username='$user' AND password='$pass'，然后判断结果集是否为空。空就是登录失败，非空就是成功。问题在于，$user 如果是 admin'--，后面的密码判断直接被注释掉了。用户名对了，密码是什么根本不重要。

还有一种更隐蔽的写法，验证逻辑放在前端。我抓过一个 App 的包，登录请求发出去，服务端返回一个 { "code": 200, "msg": "success"}，然后客户端根据这个 code 决定跳不跳转。但服务端压根没校验密码，只要用户名存在就返回 200。抓包改一下响应，或者直接构造请求，随便什么密码都能进。

这类漏洞在中小型项目里特别常见。原因不复杂：开发周期短，安全测试基本没有，代码 review 走个过场。有的团队甚至觉得“我们系统又不出名，谁闲着没事来搞我们”。可现实是，扫描器全天候在跑，你的 IP 在公网上，被扫到只是时间问题。

去年有个做电商的朋友找我，说后台被人改了商品价格，一块钱买走了十几部手机。我上去一看，登录接口就是典型的万能密码漏洞。攻击者用 ' or 1=1-- 登进去，发现是管理员权限，直接改了价格。朋友问我怎么防，我说先把 SQL 参数化查询加上，再把登录失败次数限制做了，最后把后台 IP 白名单配上。他照做之后，消停了。

修复这件事，其实不复杂。预编译语句能挡住绝大多数注入，密码哈希存储能防止拖库后直接拿到明文，登录失败锁定能拖慢暴力破解。但这些都是开发规范层面的东西，靠的是写代码的人有没有这个意识。我见过太多项目，功能跑通了就上线，安全是“以后再说”的事。

还有个细节值得提：有些系统用了 ORM 框架，觉得万事大吉。但如果你在 ORM 里写原生 SQL 拼接，或者用 whereRaw 这类方法，照样中招。框架不背这个锅，写代码的人得背。

最后说个我自己的习惯。每次拿到一个新系统，第一件事就是拿 ' or '1'='1 和 admin'-- 在登录框里试一下。十次里有两次能进去。这个比例，说实话，有点高。

本文地址：http://www.79wt.cn/news/1119e9599793.html