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

原创

逍遥
逍遥

昆仑AI安全实验室

2026年6月12日 00:52
广东

在小说阅读器读本章

去阅读

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

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

一、漏洞到底出在哪？

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

用户提交账号密码。
后端校验账号密码是否正确。
如果正确，后端返回一个响应：{\"status\":true,\"message\":\"登录成功\",\"role\":\"admin\"}。
如果错误，后端返回：{\"status\":false,\"message\":\"账号或密码错误\"}。
前端收到响应后，判断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，你就成了管理员。这个漏洞不需要技术水平，只需要多看一眼。