跳转到帖子
应急响应中心

应急响应中心

保存

应急响应中心部落格

应急响应中心的俱乐部博客

  • 篇帖子

    283

  • 篇意见

    0

  • 次查看

    2319

关于此博客

从一次后台文件上传审计看安全边界：类型校验、存储隔离与解析风险

文件上传是代码审计里很常见的入口，问题往往不在“是否允许上传”，而在上传后的处理链路：校验依据是否可靠、文件是否进入可解析目录、访问路径是否可控、后续异步处理是否信任了用户文件。本文整理一次后台上传功能审计中的经验，重点放在风险识别和加固方法，不涉及攻击利用细节。 背景 不少业务后台会提供头像、附件、合同、导入模板等上传能力。研发侧通常会做扩展名限制，例如只允许 jpg、png、pdf、xlsx。但从安全角度看，仅靠扩展名判断并不够，常见风险包括： 只校验文件名后缀，未校验文件真实类型。 上传目录位于 Web 可解析路径下，导致非预期解析。 文件名由用户控制，存在覆盖、路径穿越或特殊字符问题。 上传后由图片处理、文档转换、压缩解压等组件继续处理，引入二次风险。 权限控制只放在前端页面，接口层缺少鉴权和对象级授权。 这类问题单点看不一定严重，但多个薄弱环节叠加后，往往会变成高风险入口。 审计场景 审计对象是一个常见的 Java Web 后台，上传接口大致逻辑如下：用户登录后选择文件，后端读取 MultipartFile，检查后缀是否在白名单内，然后把文件保存到配置的 uploadPath
T0xfce

从代码审计到修复：一次 SSRF 风险的完整排查思路

背景 SSRF（Server-Side Request Forgery，服务端请求伪造）是 Web 安全里比较常见但也容易被低估的一类问题。它的本质并不复杂：应用服务端根据用户输入去发起网络请求，如果缺少边界控制，攻击者就可能借服务端的网络位置访问原本不该暴露的内部资源。 这类问题在真实项目里经常出现在以下场景：远程图片抓取、Webhook 回调、URL 预览、文件导入、PDF 渲染、第三方接口转发、云存储地址校验等。很多业务代码看起来只是“帮用户请求一个 URL”，但服务端所在网络往往比普通用户更靠近内网、元数据服务、管理接口或中间件。 典型问题场景 假设某个业务提供“根据 URL 抓取图片并保存”的功能，后端代码大致如下： public byte[] fetchImage(String url) throws IOException { URL target = new URL(url); HttpURLConnection conn = (HttpURLConnection) target.openConnection(); conn.setConnect
T0xfce

从一次代码审计看文件上传链路的防护盲点

背景 文件上传是 Web 系统里很常见的功能，但也是长期高发的问题点。很多系统在设计时只关注“能不能上传成功”，对上传后的存储、访问、解析、权限边界考虑不足。实际审计里，单点校验做得再多，只要链路上某个环节处理不当，仍然可能引出越权访问、敏感文件泄露、存储型 XSS，甚至在特定部署环境下触发脚本解析风险。 这篇文章不讨论如何利用漏洞拿权限，而是从代码审计和防护设计角度，整理一条文件上传链路中常见的风险点，以及可以落地的检查和加固方法。内容偏工程实践，适合用于自查上传模块、做安全评审或补齐测试用例。 典型场景 常见业务场景包括头像上传、附件上传、工单截图、富文本图片、合同文件、导入模板等。它们看起来差别很大，但上传链路一般都包含以下步骤： 客户端选择文件并提交请求。 服务端接收 multipart/form-data 请求。 校验文件大小、扩展名、MIME 类型等信息。 生成文件名并写入本地磁盘、对象存储或内网文件服务。 返回文件 URL、文件 ID 或预览地址。 后续通过下载、预览、转码、缩略图等接口访问。 审计时不要只看上传接口本身，下载、预览、转码和静态资源解析方式同样重要。很多问
T0xfce

一次 Java 文件上传链路的代码审计：从入口校验到落盘风险

背景 文件上传是代码审计里很常见的一类入口，问题不一定都来自“上传 WebShell”这种典型场景。实际项目里更多见的是：扩展名校验不一致、MIME 判断过度信任、文件名拼接不规范、临时目录权限过大、对象存储回源策略不清晰，以及上传后的异步处理缺少边界控制。 这篇文章整理的是我在审计 Java Web 项目上传链路时常用的一套检查思路。重点放在如何识别风险、如何验证和修复，不提供针对真实站点的攻击操作。 问题场景 一个典型的上传接口大概长这样：前端选择文件，后端 Controller 接收 MultipartFile，校验后保存到本地目录或对象存储，再把访问地址写入数据库。 表面上看逻辑很简单，但真正容易出问题的是链路中每个环节的“假设”： 认为前端限制了后端就不用再校验。 认为 Content-Type 是可信的。 认为取到的原始文件名可以直接使用。 认为只要目录不在 webroot 下就安全。 认为图片压缩、文档解析、杀毒扫描一定不会引入新风险。 技术分析 审计上传功能时，我一般按“入口参数、类型判断、文件名处理、存储位置、访问方式、后处理任务”六个
T0xfce

一次 WebShell 事件的复盘方法：从日志关联到代码侧加固

背景 这几年在做应急和代码审计时，遇到的 WebShell 事件并不少。真正麻烦的地方往往不是“找到一个可疑文件”这么简单，而是要回答几个更关键的问题：入口在哪里、权限边界是否被突破、是否存在二次落点、代码侧怎么修、日志证据能否支撑结论。 这篇整理的是一套偏实战的复盘思路，适合用于企业内部排查、靶场复现后的总结，或者在代码审计中验证上传、解析、模板、反序列化等风险点。内容只讨论防守视角的分析与加固，不涉及未授权入侵、持久化控制或横向移动操作。 典型场景 某业务系统出现异常外联告警，安全设备提示 Web 目录下存在疑似脚本木马。初步看是上传目录里多了一个扩展名伪装的脚本文件，访问时间与某个后台上传接口请求时间接近。 这类事件中常见的入口包括： 文件上传校验不严，仅检查前端或 Content-Type。 上传目录被 Web 容器当作脚本目录解析。 富文本、附件、头像、导入功能未做统一安全处理。 历史遗留测试接口未鉴权或弱鉴权。 第三方组件存在已知漏洞，攻击者借此写入文件。 复盘时不建议一开始就只盯着木马文件本身，应优先建立时间线，把“请求入口、文件落点、执行行为、外联行为、权限影响”串起来
T0xfce

一次 Java Web 越权问题的代码审计思路整理

背景 越权漏洞在业务系统里很常见，尤其是后台管理、工单、订单、租户数据这类场景。它不像 SQL 注入、命令执行那样容易通过单点 payload 触发，更多依赖业务关系和权限模型理解。实际审计中，越权问题经常隐藏在看起来“功能正常”的接口里：接口能返回数据，参数也符合预期，但缺少对当前登录用户和目标资源之间关系的校验。 这篇文章整理一次 Java Web 项目中常见的越权审计方法，重点放在可复用的排查思路上，不涉及真实目标，也不提供任何未授权攻击引导。适合用于企业内部系统自查、代码评审和安全测试流程建设。 问题场景 假设系统中存在工单模块，用户可以查看自己提交的工单，管理员可以查看全部工单。常见接口形式如下： GET /api/ticket/detail?id=10086如果后端只根据 id 查询工单详情，而没有校验当前登录用户是否有权限访问该工单，就会出现水平越权。如果普通用户可以通过调整参数查看其他用户工单，问题就比较明显。 类似问题也可能出现在以下接口中： 订单详情：根据 orderId 查询订单，但未校验订单归属。 文件下载：根据 fileId 下载附件，但未校验附件所属业务对象
T0xfce

从代码审计到运行时防护：一次 Java 反序列化风险排查实践

背景 Java 反序列化问题在企业系统里并不新，但它长期存在的原因往往不是“没人知道危险”，而是调用链分散、历史组件复杂、边界校验缺失，以及一些框架默认行为不够直观。最近整理内部老项目安全基线时，发现几类典型风险：接口直接接收序列化对象、缓存中间件存储 Java 原生对象、消息队列消费端缺少类型约束、遗留 RPC 框架暴露了不必要的反序列化入口。 这篇文章不讨论攻击利用细节，只分享一套偏防守视角的排查方法：如何在代码审计中定位风险点，如何构造安全的本地验证场景，如何做运行时加固，以及上线前后应该关注哪些指标。 问题场景 典型业务场景如下： 老系统使用 ObjectInputStream 从文件、缓存或网络流中恢复对象。 内部接口为了“方便扩展”，将请求体保存为 Java 序列化字节流。 Redis、MQ、RPC 框架中存在二进制对象传输，消费端默认信任来源。 项目依赖中包含复杂 gadget 链相关组件，例如部分历史版本的 commons-collections、groovy、spring 生态组件等。 从防守角度看，风险不只在于某一行 readObject()，而在于“不可信输入 +
T0xfce

从一次代码审计看文件上传链路的常见风险与加固思路

背景 文件上传是 Web 系统里很常见的功能，头像、附件、报表导入、工单图片、富文本资源都离不开它。也正因为入口多、链路长，上传功能经常成为漏洞审计里的高频风险点。 这篇文章整理的是我在日常代码审计和漏洞复现中比较常见的一类问题：上传接口本身看起来做了扩展名校验，但在存储、访问、解析、权限控制等环节存在缺口，最终形成安全风险。文章重点放在防御视角和审计方法，不提供非法利用或攻击控制类操作。 典型场景 一个常见的业务上传链路大致如下： 前端限制文件类型，例如只允许 jpg、png、pdf、docx。 后端接收 multipart/form-data 请求。 后端检查文件扩展名或 Content-Type。 文件保存到本地目录、对象存储或共享存储。 数据库记录文件名、路径、上传人、业务 ID。 用户通过下载接口或静态资源路径访问文件。 问题往往不只出现在“能不能上传某个后缀”，而是出现在多个环节叠加之后。例如：文件名未规范化、上传目录可被脚本引擎解析、下载接口没有鉴权、对象存储桶策略过宽、临时文件处理不当等。 风险点拆解 1. 仅依赖扩展名或 Content-Type 校验 很多项目的上传
T0xfce

一次 WebShell 入侵事件的复盘：从日志关联到代码审计

背景 最近整理了一起比较典型的 WebShell 入侵事件。事件本身不复杂：业务侧发现服务器上出现异常 PHP 文件，且访问日志中存在可疑请求。比较有价值的是，这类事件在中小型 Web 系统里很常见，攻击入口往往不是高危 0day，而是上传校验不严、历史组件漏洞、后台弱口令、临时调试接口遗留等问题叠加。 本文主要从防守视角做一次完整复盘：如何确认入侵范围、如何从日志中还原关键时间线、如何定位 WebShell 来源，以及如何通过代码审计补上缺口。内容不涉及攻击利用细节，更侧重排查方法和加固思路。 场景概述 业务环境大致如下： Linux 单机部署，Nginx + PHP-FPM。 业务代码为 PHP，存在后台管理功能和文件上传功能。 站点目录包含历史版本代码和若干临时测试文件。 无集中日志平台，只有本机访问日志、错误日志、系统日志。 最初告警来自运维巡检：Web 根目录下发现一个最近修改的 PHP 文件，文件名伪装成图片缓存，例如 cache_img.php。文件内容经过简单混淆，包含可疑的动态执行逻辑。 第一步：先做现场保护 很多事件排查一开始容易直接删除文件、重启服务，这样会破坏时
T0xfce

从一次代码审计看文件上传漏洞的完整防护链路

背景文件上传是 Web 系统里很常见的功能：头像、附件、导入文件、工单截图、富文本图片等都会涉及。它看起来只是一个业务功能，但在实际审计和应急里，上传点经常是漏洞链的入口。比较典型的风险包括：上传可执行脚本、路径穿越覆盖文件、解析差异导致脚本执行、图片二次渲染缺失导致恶意内容保留、对象存储权限配置不当，以及上传后的文件被业务再次处理时触发解析漏洞。这篇文章不讨论攻击利用细节，而是从代码审计和防护落地的角度，整理一套比较稳妥的检查思路。适合在做 Web 安全评审、上线前审计、历史系统加固时作为参考清单。常见问题场景审计上传功能时，我通常不会只看“是否限制后缀”。真实项目里，很多风险是多点叠加造成的。下面这些场景比较常见：只在前端限制文件类型，后端没有严格校验。后端仅通过文件后缀判断类型，未检查 MIME、文件头和实际内容。上传目录位于 Web 可访问路径下，并且服务器可能解析动态脚本。文件名直接使用用户输入，存在路径穿越、覆盖、特殊字符解析问题。允许用户控制保存路径、回调地址、对象存储 key。图片上传后没有重新编码，原始文件被直接保存。导入类功能会对上传文件进行解压、解析 XML、解析
T0xfce

从一次代码审计看文件上传接口的风险识别与加固

背景文件上传是 Web 系统里很常见的功能，但也是代码审计中高频出问题的位置。很多漏洞并不是因为开发完全没有做校验，而是校验点分散、信任了客户端参数、存储路径设计不合理，最后形成了可被利用的风险。这篇文章整理一套偏实战的审计思路，重点放在如何识别上传接口中的安全缺陷，以及如何做工程化加固。内容以防护和复盘为主，不提供针对真实目标的攻击操作。典型场景一个业务系统提供头像、附件、工单截图等上传能力。常见接口形态大致如下：POST /api/file/upload Content-Type: multipart/form-data [email protected] type=avatar后端收到文件后，通常会做几件事：检查文件大小检查文件扩展名生成存储路径保存到本地磁盘或对象存储返回可访问 URL问题往往出在这些步骤之间的边界条件上。例如扩展名校验不等于内容校验，文件保存目录不等于安全目录，返回 URL 可访问不等于应该具备执行能力。审计关注点1. 扩展名校验是否可靠很多代码只通过文件名后缀判断类型，例如：String filename = file.getOriginalFilename
T0xfce

从一次代码审计看 SSRF 风险的识别、验证与加固

背景 SSRF（Server-Side Request Forgery，服务端请求伪造）在真实业务里并不少见，尤其常出现在“服务端代请求”的功能中，比如图片抓取、URL 预览、Webhook 回调测试、文件远程导入、接口连通性检测等。 这类问题的麻烦点在于：表面上只是服务端访问一个用户传入的 URL，但如果缺少边界控制，攻击面会从公网 URL 扩展到内网地址、云元数据服务、管理端口，甚至变成横向探测入口。本文不讨论攻击利用链，只从代码审计和修复角度整理一套可复用的方法。 典型场景 在一次 Java Web 项目审计中，看到类似功能：用户提交一个图片 URL，后端下载后生成缩略图并缓存。代码简化后如下： public byte[] fetchImage(String url) throws IOException { URL target = new URL(url); HttpURLConnection conn = (HttpURLConnection) target.openConnection(); conn.setConnectTimeout(3000)
T0xfce

从代码审计到复现验证：一次 Spring Boot 接口越权问题的排查思路

背景在日常代码审计里，越权问题一直是比较容易被低估的一类漏洞。它不像命令执行、反序列化那样“显眼”，但在业务系统中影响往往很直接：普通用户可以查看或修改其他用户的数据，运营角色可以触达管理员接口，或者租户之间的数据边界被打穿。这篇文章整理一次比较典型的 Spring Boot 接口越权排查过程，重点放在审计思路、复现验证和修复建议上。文中涉及的接口和字段都做了简化处理，适合用于内部安全评审、研发自查和测试环境验证，不涉及真实系统攻击。问题场景某业务系统采用前后端分离架构，后端是 Spring Boot，认证方式为 JWT。用户登录后，前端会在请求头中携带 token，后端通过拦截器解析用户身份。审计时发现一个订单详情接口，表面上已经要求登录，但没有进一步校验订单归属关系：GET /api/order/detail?id=10086 Authorization: Bearer eyJhbGciOi...接口返回订单基础信息、收货信息、支付状态等敏感数据。如果后端只根据 id 查询订单，而不判断该订单是否属于当前登录用户，就可能形成水平越权。代码结构简化项目里常见的分层结构如下：cont
T0xfce

一次文件上传漏洞复盘：从代码审计到修复加固

背景 文件上传是 Web 系统里很常见的功能，头像、附件、工单截图、导入文件都可能涉及。它的问题也比较典型：业务上看只是“保存一个文件”，安全上却同时涉及文件类型识别、存储路径、访问权限、解析行为、后续处理链路等多个环节。 这篇文章整理一次比较典型的文件上传漏洞复盘。场景来自日常代码审计和测试环境验证，重点放在如何识别风险、如何验证影响、以及如何做可靠修复。文中不会涉及真实目标攻击，也不会给出用于未授权利用的操作引导。 问题场景 某业务系统提供附件上传接口，用于上传工单图片和说明文档。前端限制只允许 jpg、png、pdf，后端也做了扩展名判断。初看逻辑比较完整，但实际审计时发现几个问题叠加在一起： 后端只依赖原始文件名后缀判断类型。 上传目录位于 Web 可访问目录下。 保存文件名部分来自用户输入，未做充分规范化处理。 服务端未统一关闭上传目录的脚本解析能力。 文件访问 URL 直接返回给前端，缺少权限校验。 单个问题未必立即造成严重影响，但组合起来会显著放大风险。例如，攻击者可能上传伪装文件、构造异常文件名、覆盖同名文件，或者让不该公开的附件被直接访问。 代码审计切入点 审计上传功
T0xfce

从代码审计角度梳理文件上传风险：常见缺陷、验证思路与加固实践

背景 文件上传是 Web 系统里非常常见的功能，头像、附件、工单截图、导入模板都会用到。它看起来只是一个业务功能，但在安全审计里经常能看到问题：后端只校验前端参数、扩展名判断不严谨、上传目录可执行、对象存储权限配置过宽、文件解析链路存在差异等。 这篇文章不讨论利用细节，也不提供攻击性操作步骤，主要从代码审计和防守视角整理一套相对通用的检查方法。适合做内部安全评审、研发自查、上线前验收，也适合复盘历史文件上传类问题时使用。 典型场景与风险边界 常见上传入口大致可以分为几类： 用户资料类：头像、实名认证图片、个人附件。 业务流转类：工单附件、审批附件、合同扫描件。 数据导入类：Excel、CSV、压缩包、批量素材。 后台管理类：模板上传、主题资源、插件资源。 开放接口类：通过 API 上传图片、视频、日志文件。 从风险看，文件上传问题不只等于“上传脚本”。更常见的风险包括： 上传恶意内容后被业务系统解析，引发服务端处理异常。 上传超大文件或压缩炸弹，造成磁盘、内存、CPU 资源耗尽。 文件名未规范化，引发路径穿越、覆盖文件、日志污染。 上传后可被公网直接访问，导致敏感附件泄露。 对象存储
T0xfce

一次 Java Web 任意文件读取漏洞的代码审计与修复思路

背景 任意文件读取是 Java Web 项目里比较常见、但容易被低估的一类问题。它不一定直接导致代码执行，但在真实环境中，经常会被用来读取配置文件、密钥、数据库连接信息、日志、源码片段，进而扩大影响面。 这篇文章整理一个偏通用的审计案例：某业务系统提供“附件预览 / 日志下载 / 模板读取”能力，后端根据前端传入的文件名或路径读取服务器本地文件并返回。代码本身看起来只是普通文件下载接口，但如果路径处理不严谨，就可能形成任意文件读取。 文章重点放在审计思路、漏洞成因、复现方法和修复要点，不涉及非法利用场景。 问题场景 很多系统会有类似接口： 下载用户上传的附件 预览导入模板 读取某个目录下的日志文件 根据文件名返回静态资源 常见的后端写法是从请求参数中取出文件名，然后拼接到固定目录下： String fileName = request.getParameter("fileName"); File file = new File(baseDir + "/" + fileName); try (InputStream in = new FileInputStream(file)) {
T0xfce

一次内网 Web 资产代码审计中的 SSRF 风险梳理与加固思路

背景最近整理一批内网 Web 资产的代码审计记录，发现 SSRF 仍然是比较容易被低估的问题。原因不复杂：很多业务都需要“服务端代请求”，比如图片抓取、Webhook 回调、URL 预览、文件转存、在线文档导入等。开发侧往往只关注功能是否可用，安全侧如果只看入口参数，也容易漏掉后续重定向、DNS 解析、协议支持等细节。这篇文章不讨论攻击利用，也不提供对真实目标的操作方法，只结合代码审计和本地复现环境，梳理 SSRF 风险的常见触发点、审计思路和加固方式。重点放在长期可复用的方法上，适合做内部安全基线或代码审计 checklist。典型场景在 Web 业务中，SSRF 常见于以下功能：用户提交 URL，服务端抓取图片、头像、封面或网页标题。Webhook、回调地址、通知地址由用户配置。远程文件导入，例如从 URL 下载文档、压缩包、配置文件。富文本编辑器自动解析外部资源。微服务网关或代理类接口，由后端根据参数拼接请求。这些功能的共同点是：服务端会根据用户可控输入发起网络请求。一旦缺少严格限制，服务端就可能被迫访问不该访问的地址，例如内网服务、云平台元数据接口、管理后台或本机监听端口。问题
T0xfce

从一次代码审计看 Spring Boot 接口越权的定位与修复

背景 接口越权是 Web 系统里最常见、也最容易被低估的问题之一。它不像 SQL 注入、RCE 那样有明显的危险函数或特征 payload，很多时候只是业务代码里少了一次用户身份与资源归属关系的校验。 最近整理一个 Spring Boot 项目的代码审计记录，发现其中几类越权问题具有代表性：查询接口只校验登录态，不校验数据归属；更新接口信任前端传入的 userId；管理接口只做菜单隐藏，没有后端权限判断。这里把审计思路、定位方式和修复建议整理出来，适合做长期自查清单。 典型场景 项目采用常见的 Spring Boot + MyBatis 架构，认证通过 JWT 完成。用户登录后，后端从 token 中解析 userId，并放入上下文。理论上，业务接口应该基于当前登录用户判断其是否有权访问目标资源。 但在实际代码里，经常会看到下面几类写法： 接口只判断用户是否登录，未判断资源是否属于当前用户。 查询、修改、删除接口直接使用前端传入的 id。 DTO 中包含 userId、tenantId、roleId 等敏感字段，并被直接用于数据库操作。 后台管理接口依赖前端路由控制，后端缺少角色或权限
T0xfce

从一次文件上传问题看 Web 业务的安全边界设计

背景 文件上传是 Web 业务里很常见的功能，头像、附件、工单截图、富文本图片都会涉及。它看起来只是一个普通交互，但长期来看，上传点往往是安全边界最容易被忽略的位置：业务希望用户能自由提交文件，安全侧又必须确保这些文件不会变成脚本、钓鱼页面、恶意文档或横向移动入口。 这篇文章不讨论攻击利用细节，而是从代码审计和防护落地的角度，整理一次常见文件上传风险的分析思路。适合做安全自查、研发改造和上线前 review 时参考。 典型场景 很多系统的上传逻辑大致如下： 前端限制文件后缀，例如只允许 jpg、png、pdf。 后端接收 multipart 请求，把文件保存到某个静态目录。 数据库记录原始文件名和访问 URL。 用户后续可以通过 URL 直接访问该文件。 问题通常出在“前端校验”和“后端保存”之间。前端限制只能提高体验，不能作为安全边界；后端如果只判断文件名后缀，也容易忽略文件内容、存储位置、访问方式、权限隔离等问题。 问题分析 做文件上传审计时，我一般不会只盯着一个 if 判断，而是沿着文件生命周期看完整链路： 接收阶段：是否限制大小、类型、数量、频率。 校验阶段：是否只依赖后缀、C
T0xfce

从一次代码审计看文件上传接口的常见风险与加固思路

背景 文件上传是 Web 系统里很常见的能力，头像、附件、导入模板、工单截图都会用到。也正因为它和文件系统、对象存储、解析器、访问控制都有关，实际审计中经常成为风险集中点。 这篇文章整理一次偏真实场景的代码审计思路，重点放在如何识别上传链路中的设计缺陷，以及如何做可落地的修复。内容以防御和审计为主，不涉及未授权入侵或恶意利用引导。 典型场景 某业务系统提供附件上传接口，后端使用 Java/Spring Boot，文件最终落到本地磁盘或对象存储。简化后的接口逻辑大致如下： @PostMapping("/upload") public String upload(@RequestParam("file") MultipartFile file) throws Exception { String originalName = file.getOriginalFilename(); String suffix = originalName.substring(originalName.lastIndexOf(".")); String filename = UUID.
T0xfce

从 URL 抓取功能看 SSRF：一次代码审计中的风险识别与修复实践

服务端请求伪造（SSRF）并不只存在于“图片抓取”这类明显场景中。Webhook 校验、远程文件导入、PDF 转换、头像代理、第三方接口探测等功能，只要服务端会根据用户输入发起网络请求，就可能成为审计重点。SSRF 的风险不在于某一个危险函数，而在于“用户可控地址”和“服务端网络权限”发生了组合。即使应用没有直接暴露敏感接口，只要部署环境能够访问内网管理面、云平台元数据服务或受信任的内部系统，问题的影响范围也可能被放大。一、审计场景与问题边界本文以一个常见的远程资源导入接口为例。接口接收一个 URL，服务端下载资源后进行解析或保存：POST /api/import { 'source': ' /> }初步审计时，很多人只会检查是否使用了黑名单，例如拦截 localhost、127.0.0.1 或某些内网网段。这种方式通常不够可靠，原因包括：URL 解析存在差异，用户名、端口、编码和 IPv6 表示形式可能导致校验对象与实际连接目标不一致。域名解析结果可能变化，校验阶段与连接阶段不一定使用同一个地址。HTTP 客户端可能自动跟随重定向，初始地址安全不代表最终地址安全。应用所
T0xfce

从一次文件上传问题看 Web 漏洞复现与修复验证

背景 文件上传是 Web 安全里很常见的一类问题，但真实项目中它往往不是单点漏洞，而是由扩展名校验、MIME 判断、存储路径、访问权限、解析规则、鉴权边界等多个环节共同决定风险。很多团队在修复时只补了一处黑名单，短期看似有效，后续换个网关、改个对象存储策略或新增预览功能，又会把问题带回来。 这篇文章整理一套偏实战的复现和修复验证思路，适合用于代码审计、安全测试和研发自查。内容只讨论在授权环境中的验证方法，不涉及未授权入侵、持久化控制或恶意利用。 典型场景 一个业务系统提供头像、附件、工单截图等上传能力。接口大致具备以下特征： 前端限制文件类型，例如只允许 jpg、png、pdf。 后端接收 multipart/form-data 请求。 文件保存到本地目录或对象存储。 上传成功后返回一个可访问 URL。 部分业务还提供在线预览、缩略图生成或文件转码。 风险通常不只来自“能否上传某个后缀”，还包括上传后的文件是否会被解释执行、是否能被跨权限读取、是否可覆盖已有文件、是否能触发服务端解析组件漏洞等。 问题拆解 做文件上传审计时，我通常按以下几个维度拆： 检查点关注内容常见问题文件类型判断扩
T0xfce

一次图片代理服务 SSRF 风险排查与加固记录

背景 很多业务为了避免前端直接加载第三方图片，会做一个“图片代理”或“远程图片转存”服务：用户提交一个图片 URL，后端去拉取资源，校验类型后存储到对象存储或返回给前端。这类功能看起来很普通，但也是 SSRF 问题高发点。 最近在做一轮代码审计时，遇到一个典型场景：接口只判断了 URL 是否以 或 开头，然后直接由服务端发起请求。业务本意是转存头像和文章配图，但如果缺少边界控制，就可能访问到内网地址、云厂商元数据地址或本机管理端口。 问题场景 简化后的接口逻辑大概如下： POST /api/image/fetch Content-Type: application/json { "url": " } 后端代码逻辑类似： public String fetchImage(String url) { if (!url.startsWith(" && !url.startsWith(" { throw new IllegalArgumentException("invalid url"); } Respons
T0xfce

一次 Java Web 越权问题的代码审计复盘：从接口梳理到修复验证

背景 越权问题在业务系统里很常见，尤其是后台管理、工单、订单、租户数据这类接口。它不像 SQL 注入或命令执行那样容易通过特征命中，更多依赖对业务对象、权限模型和代码路径的理解。本文整理一次偏通用的 Java Web 越权审计思路，重点放在如何定位问题、如何验证影响、以及如何把修复做扎实。 为了避免涉及具体目标，下面使用一个简化的业务场景：系统中存在“项目 Project”，不同用户只能访问自己所属租户或被授权的项目。后端使用 Spring Boot + MyBatis，登录态通过 JWT 或 Session 识别用户身份。 问题场景 典型风险接口如下： GET /api/project/detail?id=1001 GET /api/project/task/list?projectId=1001 POST /api/project/update { "id": 1001, "name": "new-name", "description": "xxx" }从接口形态看，资源 ID 直接由前端传入。如果后端只根据 id 查询或更新，而没有校验当前用户是否有该资源权限，就可
T0xfce

一次 Java Web 任意文件读取漏洞的代码审计与修复思路

背景 任意文件读取在 Java Web 项目里并不少见，尤其是下载接口、日志查看接口、静态资源代理接口、模板预览接口这几类功能。它的危害取决于部署环境和可访问文件范围：轻则泄露配置文件、日志和源码片段，重则暴露数据库口令、密钥、Token 或内部服务地址。 这篇文章整理一个偏通用的审计思路，场景来自日常代码审计中反复遇到的一类问题：业务希望通过参数传入文件名，然后由后端读取指定目录下的文件并返回给用户。问题往往出在“看起来做了目录限制”，但限制方式并不可靠。 典型场景 一个常见的下载接口大概长这样： @GetMapping("/download") public void download(@RequestParam String file, HttpServletResponse response) throws IOException { String baseDir = "/data/app/upload/"; File target = new File(baseDir + file); response.se
T0xfce