去年一家做在线教育的下属公司被拖库，两万多名学员的于W应用身份证号和手机号在黑产论坛上打包卖。事后复盘，管理攻击者没用什么高深手段，漏洞就是下属利用了一个文件上传接口——那个接口本来只该传头像，结果连php文件也照单全收。于W应用运维在日志里看到有人传了个shell.php，管理还以为是漏洞测试人员干的，没管。下属三天后数据库被清空。于W应用

这类事在Web应用里太常见了。管理很多人一说“漏洞”，漏洞脑子里蹦出来的下属是SQL注入、XSS这些老面孔。于W应用但真正让企业半夜爬起来修服务器的管理，往往是另一类东西——Web应用管理漏洞。它不直接偷数据，也不弹窗，但它能让你整个系统的门锁形同虚设。

权限配置错误：最容易被忽略的“后门”

我见过一个后台管理系统，登录后URL是/admin/index.php?role=1。把role改成2，页面刷新，直接进了超级管理员面板。开发图省事，把角色判断写在了前端JS里，后端接口只检查“有没有登录”，不检查“登录的人是谁”。这种漏洞扫描器不一定报，但稍微懂点URL参数的人就能利用。

权限配置错误还包括：默认账号没删（admin/admin888）、目录列表没关（访问/uploads/能看到所有上传文件）、数据库备份文件放在Web根目录下（/backup.sql直接下载）。这些不是代码写错了，是部署时没管好。

会话管理缺陷：登录了不等于安全了

会话固定攻击是个典型。用户访问登录页，服务器给一个sessionid；用户输入账号密码，服务器没换sessionid，直接标记为已登录。攻击者提前拿到这个sessionid，等用户登录后，自己拿着同一个id就能冒充用户。修复方法很简单——登录成功后重新生成sessionid，但很多老框架默认不这么做。

还有会话超时设置过长。一个内部OA系统，session有效期设了30天。员工在网吧登录后忘了退出，下一个用那台机器的人打开浏览器，直接进了OA。这算管理漏洞还是代码漏洞？我觉得算管理——因为安全策略没定好。

文件上传与目录遍历：老问题，新花样

文件上传漏洞被说烂了，但每年OWASP Top 10里它都在。问题不在于“能不能传php”，而在于很多开发者只在前端用JS判断后缀名。抓包改一下，.php照样传上去。更隐蔽的是传.htaccess文件，把.jpg解析成php。我见过一个案例，攻击者传了个图片马，里面嵌了PHP代码，然后通过本地文件包含漏洞去执行它。

目录遍历也类似。一个下载接口写的是/download?file=report.pdf。把file改成../../../../etc/passwd，服务器就把系统密码文件吐出来了。这种漏洞在老旧CMS里一抓一大把。

逻辑漏洞：规则写错了，比没写还可怕

某电商平台的优惠券功能：用户领一张满100减50的券，下单时用掉，然后取消订单。券退回来了，但订单里的商品已经发货了。反复操作，0元购。这不是代码有bug，是业务逻辑没考虑“取消订单后券该不该退、退了之后能不能再用”。

还有密码找回。输入用户名，系统返回“该用户不存在”或“验证码已发送”。攻击者拿个用户名字典跑一遍，就知道哪些邮箱注册过。更糟的是，有些系统把验证码直接返回在HTTP响应里，或者验证码是4位纯数字且不限制尝试次数。

怎么判断一个漏洞算不算“管理漏洞”

我的标准很简单：如果修复它需要改代码，那是代码漏洞；如果修复它只需要改配置、改流程、改权限分配，那就是管理漏洞。但现实中两者经常混在一起。比如未授权访问，可能是代码没写权限校验，也可能是运维把管理后台暴露在公网且没加IP白名单。

回到开头那个教育公司。他们后来加了WAF，改了上传逻辑，但根本问题没解决——开发、运维、安全三个人各管一摊，没人对“这个接口到底该不该让外网访问”负责。Web应用管理漏洞，说到底不是技术问题，是人的问题。你代码写得再漂亮，部署时把debug模式开着，把.env文件留在Web目录里，一样白搭。

所以下次做渗透测试，别只盯着注入点。翻翻robots.txt，试试/admin、/backup、/.git，看看响应头里有没有泄露版本号。这些不起眼的地方，往往才是真正能进去的门。