文章总结： 本文系统梳理登录框渗透测试思路。首先通过URL特征与报错差异进行信息收集及用户枚举，接着抓包分析加密逻辑，实施弱口令爆破与验证码绕过。重点剖析密码找回的逻辑缺陷如默认密保与步骤跳过，以及登录后的URL跳转、JWT篡改和越权访问等风险。建议结合定制字典与前端逆向进行验证。 综合评分： 82 文章分类： WEB安全,渗透测试,实战经验,漏洞分析

---

分享一次登录框渗透测试思路，这样测多半能出洞！

原创

是老A 是老A

老A搞安全

2026年7月28日 07:48 贵州

在小说阅读器读本章

去阅读

一位深耕网络安全的老兵，目前是一家安全公司的技术分管，擅长渗透测试及安全培训方向，老A的愿望是大家没烦恼，一切顺心！

近期有哥们吐槽，现在渗透越来越不好干了，光给一个登录框，可利用的点少得可怜……

额嗯……

工作再难，也得硬着头皮干，分享自己挖洞多年的一些心得，仅供技术交流！

先搞清楚目标是什么

拿到一个登录框，首先要明确：你在测试什么？

不是单单的关注”能不能登录进去”，而是”这个登录过程存在哪些安全隐患”

• 有没有暴力破解的风险？
• 有没有逻辑绕过的方法？
• 有没有信息泄露的问题？
• 有没有权限校验的缺失？

整个登录过程，从输入用户名密码，到后端验证，到返回登录结果，再到登录后的状态管理，每一个环节都可能出问题

但第一步，还是先做信息收集

先搞清楚这个登录框用了什么技术，有哪些表面特征

看看页面

/login、/signin、/auth/login、/api/login

不同路径暗示了不同的技术栈，登录页面的URL结构和报错信息可以透露后端技术

示例：

/login.action→Struts2，/login.do→Spring MVC，/api/login→前后端分离，/login.jsp→JSP

报错信息

输错用户名和输错密码，返回的提示信息是不是一样？

• 如果显示”用户名不存在” → 用户名可枚举
• 如果显示”密码错误” → 说明用户名存在

这是一个常见的信息泄露点。攻击者可以通过报错差异批量验证用户名是否存在

验证码

是否有验证码？图形验证码还是短信验证码？验证码是每次刷新都会变，还是同一个会话里可以复用？

验证码的设计方式直接影响暴力破解的难度

页面源码

查看页面源码，有时候会有意外发现：

• → 有CSRF防护
• 注释里可能写着接口地址或测试账号
• JS文件里可能暴露了加密逻辑

抓取登录请求

用Burp Suite拦截登录请求，看看请求包长什么样。

关注以下几个点：

请求方式

GET还是POST？如果是GET，用户名密码会暴露在URL里，存在日志泄露风险

参数名

username、password、captcha、rememberMe、redirectUrl

参数名本身也能提供信息。比如redirect可能存在URL跳转漏洞，token涉及Token生成逻辑

加密情况

密码是明文传输还是加密后传输？如果是加密的，加密逻辑在前端还是后端？

如果密码在前端用JS加密后再发送，那就要找到加密函数，这样才能构造合法的登录请求进行爆破

返回包格式

登录成功和失败的返回有什么不同？

{"code":200,"msg":"登录成功"} → JSON格式{"code":401,"msg":"用户名或密码错误"} → 统一的错误提示

暴力破解的两种打法

暴力破解分两种：弱口令猜解和用户名枚举

弱口令猜解

用常见的弱密码去试

经典弱密码字典

123456passwordadminadmin12312345678qwerty1234567891234512341111111234567000000admin@123

企业定制字典

很多系统使用企业名称缩写、年份、固定后缀作为密码。测试前先收集目标企业的相关信息（公司名简称、成立年份、域名），生成定制字典往往比通用字典更有效

测试方法

• 暴力破解的两种打法准备一个用户名列表（如果不知道用户名，先做用户名枚举）
• 准备一个密码字典
• 使用Burp Intruder进行爆破
• 通过返回包长度或状态码判断是否成功

用户名枚举

不管密码对不对，通过返回包的差异来判断用户名是否存在

典型差异：

用户名存在但密码错误：{"code":401,"msg":"密码错误"}用户名不存在：{"code":404,"msg":"用户不存在"}

如果看到这两种不同的提示，就可以批量验证用户名是否存在。有了有效用户名，再针对性地爆破密码，效率会高很多

注意：很多系统现在已经做了统一提示，比如无论什么情况都返回”用户名或密码错误”。遇到这种情况，用户名枚举就不好使了

绕过验证码

验证码是防爆破的重要手段，但实现不好的话，绕过方式很多

方式一：验证码复用

用同一个验证码重复提交多次

测试方法：获取一个验证码图片，截取其中captcha或code的值，用这个值重复发送登录请求。如果第二次请求还能成功，验证码就可以复用

方式二：验证码置空

直接删掉验证码字段，或者传空值

正常请求：

POST /loginusername=admin&password=123456&captcha=abcd

测试请求：

POST /loginusername=admin&password=123456

或者：

POST /loginusername=admin&password=123456&captcha=

如果后端逻辑是”没有captcha字段就不校验”，那这个验证码就形同虚设

方式三：验证码OCR

简单的图形验证码，可以直接用OCR识别

如果验证码是纯数字、无扭曲、无干扰线，Tesseract等OCR工具识别率很高

方式四：验证码爆破

如果验证码只有4位数字，总共10000种组合。并发请求的话，很快就能跑完

但这种方式容易被封IP，实际操作中比较少用

方式五：短信验证码绕过

短信验证码更常见的问题是：

• 验证码长度过短（4位数字）
• 验证码有效期过长（10分钟）
• 没有限制尝试次数
• 验证码没有做绑定（用A手机号的验证码给B手机号用）

逻辑漏洞

密码找回功能

密码找回是逻辑漏洞的重灾区

默认密保答案

很多系统的密保问题有一个默认答案，比如”111″、”admin”、”000000″

如果用户注册后没改过密保答案，攻击者输入默认答案就能重置密码

真实案例：某系统的密保答案默认是”111″，测试人员用admin账号输入111，直接跳转到了重置密码页面

密保答案可遍历

“你的出生地是哪里？”这种选择题式的密保问题，选项往往只有几个（北京、上海、广州……）。遍历一遍就能命中

重置链接可预测

密码重置链接长这样：

https://xxx.com/reset?token=123456

如果token是自增数字或者时间戳+简单算法，攻击者可以枚举出其他用户的重置链接

多步骤校验绕过

找回密码分三步：验证身份→发送验证码→重置密码

如果跳过第一步直接访问第二步，或者跳过前两步直接访问重置页面，那前面所有校验都白做了

测试方法：直接访问重置密码的最终URL，或修改URL中的步骤参数（step=1改成step=3），看能否越过前面的验证步骤

短信轰炸

输入手机号，点击”获取验证码”。

重放这个请求，观察是否每次都能成功发送短信

• 如果能连续发送 → 短信轰炸漏洞
• 如果提示“发送过于频繁” → 有防护

更隐蔽的轰炸方式：

系统限制同一个手机号60秒只能发一次，但攻击者可以换多个不同的手机号同时请求，导致同一个号码收到多条短信

任意用户注册

注册功能没有做校验，攻击者可以用任意手机号/邮箱注册

更严重的情况：注册时没有校验验证码，或者验证码可被绕过，攻击者可以批量注册账号

越权与未授权

登录后的跳转

登录成功后，系统通常会跳转到某个页面

POST /loginusername=admin&password=123456&redirect=/home

如果redirect参数可控，且后端没有校验跳转目标，攻击者可以构造钓鱼链接：

https://xxx.com/login?redirect=https://evil.com

用户登录后会被跳转到恶意网站

测试方法：将redirect参数改成外部网址（如https://evil.com），看是否跳转

登录后的Token

登录成功后，系统返回的Token有什么特征？

• JWT格式（eyJ…）？ → 可以解析看看里面存了什么信息
• 自增数字？ → 可以遍历
• 有签名吗？ → 测试是否可以篡改

JWT测试重点：

解析JWT的payload，看看里面有没有存username、role、user_id等信息。如果有，尝试修改这些值再重新签名（使用空签名或none算法），看服务端是否校验签名。

已登录后的越权

登录成功只是第一步。登录后能访问哪些数据，是进一步测试的重点

这里涉及的水平越权、垂直越权、未授权访问，与上一篇文章《越权测试三模式》中的方法一致：

• 拿到登录后的Token，把userId改成别人的
• 拿普通用户的Token去访问管理员接口
• 拿掉Token直接访问需要登录的接口

其他需要注意的点

加密参数

如果密码在前端加密后传输，需要找到加密函数。

一般在前端JS文件中搜索encrypt、password、encode等关键词可以定位。找到后，逆向出加密逻辑，在Burp中预处理密码字段，再进行爆破。

返回包信息泄露

登录失败时，返回包里是否包含敏感信息？

• 用户名是否存在
• 账号状态（已锁定、未激活）
• 剩余尝试次数
• 最近登录时间/IP

这些信息看似”帮助用户”，实际上给了攻击者更多线索

静态文件泄露

登录页面引用的JS、CSS、图片文件，有时候会暴露一些不该暴露的东西。 比如在JS文件中发现：

var apiBase = "https://internal-api.xxx.com"var testAccount = "test/123456"// TODO: 上线前删除测试账号

这些信息可以直接利用

⚠️ 法律声明：以上内容仅供安全学习和授权测试使用。未经授权的漏洞利用属于违法行为，请勿对未经授权的目标进行测试。

---

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：老A搞安全 是老A 是老A《分享一次登录框渗透测试思路，这样测多半能出洞！》