背景 越权问题在 Web 系统里一直很常见，尤其是业务接口越来越细、前后端分离之后，很多权限判断会被分散到 Controller、Service、网关、注解或数据层过滤里。表面上看接口返回正常、鉴权也存在，但只要某个对象级权限校验缺失，就可能出现用户访问他人订单、工单、文件、组织数据的情况。 这类问题的特点是：不一定依赖复杂漏洞利用，更多来自业务逻辑疏漏。做代码审计时，如果只看是否登录、是否有角色，很容易漏掉“当前用户是否有权操作当前资源”这个核心问题。 典型场景 下面以一个常见的后台业务系统为例：用户登录后可以查看自己的项目详情，接口大致如下： GET /api/project/detail?id=10086服务端代码中可能已经做了登录校验，例如通过 Token 获取当前用户身份： @GetMapping("/detail")
public ProjectDTO detail(@RequestParam Long id) {
LoginUser user = SecurityContext.getCurrentUser();
return projectService
背景文件上传是 Web 系统里很常见的功能，也是代码审计中高频出现问题的位置。头像上传、附件上传、工单图片、富文本编辑器、导入导出等模块，都可能因为校验不完整、存储路径不合理或解析配置错误，变成安全风险点。这篇文章整理一次典型代码审计中的文件上传问题分析过程，重点放在成因、审计方法和修复思路上。内容不会提供攻击利用引导，更多是帮助开发和安全同学判断一个上传模块是否可靠，以及如何把风险降下来。常见场景审计中遇到的上传逻辑通常类似下面几类：用户头像、身份证明、资质材料等图片上传。后台管理系统中的附件上传、模板导入。富文本编辑器内置上传接口。工单、论坛、评论系统中的图片或文件附件。第三方对象存储直传或后端中转上传。看起来都是普通业务功能，但只要文件类型判断、文件名处理、目录权限或 Web 容器解析规则里有一个环节出问题，就可能产生严重后果。问题成因文件上传漏洞很少是单点问题，更多是多个弱点叠加造成的。常见成因包括：只检查前端限制，没有在服务端重新校验。只根据文件后缀判断类型，没有校验文件内容。允许用户控制保存文件名或保存路径。上传目录位于 Web 可执行目录下。Web 容器对特殊后缀、双后缀
文件上传类问题经常被简单归结为“校验扩展名不严格”，但在实际项目中，风险通常来自一整条处理链路：请求解析、文件名规范化、类型判断、临时目录落盘、压缩包解包、对象存储上传、静态文件映射以及后续异步处理。单点修补往往只能降低风险，不能替代完整的边界设计。本文以一次典型的代码审计场景为背景，整理文件上传功能中比较容易被忽略的风险点，并给出适合落地到研发流程中的审计和修复方法。示例均面向隔离测试环境和防守性验证，不涉及对真实系统的攻击操作。一、先明确需要保护的边界审计上传功能之前，建议先回答四个问题：上传文件最终保存在哪里，是本地目录、共享目录，还是对象存储？上传后的文件是否会被 Web 服务器直接映射访问？文件是否会进入图片解析、文档预览、压缩包解包或杀毒扫描流程？上传者能否影响最终文件名、目录层级、Content-Type 或处理参数？这几项决定了风险类型。文件本身不一定需要被服务器直接执行，才会产生安全问题。例如，路径处理缺陷可能导致覆盖应用配置；压缩包中的符号链接可能影响解包结果；图片解析器缺陷可能在异步处理阶段触发；对象存储的公开策略错误则可能造成敏感文件泄露。二、审计时不要只看扩展
.jpg.9e5b93ecbee2891469035a26c1fc0c39.jpg)
