登录框渗透

我盯着那个登录框看了十分钟，登录它干干净净地站在页面中央，框渗只有一个用户名输入位、登录一个密码输入位，框渗外加一枚蓝色的登录“Sign in”按钮。这种极简设计往往藏着最不极简的框渗后端逻辑——开发者的自信常写在脸上，而漏洞就埋在他们懒得加注释的登录那几行代码里。

先试弱口令是框渗种礼貌。admin/admin，登录admin/123456，框渗test/test。登录服务器回了三次“Invalid credentials”，框渗第四次直接给我来了个429限流。登录这倒是框渗个信号——他们做了基础防护，但限流阈值设得那么高，登录明显是怕影响正常用户体验。我换了个IP池，开始用密码喷洒，拿“spring”“welcome”“company名+年份”这种组合去撞。第七轮的时候，一个老账号居然用“Welcome@2023”进来了。这种密码像生日蛋糕上的蜡烛，看着喜庆，吹一口就灭。

但真正的乐趣在绕过逻辑。我退回登录页，把用户名改成admin' OR '1'='1，密码随便填。页面没报错，也没放行，但响应时间比正常请求慢了1.2秒。这个延迟暴露了SQL拼接的存在——数据库在尝试解析我的引号，然后被WAF拦了。WAF不是墙，是滤网，总有些颗粒能穿过去。我换成admin'-- -，加个注释符试试，这次服务器直接回了302跳转，跳到了后台面板。

进去之后才发现，真正脆弱的不是登录框本身，而是“记住我”这个功能。它的token是一串Base64编码的用户ID+时间戳，没有签名。我把自己账号的token解出来，把用户ID改成1，重新编码放回Cookie里，刷新页面——管理员身份到手。整个过程没碰密码，没碰验证码，就改了个数字。

这类问题太常见了。很多团队把安全预算全砸在登录框的验证码、双因素、复杂密码策略上，却忘了登录框后面的会话管理、token生成、权限校验才是命门。攻击者根本不需要撬锁，他们只需要找到那把没换锁芯的后门钥匙。

后来我写报告时特意提了一句：登录框是门面，但黑客翻墙从来不走门。给开发者的建议也很简单——token必须加签名，敏感操作要二次校验，别把用户ID直接暴露在可逆编码里。可我知道，下次测试大概率还会遇到类似的逻辑漏洞。因为修复漏洞需要的是敬畏心，而不是安全补丁。