web登录渗透

登录框是录渗web渗透里最尴尬的位置。它看起来像一道门，录渗实际上往往是录渗窗户纸。我见过太多团队花一周时间打内网，录渗最后发现突破口就是录渗管理员把密码设成了Admin@123——这种案例占了我接手项目的四成。

先别急着上sqlmap。录渗手动试三条路径：第一，录渗用户名枚举。录渗注意服务器返回的录渗“用户名不存在”和“密码错误”在响应时间上的差异，差50毫秒都算线索。录渗第二，录渗密码喷洒。录渗别对着一个账号死磕，录渗拿top100弱密码去撞整个公司域名下的录渗所有账号，锁定率反而高。录渗第三，验证码逻辑。有些系统的验证码只校验一次，你抓包重放请求，验证码形同虚设——这漏洞出现频率高得离谱。

真正的分水岭在token处理上。去年测试某金融系统，登录接口返回的JSON里藏着完整的JWT，密钥是硬编码在JS文件里的。我直接在浏览器控制台伪造了管理员token，全程没碰数据库。这类问题根源在于开发者把“登录成功”和“会话可信”画了等号，却忘了token本身需要独立验证。

绕过登录还有条野路子——直接改前端逻辑。把登录按钮的disabled属性删掉，或者把onsubmit事件里的校验函数替换成空函数。别笑，我实测过某政务平台，前端校验和后端完全脱节，删掉两行JS就能直接进后台。这不算高明攻击，但能揭露一个事实：很多系统连最基本的“前端不可信”原则都没贯彻。

再往下走就是经典SQL注入了，但现在的WAF没那么好骗。试着用分块传输绕一下，或者把payload编码成multipart/form-data的boundary里。有个诀窍：当WAF检测到异常字符时，它会先返回403，但如果你把请求拆成多个TCP包，有些设备只检查第一个包，后面就放行了。这种手法不稳定，但值得一试。

最容易被忽略的是密码重置逻辑。找找看有没有“忘记密码”功能，然后观察三步：验证码是否绑定用户、重置链接是否带随机参数、新密码是否明文回显。上周测某电商平台，重置链接里的token就是一串自增数字，改个ID就能重置任意用户密码——这种设计漏洞比技术漏洞更致命。

收尾时提醒一句：别沉迷于花式绕过。多数系统的弱点不在技术层，而在流程层。比如测试账号权限过大、日志不记录登录失败、密码策略只对新建账号生效。这些地方花十分钟就能发现，却常常被忽略。真正的渗透不是炫技，是找出那些“你以为安全”的角落。