跳转到帖子
应急响应中心

应急响应中心

保存

应急响应中心部落格

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

  • 篇帖子

    283

  • 篇意见

    0

  • 次查看

    2321

关于此博客

一次 WebShell 入侵事件的复盘：从日志线索到加固闭环

背景 最近整理了一起典型的 WebShell 入侵事件。场景并不复杂：一台对公网开放的业务服务器，运行常见的 PHP Web 应用，前面挂了反向代理。管理员最早发现的问题是站点偶尔返回异常内容，随后在 Web 目录下发现了可疑 PHP 文件。 这类事件在实际处置中很常见，难点往往不在于“删掉木马文件”，而在于确认入口、影响范围、是否存在持久化、以及如何把同类问题彻底堵住。本文按一次相对完整的排查流程整理，重点放在日志分析、文件取证、代码入口定位和加固闭环上。 问题场景 已知现象包括： Web 根目录下出现异常 PHP 文件，文件名看起来像缓存或资源文件。 Nginx 访问日志中存在少量非常规请求，User-Agent 较少见。 服务器负载没有明显升高，未发现大规模扫描或挖矿行为。 应用目录中部分文件修改时间集中在某个时间段。 这种情况下，不建议直接重装或清空日志。比较稳妥的做法是先保护现场，复制关键日志和可疑样本，再进入清理与加固阶段。 第一步：保护现场与基础信息采集 如果业务允许，优先将站点切到维护页或只读状态。至少应避免攻击者继续写入文件。基础信息采集建议覆盖以下几类： Web 访
T0xfce

从一次代码审计看文件上传漏洞的识别与加固

背景 文件上传功能在业务系统里很常见，比如头像、附件、工单截图、文档导入等。它看起来只是一个普通表单，但从攻防视角看，上传链路往往同时涉及前端校验、后端解析、文件存储、访问控制、Web 容器解析规则、对象存储权限等多个环节，任何一个点处理不当，都可能演变成高危问题。 这篇文章结合日常代码审计和漏洞复现经验，整理一套比较通用的文件上传安全分析方法。内容侧重识别风险与加固思路，不提供违法攻击、恶意控制或绕过授权类操作。 典型场景 常见业务代码里，文件上传接口大致会做三件事： 接收 multipart/form-data 请求中的文件对象。 校验文件名、后缀、大小、MIME 类型。 保存到本地目录、NFS、对象存储或 CDN 回源目录。 问题经常出现在“只做了表面校验”或“保存路径位于 Web 可执行目录”这类细节上。例如只根据原始文件名后缀判断类型，或者上传后文件可被 Web 容器当作脚本解析。 审计时优先看的几个点 1. 文件类型校验是否可信 不少代码只检查用户提交的文件名后缀，甚至只检查 Content-Type。两者都不能作为唯一依据，因为它们都来自客户端，可信度较低。更稳妥的方式是
T0xfce

一次 SSRF 漏洞复现与代码审计的完整整理

背景SSRF（Server-Side Request Forgery）在 Web 安全里属于非常常见但容易被低估的一类问题。它的核心风险不是“服务端能发请求”本身，而是攻击者可以影响服务端请求的目标、协议或关键参数，从而访问本不该暴露的内部资源。实际项目中，SSRF 常出现在这些功能里：远程图片抓取、URL 预览、Webhook 回调、文件导入、PDF/截图生成、站点连通性检测、第三方资源同步等。本文整理一次偏防御视角的 SSRF 复现与代码审计思路，重点放在如何定位问题、验证风险、修复和回归测试，不包含对未授权目标的攻击利用。问题场景假设某业务提供“远程图片上传”功能，用户提交一个图片 URL，后端下载后保存到对象存储或本地文件系统。简化后的业务流程如下：用户提交一个 URL。后端校验 URL 格式。后端发起 HTTP 请求下载内容。判断 Content-Type 或文件后缀。保存文件并返回访问地址。这类功能如果只校验了 URL 是否以 http:// 或 https:// 开头，而没有限制目标地址范围，就可能导致服务端访问内网地址、云厂商元数据地址、本机服务或管理端口。风险边界SS
T0xfce

一次 SSRF 漏洞分析与内网风险收敛实践

{"title":"一次 SSRF 漏洞分析与内网风险收敛实践","content":"背景 SSRF（Server-Side Request Forgery）在近几年仍然是 Web 安全里比较常见、也比较容易被低估的一类问题。它的特点不是单点危害一定很高，而是经常作为“入口型漏洞”存在：攻击面看起来只是一个 URL 抓取、图片转存、Webhook 校验、PDF 生成或接口代理功能，但一旦服务端可以代替用户发起请求，就可能影响到内网服务、云元数据接口、管理面板、消息队列、缓存服务等资源。 这篇文章不做攻击教程，主要从代码审计和防护视角整理一次典型 SSRF 问题的分析思路：怎么识别风险点、怎么验证是否存在服务端请求行为、常见过滤为什么失效，以及工程上如何收敛这类风险。 问题场景 在一次代码审计中，业务侧有一个“远程图片转存”功能。用户提交图片 URL，后端下载图片并上传到对象存储，最终返回 CDN 地址。功能本身合理，但风险点也比较典型： 用户可控 URL 被服务端直接请求； 后端服务部署在内网，具备访问部分内部域名和基础设施的能力； 代码只校验了 URL 是否以 http 开头，没有
T0xfce

一次 Java Web 代码审计中的文件上传风险梳理

背景 文件上传是 Java Web 项目里很常见的功能，但也是代码审计中反复出现问题的点。很多团队已经做了后缀名校验、大小限制、登录态校验，但在实际审计里，风险往往不只来自“能不能上传 JSP”，还包括路径拼接、文件覆盖、内容类型信任、解压缩处理、对象存储回调、预览解析等边界问题。 这篇文章整理一次典型 Java Web 上传模块的审计思路，重点放在如何发现问题、如何修复和加固，不提供任何非法利用或入侵操作引导。适合作为日常代码审计、研发自查和安全评审时的检查清单。 常见场景 审计对象通常包括以下几类上传入口： 用户头像、附件、工单截图等普通文件上传。 后台 CMS 的图片、模板、资源包上传。 Excel、CSV 导入功能。 ZIP 压缩包上传后自动解压。 对象存储直传、服务端签名上传、回调通知。 文件预览功能，如 PDF、Office、图片缩略图生成。 从经验看，真正的问题经常出现在“上传之后”的处理链路里，例如保存路径可控、文件名复用、异步解析、解压目录穿越、预览组件调用外部命令等。 审计入口定位 Java Web 项目可以优先从 Controller 层和依赖库入手。常见关键字包
T0xfce

从一次 Java Web 漏洞复现看代码审计中的数据流追踪

背景 做 Java Web 代码审计时，很多问题并不是一眼看到危险函数就能确认的。真实项目里通常有多层 Controller、Service、DAO、Filter、Interceptor，还有各种参数绑定和工具类封装。单点搜索容易漏报，也容易误报。 这篇文章整理一个偏通用的审计思路：围绕“入口参数如何流向敏感操作”做数据流追踪。内容以本地靶场或授权测试环境为前提，重点放在漏洞确认、修复建议和审计方法，不涉及未授权利用和攻击扩展。 问题场景 假设某 Java Web 项目提供了一个文件预览接口，业务上允许用户查看自己上传目录下的文档。代码经过多层封装后，大概流程如下： Controller 接收参数 fileName； Service 拼接上传目录路径； 工具类读取文件并返回内容； 前端根据响应展示预览结果。 这类功能的常见风险包括路径穿越、任意文件读取、越权访问以及日志泄露。审计时不能只看是否调用了 FileInputStream，还要确认用户输入是否经过规范化、边界校验和权限校验。 核心代码示例 下面是一段简化后的示例代码，便于说明问题。实际项目中可能散落在不同类里。 @GetMap
T0xfce

一次面向内网 Web 资产的代码审计思路整理

背景 内网 Web 资产往往不像公网业务那样有完整的安全基线：历史系统多、框架版本杂、账号体系分散，很多接口长期处于“能用就行”的状态。做红队演练或内部安全评估时，如果只依赖自动化扫描，很容易漏掉业务逻辑问题；如果只靠手工黑盒测试，又会受限于接口覆盖率。 这篇文章整理一套我在实际代码审计和漏洞复现中常用的思路，重点放在可验证、可复盘、可修复的流程上。内容以防御和内部授权测试为前提，不涉及未授权攻击、凭证窃取或恶意控制。 问题场景 假设目标是一套常见的 Java Web 内部管理系统，技术栈大致如下： Spring Boot / Spring MVC MyBatis 或 MyBatis-Plus Shiro / Spring Security 做认证鉴权 前后端分离，接口以 JSON 为主 部分文件上传、导入导出、任务调度、报表查询功能 这类系统的风险通常不在单点框架漏洞，而在“权限边界不清 + 参数流向复杂 + 历史代码缺少统一约束”。审计时我一般先不急着看具体漏洞点，而是先建立三张图：接口图、权限图、数据流图。 第一步：快速建立接口资产视图 代码审计的第一件事是知道系统暴露了什么接口
T0xfce

从代码审计到修复验证：一次 Web 文件上传漏洞的完整分析方法

文件上传功能看起来只是“接收文件并保存”，但它同时涉及输入校验、文件系统、Web 服务器解析规则、访问控制和异步处理等多个边界。实际审计中，很多问题并不来自某一行明显危险的代码，而是来自“校验逻辑”和“存储、访问逻辑”之间的不一致。 本文以一个本地测试环境中的文件上传功能为例，整理从定位风险、构造安全复现、分析根因到修复验证的完整方法。示例只上传普通文本文件，不涉及脚本执行、未授权访问或对真实系统的测试。 一、先明确需要回答的几个问题 审计上传功能时，不要一开始只盯着文件后缀。更有效的做法是沿着文件生命周期逐步确认： 请求中的文件名、Content-Type 和文件内容分别由谁控制？ 服务端是否只依赖客户端提交的扩展名或 MIME 类型？ 文件最终保存在哪里，是否位于 Web 可直接访问的目录？ 保存后的文件名是否由用户输入决定？是否可能覆盖已有文件或形成路径穿越？ Web 服务器是否会解析该目录中的某些后缀？ 下载文件时是否重新校验了权限，还是只要知道 URL 就可以访问？ 缩略图、解压、转码等后处理组件是否会再次解析用户文件？ 这几个问题基本覆盖了上传漏洞的主要风险面，也能避免审计
T0xfce