文章总结： 本文通过实战案例分析了JS渲染逻辑漏洞，作者在SRC资产中发现新站点存在登录遮罩层，通过追踪JS代码发现其依赖HTTP状态码验证（Response.ok属性），利用BurpSuite将401状态码改为200绕过前端验证。随后通过参数fuzz获取用户名，观察set-cookie操作发现auth_name为权限凭证，最终实现任意用户接管。文章强调JS逻辑追踪、参数fuzz和set-cookie观察是关键技能，并建议利用资产监控工具发现新目标。 综合评分： 85 文章分类： WEB安全,漏洞分析,实战经验,渗透测试,安全工具

JS渲染逻辑分析实战 || 从遮罩层绕过到任意用户接管

原创

庆尘 庆尘

Daylight庆尘

2026年4月20日 13:00 重庆

在小说阅读器读本章

去阅读

一周没更新了，发篇文章涨涨活跃度，上一篇文章讲的技巧课，这次就讲个上周挖的实战案例

手法并没有很特别，师傅们看个思路就行，希望对师傅们挖洞有所帮助

1

正文

最近在收集某个src资产时，由于之前挖过几遍他家的资产，所以很快就发现资产收集的结果中有一个之前没见过的站，所以开始测试

首先访问站点，页弹出遮罩层提示请先登录，页面如下

观察数据包发现是被鉴权包拦截，如下

追踪接口函数定位到js渲染逻辑关键代码，如下

这里简单提一下，Response.ok是一个只读属性，当 HTTP 状态码在 200–299 范围内时，其值为 true；否则（如 404、500 等）为 false。

也就是这里的JS逻辑是验证响应的状态码是不是两百多，所以用自动改包把响应包的状态码改为200

注：自动替换的Response header作用域包括响应的状态码

再次刷新页面，发现仍被拦截

观察数据包，发现是由于进入站点后，站点调用/api/auth来获取用户信息，但获取不到导致报错

数据包如下

通过ParamX收集js中所有参数并检索，成功找到用户名参数name

再fuzz用户名的值，成功调用接口

注意到响应中进行了set-cookie操作，且只设置了auth_name

猜测这个包就是站点赋予权限的包，在cookie中加入auth_name参数，发现内部需要登录的接口被成功请求

成功验证auth_name就是站点的访问凭证，修改auth_name即可实现任意账户接管

自动化复现流程：

Bp配置一个状态码401改200和请求体添加用户名，如下

刷新页面，成功接管用户x的账号

后续就是各种危害展示

由于站点内部信息比较敏感，所以最后成功定级严重

2

总结

案例中手法不是很特别，主要是师傅们要能将这些东西连接起来

案例关键点

1、看到遮罩层要能找到前端渲染遮罩层的依据

2、缺少用户名则要求你能够找到参数并fuzz出值

3、能细心观察到set cookie操作并判断出站点存在鉴权缺陷

然后是对于信息收集来说，师傅们如果想长期挖某个src，最好是要能够快速定位到新资产，这个可以借助网上的某些开源资产监控工具或者自己通过ai写一个，毕竟新资产出现问题的概率会大很多

在我看来，定位和分析js关键代码逻辑是Web漏洞，特别是未授权漏洞挖掘中一个非常重要的技能。

        像本次案例的js追踪基本属于算是最简单的一种。过程中既不涉及webpack处理后的多模块代码追踪，也不涉及复杂的参数和格式校验（即js要求这个接口的响应体必须符合某个格式或带有某个参数才通过校验）。

        所以师傅们碰到鉴权失效导致页面进行跳转或弹出等操作的时候可以多练练，自己尝试追踪一下然后绕过，我后面也会给师傅们写几个更复杂的边界校验逻辑绕过导致的各种后台接管案例，让师傅们更好的理解这个东西

以上内容纯属个人见解，欢迎有问题和不同看法的师傅们交流，期待下次继续给师傅们带来更优质的内容

本人亲带SRC漏洞挖掘课程第四期开课中，即将进入实战阶段，每周一次小复盘每月一次大复盘，可随时报名插班。欢迎感兴趣的师傅们咨询

《庆尘Src漏洞挖掘课第四期》开启招生 || 从理论到实战，我们力求把”未授权”玩到极致

免责声明：

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

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

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

本文转载自：Daylight庆尘 庆尘 庆尘《JS渲染逻辑分析实战 || 从遮罩层绕过到任意用户接管》