文章总结： 文档通过实战案例揭示响应包篡改漏洞：攻击者通过拦截登录接口返回的JSON数据，将success或auth字段从false改为true即可绕过认证进入后台。关键发现包括前端依赖客户端状态判断权限、后端缺乏二次校验等设计缺陷。可操作建议包括后端应对每个请求进行独立身份验证、避免在响应中返回权限字段、统一使用401状态码。 综合评分： 78 文章分类： WEB安全,渗透测试,漏洞分析,安全意识,安全开发

响应包篡改绕过登录：false改成true，我直接进了后台管理面板

原创

逍遥 逍遥

昆仑AI安全实验室

2026年6月12日 00:52 广东

在小说阅读器读本章

去阅读

上次打一个企业的管理系统SRC，前端界面做得挺好看，登录框、验证码、图形拖动一应俱全。我试了几个常见的弱口令，都不对。本来想放弃了，结果在Burp里多看了一眼登录接口的响应包——就这一眼，我直接绕过验证进了后台。

不是SQL注入，不是XSS，也不是越权。只是把服务器返回的JSON里一个字段，从false改成了true。整套操作花了两分钟，后台就这么对我敞开了大门。

一、漏洞到底出在哪？

很多时候，开发者把登录验证的逻辑写成这样：

1. 用户提交账号密码。
2. 后端校验账号密码是否正确。
3. 如果正确，后端返回一个响应：{"status":true,"message":"登录成功","role":"admin"}。
4. 如果错误，后端返回：{"status":false,"message":"账号或密码错误"}。
5. 前端收到响应后，判断status是true还是false，决定跳不跳转到后台。

问题在第五步。登录状态和权限的判断，完全交给了前端。

攻击者不需要知道正确的密码，只需要用Burp Suite把服务器返回的false拦截下来，手工改成true，再放给浏览器。浏览器拿到true，就按照代码逻辑，乖乖跳转到了后台页面。

更致命的是，很多系统的后台接口，只管前端传来的role或userType字段，根本不再去Session或Token里核实一次。攻击者把响应包里的role从user改成admin，不仅能进后台，还能直接拿管理员权限。

二、真实案例：两次改包，两次进后台

说一个今年年初的实战。

目标是一个教育培训机构的教务管理系统。登录接口返回的JSON长这样：

{  "code": 400,  "msg": "账号或密码错误",  "data": null,  "success": false}

随便输了个账号admin，密码123456，用Burp截住了这个响应。直接把"code":400改成"code":200，把"success":false改成"success":true，然后放行。

浏览器收到后，前端代码读到了success=true，直接跳转到了/admin/index。教务管理后台就这么出现在我面前——课程数据、学生信息、缴费记录，全部能看能导。

再往后走，我发现这个系统的一个高危接口——/admin/userList直接返回了所有用户的手机号和身份证号。越权漏洞叠加响应包篡改，高危中的高危。

另一次打一个企业OA系统，响应包更简单，就一个字段：

{"auth":false}

改成{"auth":true}放行，直接跳进了后台首页。后台顶上写着“欢迎您，系统管理员”。一个false改true，我就变成了管理员。

三、手工怎么做？完整流程三步走

第一步，抓登录响应包。Burp Suite配置好代理，浏览器打开目标系统的登录页。输入任意账号密码，点击登录。Burp的Proxy标签页会抓到登录请求和对应的响应。

第二步，修改响应。在Proxy里找到登录接口的返回包，右键选Do intercept→Response to this request。点击Forward，下一个包就是服务器返回的响应。在Response窗口里，把响应的状态码从4xx或5xx改成200，把Body里所有的false、fail、error改成true或success，观察有没有角色字段（role、userType、level、isAdmin），有的话就改成最高权限对应的值。然后点Forward放行。

第三步，绕过前端路由。有些系统不仅校验响应字段，还做了前端路由守卫——未登录状态下直接访问/admin/xxx会被重定向到登录页。这种情况试一下直接访问静态资源路径：/admin/static/js/main.js或/admin/api/config，如果能直接拿到JS或接口数据，说明后端根本没做权限校验，前端的路由守卫只是纸老虎。

自动化也可以，用Burp的Match and Replace功能。在Proxy → Options → Match and Replace里加一条规则，把响应体里所有的"success":false自动替换成"success":true。这样每次登录失败，返回给浏览器的都是“成功”。

四、这种漏洞为什么还这么普遍？

前端路由不等于权限控制。很多前后端分离的项目里，开发者以为“用户不登录就看不到后台页面”，但实际上后台页面就是一堆JS和CSS文件，全打包在前端代码里。后端接口没有做身份校验，前端再怎么跳转都是自欺欺人。

产品经理的逻辑也有问题。“登录失败返回状态码，前端根据状态码跳转”——这个逻辑在产品需求文档里写得很清楚。但产品经理没想过，这个状态码可以被攻击者篡改。

安全测试的盲区同样存在。自动化扫描器很难发现这类漏洞，因为扫描器不会“改响应包”。渗透测试人员如果不做这一步手工测试，也会漏掉。

五、怎么防？

后端必须对每一个请求做身份校验，不能只靠前端传来的状态码或角色字段来判断。登录成功时，只返回一个Session ID或JWT Token，不要返回任何权限信息。权限信息由后端在后续每个请求中，从Token或Session里重新读取。

登录失败的响应体里，不要出现任何可以被前端用来判断权限的字段。统一返回{"code":401,"msg":"认证失败"}，不区分是“密码错误”还是“账号不存在”。

后端API必须用独立的身份验证中间件进行校验，不能信任客户端请求体中的任何权限相关参数。身份和权限信息只能从服务端Session、数据库或JWT Token中获取。

六、写在最后

响应包篡改攻击的本质，是开发者把“展示层的判断”当成了“安全层的校验”。前端只是一个展示工具，不能替后端做安全决策。

下次挖洞时，别急着跑字典。先抓个登录失败的响应包，看看有没有success、status、auth、code这些字段。如果有，改一下试试。可能只改一个false，你就成了管理员。这个漏洞不需要技术水平，只需要多看一眼。

https://wwbxi.lanzouu.com/iq92o3roj2kb  ：星球内部文件下载地址PDF版本

https://blog.csdn.net/qq_39185255/article/details/161904227?spm=1001.2014.3001.5502  ：在线阅读

免责声明：

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

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

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

本文转载自：昆仑AI安全实验室 逍遥 逍遥《响应包篡改绕过登录：false改成true，我直接进了后台管理面板》