登录页面的渗透

登录框是登录的渗互联网的门垫。每个访客踩上去之前，页面门垫底下可能已经埋了雷。登录的渗我见过太多人以为登录页就是页面“用户名+密码+验证码”的三件套，但真正的登录的渗攻击面往往藏在你看不见的请求里。

拿去年一个金融客户来说，页面他们开发团队把登录接口写得干干净净——参数校验、登录的渗频率限制、页面图形验证码，登录的渗样样齐全。页面可渗透测试时，登录的渗我随手改了改HTTP头里的页面X-Forwarded-For字段，把IP换成127.0.0.1，登录的渗验证码直接失效了。页面为什么？登录的渗因为他们的WAF规则只对公网IP做风险拦截，内网地址直接放行。这个逻辑漏洞比SQL注入还蠢，但就是藏在最显眼的地方。

更常见的是用户名枚举。别小看这个“小毛病”，它能帮你把字典从几百万条压缩到几百条。响应时间差是信号——账号不存在时，数据库查0行返回；账号存在但密码错，查1行再比对哈希。两次查询耗时差个20毫秒，用脚本统计就能画出用户名的“存在性地图”。有些系统更贴心，直接返回“用户不存在”或“密码错误”，连猜都不用猜。

密码重置流程是另一片沼泽。我测试过一家SaaS平台，重置链接里的token是用户ID+时间戳的Base64编码。解码后改掉用户ID，就能重置任意管理员的密码。他们甚至没给token加个过期校验，我拿三天前的链接照样能改密码。这不是黑魔法，就是开发图省事，把明文状态塞进了签名里。

还有个容易忽略的点——登录页的第三方组件。很多前端为了做社交登录，嵌入了Google或Facebook的SDK。但某些地区的网络环境会加载失败，开发者就自作聪明加了onerror回调，把用户重定向到一个备用域名。渗透测试时只要伪造DNS解析，把这个备用域名指到攻击服务器，就能拿到所有通过社交登录的用户的授权码。这招叫“供应链投毒”，但多数时候只是测试环境配置疏忽留下的后门。

别以为HTTPS就万事大吉。登录页的证书链如果没校验完整，中间人攻击照样能截获明文密码。去年测试某个政务系统，他们的证书链里混了一个自签名CA，浏览器弹警告但用户点“继续”就进去了。我用树莓派搭了个钓鱼AP，改了路由器的DNS，半小时就拿到了测试账号的密码——整个过程没碰任何漏洞，纯粹是利用了用户对警告框的麻木。

话说回来，登录页渗透最值钱的东西不是密码本身，而是密码背后的重用习惯。拿到一个邮箱密码，去撞库其他平台，成功率超过三成。所以真正专业的渗透测试，会在报告里强调：别只修漏洞，要强制开启双因素认证。否则你修好了登录框，攻击者换个角度又从密码重置接口爬进来了。

最后说个反直觉的观察——很多系统的登录页比内部页面安全得多。因为甲方知道入口要脸面，把WAF、风控全堆在登录接口上，但内部API却裸奔。我见过一个案例，登录接口用了五层防护，可一旦登录成功，后续的每个请求都只靠一个userId参数识别身份。改个数字就能横向越权，这等于把保险柜焊死在门上，窗户却大敞着。

所以，下次看到登录页，别只盯着那个输入框。后面跟着的每一个请求、每一个响应头、每一个跳转逻辑，都是潜在的裂缝。渗透测试不是找茬，是帮你在门垫底下装上报警器——只是很多人装完报警器，忘了把备用钥匙藏好。