| name | no-auth-quick-test |
| description | 无账号登录页面快速测试策略。当用户只给了一个登录页面 URL 且没有提供账号密码时使用。在没有认证凭据的情况下,能测试的范围有限,应在3分钟内快速完成外围测试。不要花大量时间在无法深入的功能上。 |
| priority | 9 |
| vuln_types | ["未授权访问","信息泄露","登录绕过","默认口令","源码泄露"] |
| triggers | ["登录页","login","no-auth","无账号","未登录","Cookie缺失","Authorization缺失","Vite","swagger","actuator"] |
| synonyms | ["unauthenticated-test","no-login-test","no-auth-check"] |
| metadata | {"tags":"登录页面,无账号,快速测试,外围,login,no-auth,unauthorized","category":"strategy","authority":"expert"} |
无账号登录页面快速测试策略
没有账号密码时,能测的东西很有限,3 分钟内完成。不要反复分析同一个页面。
适用场景
- 用户给了登录页面 URL,但没有提供账号密码
- 注册功能不可用或不存在
- 无法获取有效的认证 Token
测试清单(按顺序,全部完成后结束)
1. JS 分析与 API 发现(1 分钟)
1. js_extract_apis → 查看所有资源文件清单
2. 选择业务 JS 调用 js_analyze_selected 深度分析
3. 关注 JS 中是否有:
- 硬编码的 API Key / Token / 密码
- 内部 IP / 域名
- 管理后台路径
- 调试接口
- Source Map 泄露(等于前端源码泄露)
1.5 Vite/Dev Server 检测(必做!发现即高危)
只要目标有前端页面,就必须检测。Vite Dev Server 暴露在生产环境 = 服务器文件系统可读。
Step 1: 判断是否 Vite Dev Server
proxy_send_request GET /@vite/client → 200 = Vite Dev Server
proxy_send_request GET /src/main.ts → 200 且返回 JS 代码 = 源码泄露确认
Step 2: 如果是 Vite → 立即测 @fs 路径遍历(CVE-2023-34092 等)
proxy_send_request GET /@fs/etc/passwd
proxy_send_request GET /@fs/proc/self/environ
proxy_send_request GET /@fs/app/.env
proxy_send_request GET /@fs/app/package.json
→ 任意一个返回 200 + 文件内容 = 严重漏洞(任意文件读取)
Step 3: 如果 @fs 可用 → 深入读取敏感文件
/@fs/app/.env → 数据库密码、JWT_SECRET、API_KEY
/@fs/app/.env.local → 本地环境变量(常含真实密码)
/@fs/app/prisma/seed.ts → 种子数据中的硬编码用户密码
/@fs/app/docker-compose.yml → 数据库连接串
/@fs/app/server/index.ts → 后端入口代码
Step 4: 即使 @fs 被禁 → Vite Dev Server 仍可读 /src/ 下全部源码
/src/router/index.ts → 完整路由表(所有页面)
/src/api/*.ts → 所有 API 端点定义
/src/stores/user.ts → 认证逻辑、角色判断
/src/utils/request.ts → axios 配置、baseURL、硬编码 Token
⚠️ 发现 Vite Dev Server 在线是高优先级突破口,必须深入利用!
2. API 未授权访问采样(30 秒)— 采样推断,不穷举
从 JS 提取的 API 中挑 5-10 个不同模块的接口(用户/订单/管理/系统各挑):
- 用 proxy_send_request(method="GET", url=..., drop_auth=true) 请求
⚠️ 必须传 drop_auth=true,否则工具会自动注入全局 Cookie,看到的 200 是带认证态
- 采样结果判断:
├─ 全部 401/403 → 结论"统一鉴权",立即停止未授权测试
│ → 把时间花在下面的登录绕过和 JS 分析上(这些才有突破口)
├─ 某个返回 200 → 发现突破口!记录漏洞,继续深入
└─ /swagger/ /api-docs/ /actuator/ 返回 200 → 信息泄露,记录
⚠️ 不要对 100 个接口逐个测未授权!采样 5-10 个一致就够了。
采样省下的时间用来做更有价值的事:分析 JS 找后门、测登录绕过。
3. 登录接口测试(30 秒)
- SQL 注入:用户名填 admin' OR '1'='1,看响应变化
- 用户枚举:分别输入存在/不存在的用户名,对比响应差异
- 默认密码:admin/admin, admin/123456, test/test
- 验证码:有没有验证码?验证码能否绕过(重放/空值)?
4. 注册功能(如果有)(20 秒)
- 是否存在注册入口
- 注册是否需要审核
- Mass Assignment:注册时多传 role=admin 字段
5. 其他快速检查(20 秒)
- 密码重置功能是否存在
- OAuth/SSO 登录入口
- URL 跳转参数(redirect/next/return_url)
- CORS:发一个带 Origin 的请求看是否反射
- 响应头安全(X-Frame-Options / CSP / HSTS)
- robots.txt / sitemap.xml 是否有隐藏路径
6. 结论
完成以上测试后,总结:
- 找到的漏洞
- 无法深入测试的原因(缺少账号)
- 建议:提供测试账号后可深入测试的方向
🔥 突破口升级(最重要!)
如果在测试过程中获得了认证能力,立即切换到完整测试模式:
| 突破口 | 下一步 |
|---|
| SQL 注入万能密码绕过了登录 | 用获得的 Token/Cookie 继续测后台所有功能 |
| 发现默认密码能登录(admin/admin) | 登录后浏览所有功能,注册功能点,完整测试 |
| 某个后台页面/API 未授权可访问 | browser_goto 进入后台,分析所有功能点 |
| JS 中发现硬编码的 Token/密钥 | 用这个 Token 请求 API,看能访问多少功能 |
| 注册了新账号 | 用新账号登录,完整测试认证后功能 |
具体操作:
- 先用
note_add(type="result") 记录这个突破口漏洞本身
- 然后用
browser_set_cookie 或在请求中带上获取的 Token
- 用
browser_goto 访问后台页面
- 用
browser_get_content + js_extract_apis 分析后台功能
- 对后台功能继续用
sitemap_add_feature 注册新的功能点
- 按正常 checklist 流程测试后台功能
不要发现突破口后只记录漏洞就结束 — 这是渗透测试最有价值的时刻,要深入!
7. 未授权响应判定状态机
对任何未登录请求,不要只看状态码,必须结合响应体、字段数量、跳转位置和错误语义判断:
| 响应 | 判定 | 下一步 |
|---|
200 + 真实业务数据 | confirmed_vuln | 记录未授权访问证据,继续测同模块列表/详情/导出 |
200 + 空数组/空对象 | suspected | 换 ID、换分页、加 verbose/debug、测列表和详情差异 |
302 到登录页 | 暂不算漏洞 | 继续检查 API 是否仍返回 JSON,前端跳转不能代表服务端鉴权 |
401/403 | 暂不算漏洞 | 尝试方法改写、路径变体、头部绕过、旧版本 API、大小写路径 |
404 | 不直接判安全 | 对比带认证/不带认证是否同样 404,排除伪装拒绝 |
字段减少但仍有 id/email/phone/order/status | suspected | 评估是否为敏感信息泄露或对象枚举 |
8. 标记 not_vuln 前最低自检
- 已确认请求确实不带全局 Cookie/Token,必要时显式使用
drop_auth=true。
- 已从 JS、SourceMap、Swagger、robots、sitemap 中抽样不同模块接口。
- 已覆盖至少登录、用户/个人信息、管理、导出/下载、系统配置五类候选接口中的可见项。
- 已尝试旧版本路径、大小写路径、尾斜杠、
.json、方法改写。
- 已记录“缺账号导致不能验证”的方向,输出
needs_review,而不是把认证后漏洞判为不存在。
⛔ 不要做的事
- 不要反复分析同一个 JS 文件 — 看一遍就够了
- 不要逐个测试 100 个 API 的未授权 — 采样 5-10 个推断
- 不要尝试暴力破解密码 — 除非用户明确要求
- 不要花超过 3 分钟 — 没账号能测的就这些,测完就结束
- 不要注册超过 3 个功能点 — 没账号时功能点不多