1. 从一次渗透测试聊起这三个漏洞为什么总被一起提干安全这行久了你会发现一个规律在很多漏洞报告里目录遍历、越权和信息泄露经常同时出现。不是说它们必须绑在一起而是它们往往是同一套不严谨的开发习惯留下的连锁反应——目录遍历帮攻击者摸清了服务器上的文件结构信息泄露带来了数据库账号、内部接口地址而这些线索最终汇成一条路让越权变得轻而易举。我去年做的一次授权渗透测试就是典型的例子。目标是一个企业内部管理系统第一眼看上去没什么特别登录页、表单、报表常规得不能再常规。但就在测试附件下载功能时我改了一下文件路径参数服务器直接把/etc/passwd吐了出来。顺着这个目录遍历漏洞又翻到了配置文件里的一段数据库连接字符串。更离谱的是系统里的普通账号居然可以调用管理员接口修改用户角色。整个过程没用到任何0day全是Web应用里最经典的老三样。那次之后我就决定得把这三个漏洞串起来写一篇真正讲透的文章。这篇文章我不会堆名词而是从一个从业者的视角把这些年实际踩过的坑、看过的代码、修过的问题都倒出来。不管是刚入门的安全新人还是写了几年业务代码的开发只要你想搞清楚这三个漏洞到底是什么、怎么找、怎么修这篇文章应该能给你一些实在的东西。2. 目录遍历当服务器把家底亮给你看2.1 漏洞原理与产生场景目录遍历Path Traversal说白了就是攻击者通过构造特殊的路径序列绕过开发者的路径拼接逻辑把文件访问范围扩展到应用原本不该触及的目录。最经典的载荷就是../在Linux系统里它代表上级目录连续叠加就能一路爬升直到访问整个文件系统。那为什么这个漏洞在真实业务里这么常见根子在于开发者对用户输入太信任。很多老系统的文件下载功能是这么写的用户传一个文件名后端直接把它拼到某个目录后面然后读文件返回。这种做法在写代码的当下确实省事但等于把文件系统的钥匙插在了门锁上等攻击者来拧。常见的高危场景有这么几类文件下载、预览功能参数直接用了文件名或相对路径导出文件、生成报表功能传入路径参数用于定位模板或临时文件语言包、主题资源加载文件名参数可被用户控制Nginx、Tomcat、Spring Boot 等中间件配置不当导致的别名穿越我见过一个很有意思的案例某系统做在线文档预览URL 长这样/preview?file合同_20240115.pdf后端拿这个文件名去固定目录找文件。测试的时候我把参数换成file../../../../etc/passwd响应直接返回了系统账号信息。开发者万万没想到一个合法功能的参数居然成了服务器文件系统的任意门。2.2 经典案例复盘Spring Framework 目录遍历漏洞今年安全圈刷屏的CVE-2024-38819就是目录遍历漏洞的一个典型现代变种。它影响 Spring Framework 的静态资源处理模块攻击者通过精心构造的 URL利用资源解析器对路径的规范化缺陷可以绕过防护读取到任意文件。这个漏洞本质上不是新物种而是老问题在新框架里的重新演绎。复盘这个漏洞时我重点看了它的根因框架在解析静态资源路径时对 URL 编码后的..序列处理不够严谨导致%2e%2e%2f这类编码载荷在多层解析后被还原成了目录穿越序列。这里有个值得所有开发者记住的点过滤../是不够的因为攻击者可以换花招——URL 编码、双层编码、Unicode 畸形字符、绝对路径手法多到数不清。这类漏洞影响范围之所以大是因为 Spring Framework 在 Java 生态里的普及率太高。很多企业自己写的业务代码没出事反倒是地基里的框架出了纰漏。所以每次框架发布安全更新不要拖尽快升级。我在多个客户现场见过因为升级有风险而长期不升框架的结果安全扫描一打一个准。2.3 修复方向与绕过陷阱关于目录遍历的修复市面上的文章写了很多但真正落到实处的方案是有讲究的。最稳妥的做法不是过滤而是校验规范路径。思路是先把用户传入的路径和基础目录拼接然后通过路径规范化得到一个绝对路径最后校验这个绝对路径是否以基础目录开头。如果不在范围内直接拒绝。我习惯用伪代码来描述这个校验过程baseDir /data/files inputPath request.getParameter(file) fullPath baseDir / inputPath canonicalPath normalize(fullPath) if not canonicalPath.startsWith(baseDir): return 403看起来简单但有几个隐藏的坑必须提一下。第一startsWith判断要记得加目录分隔符否则/data/files_private这种路径也会被放行。第二Windows 环境下大小写不敏感、路径分隔符不一致校验逻辑要做好兼容。第三尽量避免让文件名直接进文件系统 API更好的做法是把文件名映射成数据库里的 ID从源头杜绝用户控制路径的可能。另外中间件层面的配置也别忽略。给 Nginx 或 Tomcat 设置好静态资源的真实路径映射关闭不必要的别名访问能减少很多默认配置带来的暴露面。这个属于纵深防御的思路——应用层校验是第一道门中间件配置是第二道门别把所有的安全希望都押在一层上面。3. 越权一个普通账号怎么操控管理员权限3.1 水平越权和垂直越权越权漏洞在安全界有个更学术的名字叫访问控制缺陷Broken Access Control。它指的是应用没有正确验证用户是否有权执行某个操作或访问某个资源。讲这个概念的时候我喜欢用生活化的例子水平越权就像你住酒店用房卡打开了隔壁房间的门。订单系统里用户A登录后修改自己的订单没问题但如果他修改订单ID就能操作别人的订单这就是水平越权。本质上是同一级别用户之间的越权访问。垂直越权更像实习生拿了CEO的门禁卡。普通用户直接调用管理员的接口、普通员工给自己提权这就是垂直越权。本质上是低权限用户执行了高权限操作。水平越权的高发区几乎都在基于ID的查询或操作上面。比如用户资料查看/profile?id1001、订单详情/order/detail?orderId8888参数是连续的、可枚举的数字后端拿到参数之后查库就返回压根不管这数据是不是属于当前登录用户。这种漏洞在测试的时候特别好发现登录A账号复制请求换成B账号的资源ID看响应就完了。垂直越权则往往藏在前端隐藏入口的幻觉里。不少开发觉得后台管理按钮没渲染出来普通用户就看不到管理功能了。问题是攻击者根本不需要看按钮直接抓包、改 URL、调接口就行。只要后端接口没有做角色校验前端隐藏菜单只是一层纸。3.2 权限校验的三个必备层次我希望每个开发者都能记住一个原则权限校验必须在后端做而且必须在处理业务之前做。前端控显只是用户体验不是安全措施。我在代码审计中总结了一套相对完整的校验层次身份认证层确认你是谁。这一层解决的是登录问题确保当前请求来自于一个已登录的合法用户。授权校验层确认你能干什么。这一层解决的是角色问题需要检查当前用户是否具备某个操作的角色或权限点。资源所有权层确认这个数据是不是你的。这一层解决的是归属问题在访问具体资源时校验资源归属与当前用户一致。很多系统只做了第一层也就是登录校验后面两层完全缺失。结果是任何人登录后都能访问任何人的数据和任何管理员接口。那种为什么扫描器能挖出这么多越权的疑问答案就是后面两层根本没做。那怎么判断一个接口的权限校验是否合格我有个土办法把当前用户ID和角色模拟成最普通的访客身份然后遍历所有业务接口看哪些接口还能正常返回数据、正常执行操作。如果访客都能调通说明这个接口要么本来就是公开的要么就是权限校验漏了。3.3 Sa-Token 框架下的越权实践与注意点近期圈里热议 Sa-Token 的横纵越权问题不少团队用这个 Java 权限框架时踩了坑。Sa-Token 本身是一个非常优秀的轻量级权限框架提供了登录认证、权限认证、Session 会话管理等能力。但问题恰恰出在用得太顺手上。我在看一些项目代码时发现很多开发者把StpUtil.getLoginId()拿来做数据归属判断然后就觉得权限已经做好了。实际上 Sa-Token 的核心职责是身份认证和角色权限判断它不会自动帮你判断这个订单是不是当前用户的。比如订单删除接口开发者只调用了StpUtil.checkLogin()确认用户已登录然后拿着请求里的订单ID直接去删库。这就漏了资源归属校验——任何一个登录用户都可以删别人的订单这在 Sa-Token 框架里是完全合法的因为框架根本不知道业务规则。我自己在项目中总结了一套用 Sa-Token 的正确姿势StpUtil.checkLogin()只解决有人StpUtil.checkPermission(order:delete)解决是合适的人而操作的是自己的数据这一层必须写在业务代码里。比如删除订单之前先从数据库查出订单归属用户ID和StpUtil.getLoginId()比对不一致就抛异常。这三层都过了才算真正安全。3.4 越权漏洞的检测思路检测越权说难也难说容易也容易。难在业务逻辑复杂容易在于思路一旦通了你就能举一反三。第一步梳理系统角色。画一个矩阵横轴是功能模块纵轴是角色等级每个单元格标注允许/不允许。这张表既是开发时的需求文档也是测试时的对照表。第二步用低权限账号抓取高权限请求。登录普通账号把所有请求抓下来挑出涉及接口调用的部分一个个放到低权限甚至未登录环境下去重放看返回。第三步重点盯资源ID可猜测的接口。连续ID、UUID也好、雪花ID也好只要别人能猜到或者拿到就要做归属校验。看到/xxx/{id}这种 RESTful 写法优先测试越权。第四步别放过批量接口和导出接口。这几年我见过不少案例是单个接口防护到位结果批量查询接口忘了做行级权限过滤一次请求把全库数据拖走了。4. 信息泄露那些不设防的敏感数据出口4.1 HeapDump 泄露的杀伤力Spring Boot 的 Actuator 是运维监控的一把好手HeapDump 功能可以导出 Java 堆内存快照用来分析内存泄漏。但这个功能如果暴露到公网就是一场灾难。为什么因为 Java 堆内存里保存着什么一切在运行中的数据。用户手机号、身份证号、数据库连接串、Redis 密码、加密密钥、Token甚至管理员当前会话的 Session ID都在堆里躺着。攻击者只要把 HeapDump 文件下载下来用 Eclipse MAT 或者 JVisualVM 打开直接搜索关键词敏感信息一览无余。这个过程的门槛低到什么程度会用工具就行不需要多少安全知识。真实案例我记得很清楚。某个客户被攻击后排查发现攻击者的入口就是 Spring Boot 的/actuator/heapdump接口。攻击者下载了 heapdump 文件从里面翻出了数据库账号密码然后直连数据库拖走了全部用户表。整个过程行云流水比打任何漏洞都省事。事后他们统计这个 heapdump 文件有 800 多MB跑在公网上大半年没人知道。所以对于不太需要对外暴露监控接口的系统我的建议是Actuator 只在内网开放或者干脆禁用。如果确实需要至少要设置独立的端口和管理账号并配合网络访问控制绝不能让管理端口裸奔在公网。4.2 常见的信息泄露路径盘点HeapDump 只是信息泄露的冰山一角。我按泄露入口给信息泄露类问题做了个分类几乎覆盖了我在真实项目中见过的绝大多数情况错误信息回显数据库报错直接把 SQL 语句、库表结构、连接地址打在页面上。攻击者不费吹灰之力就完成了信息收集。接口返回多余字段后端把用户对象的全部属性返回给前端包括password_hash、id_card、phone这些不该出现的字段。前端根本不用但接口就是给了。敏感配置暴露application.yml、.env、web.config这些文件被错误地放进了静态目录或者备份文件残留被搜索引擎收录。调试接口未关闭Swagger 文档、接口调试模式、Mock 接口在生产环境开了一堆等于把系统的内部构造图贴在了大门上。第三方组件信息框架版本号、中间件版本号直接暴露在响应头或错误页里。这些信息虽然单个看不算严重但为攻击者匹配已知漏洞提供了便利。SSL/TLS 协议信息泄露CVE-2016-2183 就是代表服务器开放了较弱的加密套件泄露了加密协议的详细信息可能被用于降级攻击。这里面有意思的是很多信息泄露并非功能设计错误而是部署运维疏忽。比如把测试环境的配置文件同步到了生产或者本来只在内网用的调试开关忘了关。这提醒我们安全不仅是编码问题更是一个覆盖开发、测试、运维全流程的工程问题。4.3 何时该担心量化泄露未来信息热搜词里有个量化泄露未来信息这个词有两种理解一种是指量化交易系统因为权限配置不当导致策略代码或未来交易信号泄露另一种是指在大数据推荐场景下模型训练数据泄露导致预测结果提前暴露从而引发公平性问题。无论是哪种未来信息一旦被未授权方提前掌握危害都远大于普通历史数据泄露。在有量化交易系统实践经验的朋友交流中我了解到这类系统的信息泄露往往发生在日志打印、监控埋点、API 返回维度。比如交易策略产生信号的时候日志里打了完整的参数和信号方向而日志系统权限没管好内部员工就能看到。更隐蔽的是某些回测服务把未来函数写在了对外接口里调用者通过多次请求就能逆向推断出策略逻辑。应对思路也很明确量化系统按最小权限原则隔离数据和代码实盘信号和回测接口要严格分离日志脱敏和权限审计必须同步。4.4 信息泄露的防护姿势和自查清单信息泄露的防护本质上是一场数据最小化的运动。不要收集不需要的数据不要返回不需要的字段不要暴露不需要的接口。我总结了几个具体的操作建议统一响应封装后端接口统一返回 VO/DTO绝不把数据库实体直接序列化给前端。想返回哪些字段就在 VO 里声明哪些字段。日志与异常脱敏全局异常处理器拦截所有错误信息对外只返回服务器开小差了这种通用提示详细堆栈只打印到日志文件。日志框架里配置好脱敏规则手机号、身份证、密码这类关键词打码处理。管理端点收口Nginx 层做访问控制把 Actuator、Swagger、Druid 监控等端点限制在内网 IP 段外部访问一律 403。响应头清理隐藏或伪装 X-Powered-By、Server 等响应头减少中间件版本信息暴露。定期检查暴露面用扫描器做周期性全端口、全路径巡检重点看那些保姆级接口是不是又被打开了。如果你刚接手一个老项目先把信息泄露的自查清单过一遍错误页会不会爆堆栈接口返回是否包含敏感字段静态目录里有没有配置文件监控端点是否公网可达这几个问题只需要半天时间就能有个初步结论但能帮你避开大多数常见的泄露风险。5. 漏洞组合拳从信息收集到横向突破的完整链条5.1 三个漏洞如何被串联利用前面对三个漏洞是分别讲的但真实攻击中最可怕的是攻击者把它们串联起来形成攻击链。理解这条链比单独理解每一个漏洞都重要因为防御方往往逐点防御攻击方却是全程串联。典型的攻击路径长这样攻击者先利用目录遍历漏洞读取系统配置文件拿到数据库账号、密钥、内部服务地址接着利用信息泄露接口收集更多内部信息包括管理员接口的路径和参数规则最后利用越权漏洞用普通账号调用管理员接口实现提权和数据窃取。这条攻击链最大的特点是每一步单独看可能都不致命目录遍历漏一个配置文件信息泄露漏一个调试接口越权漏一个非核心功能单看危害评级可能都是中低危但组合起来就是完整的高危渗透路径。这也是我在写报告时一直强调的不要孤立评估漏洞危害要站在攻击链的视角看问题。5.2 用攻击路径思维做防御理解了攻击链防御思路就清晰了。很多团队做安全是头痛医头发现目录遍历就修目录遍历发现越权就补越权却忽视了链路中的信息支撑才是最需要切断的环节。我有一次做红队演练目标系统没有直接的高危漏洞单点看防护做得挺到位。但我在测试中翻到了一份内部 API 文档上面详细标注了所有管理接口的地址和参数。顺着这份文档我用一个低权限测试账号直接调用了几个预期外的接口轻松拿到管理权限。事后复盘如果他们对文档信息泄露做好管控这次攻击在第一步就会终止。防御层面我特别推荐团队做一次攻击路径模拟。假设你是攻击者从零开始画一张攻击路径图标注出每一步需要什么信息、利用什么漏洞、达到什么效果。然后审视哪些步骤是可以被阻断的、哪些信息是可以不被暴露的、哪些权限是可以不赋的。把攻击路径中的关键节点卡死即使某些漏洞无法彻底修复攻击者也很难串联成完整的攻击链。5.3 纵深防御的落地建议纵深防御Defense in Depth这个词说出来容易落地才是关键。我给它做了个通俗的拆解就算某一层被攻破也不能让它一路通到底。具体来说就是网络层分区分域管理内网服务不暴露公网核心数据库只允许应用服务器访问。哪怕应用被攻破攻击者也不能直接连数据库。应用层输入校验、身份认证、权限校验、输出脱敏每一层独立实现不互相依赖。校验逻辑统一封装不散落在业务代码里。数据层敏感字段加密存储数据库账号最小权限分配不用 root 连库。即使拿到配置文件也推不开数据的大门。运维层日志全量记录、告警实时通知、周期安全巡检。攻击行为尽可能留下痕迹让防守方有机会发现和响应。这套体系听着复杂实际落地时可以分阶段推进。第一步先把公网暴露面收一收第二步做应用层权限校验和输出脱敏第三步再补日志审计和告警。循序渐进每步都能看到实际效果。6. 常见问题排查与加固速查6.1 三类问题高频场景速查表鉴于项目排期紧张、安全测试时间有限我把高频排查点整理成了一张速查表开发和安全测试都能直接对着看。漏洞类型高危场景特征快速验证方法优先修复方案目录遍历文件下载/预览接口存在文件名参数参数中拼接../../etc/passwd试读规范化路径后校验前缀或改用 ID 映射水平越权接口路径含用户ID/订单ID且无归属校验切换两个账号A/BA的Token访问B的资源业务代码增加资源归属者 当前登录者校验垂直越权管理接口无角色标注前端菜单隐藏登录普通账号直接调用管理接口URL/抓包重放后端接口强制RequiresPermissions等注解鉴权HeapDump泄露Actuator 相关端点公网可达访问/actuator/heapdump看是否直接下载内网隔离、独立端口、身份认证必要时禁用错误信息泄露页面直接显示异常堆栈/ SQL 语句触发一个必现异常观察响应体全局异常处理器统一兜底堆栈写日志文件6.2 测试中的经验与教训做了一堆项目我踩过的坑比见到的漏洞还多挑几个有代表性的分享一下。第一个坑是只测正向不测反向。很多测试人员拿着工具跑一遍自动化扫描就交差了但真正的高危漏洞往往藏在业务逻辑的反向路径里。比如下载功能正向下载没问题但你试过把文件名参数改成一个超大值、一个不存在的值、一个绝对路径吗改参数、改请求方法、改 Content-Type这些反向操作才是人工测试的核心价值。第二个坑是忽略权限上下文。测试越权时很多人的习惯是退出登录直接访问接口但有些系统的鉴权逻辑是只要带上合法 Token 就算登录用户这时候你用一个低权限账号的 Token 去访问管理员接口才能准确验证垂直越权。未登录和已登录是两个不同的测试场景都覆盖到才算测全。第三个坑是忽略文件型信息泄露。很多安全测试只关注应用层漏洞却忘了看看 Web 目录下有没有备份文件、源码压缩包、SQL 导出文件。这类问题用目录扫描器就能发现一大半企业在自查时应优先做。真正的攻击者第一步往往就是拿目录扫描器扫路径扫到www.zip、backup.sql就意味着拿下了整个系统的底牌。6.3 安全意识技术与流程双管齐下写了这么多技术层面的内容最后绕不开人这个因素。安全漏洞的背后最终还是会追溯到人的认知盲区。单纯在代码层面打补丁永远赶不上攻击者的思路变化。这也是我特别认同安全左移理念的原因——在需求评审阶段就想清楚权限模型、数据敏感级别、暴露面大小比事后补救省太多事。我给的直接建议有两条。第一团队内部定期做安全 coding 培训不是讲枯燥的理论而是拿自己项目里真实出现过的漏洞做案例分析告诉开发人员这段代码为什么有问题、正确写法是什么。第二把安全 checklist 融入到 CI/CD 流水线每次发版前自动跑一遍基础安全扫描高危问题直接拦截发布。这两件事做起来不难但坚持做下去团队的安全水位会肉眼可见地提升。根据我个人的经验安全建设没有一劳永逸的终点。系统在迭代、框架在升级、攻击手法也在进化唯一能保证系统长久安全的方法就是不断地测试、修复、再测试让它成为一个持续改进的循环。最后再分享一个小技巧在做完所有修复之后把最初的攻击路径重新走一遍确认每一步都被有效阻断这种回归测试虽然简单但往往比新增任何安全功能都管用。