跳转到帖子
应急响应中心

应急响应中心

保存

应急响应中心部落格

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

  • 篇帖子

    283

  • 篇意见

    0

  • 次查看

    2340

关于此博客

从异常请求到根因：一次 SSRF 风险的代码审计与修复实践

在实际代码审计中，SSRF（服务端请求伪造）往往不是一个单独的“请求外部 URL”问题，而是输入校验、URL 解析、DNS 解析、重定向处理和网络出口策略共同形成的风险。很多修复方案只增加一个字符串前缀判断，短期内能够挡住已知测试用例，但在解析差异、重定向或 DNS 变化场景下仍然可能失效。 本文以一个常见的文件预览接口为例，整理从发现线索、确认数据流、分析风险边界，到修复和验证的完整过程。示例只用于本地测试环境和防守性分析，不涉及对第三方系统的访问。 一、背景与问题场景 某应用提供了一个“通过 URL 获取远程文件并生成预览”的功能，业务代码大致包含以下逻辑： String source = request.getParameter("source"); byte[] data = httpClient.get(source); return previewService.generate(data);从业务角度看，这段代码很直接：接收地址、发起请求、处理响应。但从安全角度看，服务器实际上成为了用户可控的网络请求代理。攻击者可能借此让服务器访问本不应由用户直接访问的内部服务、管理接口
T0xfce

从代码审计到修复：系统化识别与防护 SSRF 风险

SSRF（Server-Side Request Forgery，服务端请求伪造）并不只是“接口允许访问内网”这么简单。实际审计中，风险通常藏在图片抓取、Webhook、URL 预览、文件导入、PDF 转换、在线截图等功能里。一个看似普通的后端请求，只要让用户影响了目标地址，就可能成为访问内部服务、探测网络边界或泄露敏感信息的入口。这类问题的难点在于：应用层校验、DNS 解析、HTTP 重定向、代理配置和网络出口策略往往分散在不同组件中。只修补其中一层，通常不足以形成可靠防线。本文从代码审计和修复角度，整理一套适用于 Web 应用的 SSRF 分析方法，重点讨论如何降低误报、避免绕过，并建立可测试的防护策略。一、常见问题场景图片或头像服务根据用户提交的 URL 下载远程资源。Webhook、回调地址、第三方通知接口允许用户配置目标 URL。在线文档、网页截图、PDF 转换服务会主动访问页面中的资源。导入功能根据 URL 获取 JSON、XML、CSV 或压缩包。监控、健康检查或调试接口允许管理员填写探测地址。服务端代理接口将用户提供的 URL 转发，并把响应内容返回给前端。审计时不要只
T0xfce

从源码审计到安全修复：SSRF 漏洞的识别、验证与防御

服务端请求伪造（SSRF）并不只是“让服务器访问一个外部 URL”。在真实项目中，它往往出现在图片抓取、Webhook、在线预览、文件导入、URL 扩展等功能里。问题的核心是：攻击者能够影响服务端发起请求的目标，而应用又没有正确限制目标地址、协议、重定向和请求范围。SSRF 的危害取决于服务端所在网络环境。一个看似只能访问公网的功能，可能因为网络分区、代理配置、云环境元数据服务、内部管理接口或本机调试端口而获得更高权限。因此，审计时不能只盯着某一条黑名单规则，而应从“输入如何流向网络请求”以及“请求最终能到达哪里”两个方向同时分析。一、先明确审计边界和风险模型在开始复现前，应确认测试对象属于授权范围，并尽量使用本地靶场、隔离测试环境或由团队提供的模拟服务。验证 SSRF 不需要访问真实的内网资产，也不需要请求云平台元数据地址。最稳妥的方式是准备一个可控的本地 HTTP 服务，观察应用是否按照预期发起请求。建议先回答以下问题：用户可控的输入是否最终进入了 HTTP、HTTPS、TCP 或其他网络客户端？应用是否允许用户指定完整 URL，还是只允许指定路径、资源编号或域名？请求是否会自动跟
T0xfce

一次 Java Web 文件上传漏洞的复盘与代码审计要点

背景文件上传是 Java Web 项目里很常见的功能，头像、附件、导入模板、富文本图片都会用到。问题在于，上传链路往往同时涉及文件名处理、扩展名校验、MIME 判断、存储路径、静态资源访问和后续解析逻辑，任何一个环节处理不当，都可能让普通上传功能变成高危入口。这篇文章整理一次较典型的文件上传漏洞复盘思路，重点放在代码审计和防护改造上。内容不涉及实际入侵操作，也不提供可直接用于攻击的样例，只讨论如何识别风险、验证边界和修复问题。问题场景某 Java Web 系统提供附件上传接口，业务设计上只允许上传图片和 PDF。接口大致流程如下：前端限制上传文件后缀，例如 jpg、png、pdf；后端接收 MultipartFile；根据原始文件名截取扩展名；将文件保存到 Web 可访问目录；返回文件 URL 给前端展示或下载。从功能上看没有异常，但从安全角度看，这里有几个明显的审计切入点：是否只依赖前端校验；后端扩展名判断是否可靠；文件内容是否校验；保存目录是否可执行或可被服务器解析；文件名是否存在路径穿越、覆盖、特殊字符问题；返回 URL 是否导致敏感文件暴露。典型问题代码下面是一段常见但风险较高
T0xfce

一次 Java Web 文件上传漏洞的复现与代码审计记录

背景 文件上传是 Java Web 项目里很常见的功能，但也是代码审计中高频出现问题的点。很多漏洞并不是因为框架本身不安全，而是业务代码在文件名处理、类型校验、存储路径、访问权限等环节留下了缺口。 这篇文章整理一次偏防御视角的复现与审计过程，场景是内部测试环境中的一个文件上传接口。重点放在如何定位风险、如何验证影响、以及如何修复，不包含对真实站点的攻击操作。 场景描述 目标系统是一个传统 Java Web 应用，提供头像上传和附件上传两个接口。上传后的文件会被保存到 Web 目录下，前端可直接通过 URL 访问。 审计时关注到一个接口大致逻辑如下： @PostMapping("/upload") public String upload(@RequestParam("file") MultipartFile file) throws Exception { String fileName = file.getOriginalFilename(); String savePath = request.getServletContext().getRealPath("/up
T0xfce

从一次 SSRF 误报到真实风险：URL 出站请求的审计与加固方法

SSRF（Server-Side Request Forgery，服务端请求伪造）并不只存在于一个简单的“传入 URL、后端发起请求”接口中。在实际项目里，图片抓取、Webhook 调试、文档预览、远程文件导入、健康检查等功能，都可能形成出站请求能力。真正困难的地方通常不是发现请求，而是判断请求是否能够到达不应访问的网络边界，以及应用是否在重定向、DNS 解析和代理配置下仍然保持安全。 本文以代码审计和内部复现为主线，整理一套不依赖攻击内网的 SSRF 分析方法。示例均应在本地靶场或经过授权的测试环境中进行，重点放在风险确认、边界控制和修复验证。 一、问题场景与审计目标 典型业务代码大致如下： String target = request.getParameter('url'); URL url = new URL(target); HttpURLConnection connection = (HttpURLConnection) url.openConnection(); connection.setConnectTimeout(3000); connection.setRead
T0xfce

从代码审计到复现：一次文件上传漏洞的安全分析与加固思路

背景文件上传一直是 Web 安全里很常见、也很容易被低估的一类风险。很多业务系统都会提供头像、附件、导入模板、工单图片等上传入口，看起来只是普通功能，但如果后端校验不严，可能导致任意文件写入、脚本解析、存储型 XSS，甚至进一步扩大为服务器侧风险。这篇文章整理的是一个相对典型的审计过程：从代码层发现问题，到在本地环境中验证风险，再到给出相对可落地的修复方案。内容只讨论授权环境下的安全测试和加固，不涉及未授权攻击。问题场景某业务系统提供附件上传接口，前端限制只能上传图片，后端代码也做了简单判断。接口大致逻辑如下：POST /api/upload/avatar Content-Type: multipart/form-data file: 用户上传文件从功能表现看，上传图片后会返回一个可访问的 URL，例如：{ \"url\": \"/uploads/2026/10/08/169xxxx.png\" }初看没有明显问题，但代码审计时发现后端校验主要依赖文件后缀和客户端传入的 Content-Type，这两点都不适合作为唯一安全边界。技术分析一个常见的有问题实现大概是这样：Str
T0xfce

一次面向内网资产的 Web 代码审计思路整理：从入口梳理到风险收敛

背景 最近在帮团队梳理一批历史 Web 系统，特点比较典型：业务代码维护多年，框架版本不统一，接口文档缺失，很多权限和数据校验逻辑散落在控制器、服务层甚至前端页面里。单纯跑扫描器会有不少噪声，真正需要的是把入口、数据流、权限边界和危险函数串起来看。 这篇文章整理一套偏实战的代码审计流程，适合用于企业内部资产、安全评估和上线前复核。重点放在如何定位高风险问题、如何验证风险、如何给出可落地的修复建议，不涉及未授权入侵或破坏性利用。 审计目标与场景 我一般会先明确审计目标，否则很容易陷入“看了很多代码，但没有结论”的状态。常见目标可以拆成几类： 确认认证与授权是否存在绕过或越权风险。 检查用户输入到敏感操作之间是否缺少校验。 发现文件上传、文件读取、命令执行、SQL 拼接等高风险点。 梳理历史接口、测试接口、管理接口是否暴露在生产环境。 为后续加固提供优先级，而不是只列问题清单。 如果是第一次接触一个系统，我更建议从“资产入口”和“权限模型”开始，而不是直接全局搜索危险函数。前者能帮助判断风险面，后者能决定漏洞影响范围。 第一步：建立项目视图 拿到代码后，先不要急着看业务细节，可以先建立一张
T0xfce

一次 WebShell 入侵事件的复盘思路：从日志定位到代码审计加固

背景 这篇整理来自几次应急排查中的共性经验：业务站点突然出现异常文件、可疑进程或被搜索引擎标记风险，最后追溯到上传点、后台弱口令、插件漏洞或历史遗留接口。很多复盘文章会直接给 IOC 或处置结论，但真正有长期价值的是把排查路径沉淀下来，方便下次遇到类似情况时能快速缩小范围。 本文只讨论防守视角下的日志分析、样本识别、代码审计和加固方法，不涉及攻击利用细节。示例命令也以本地自查和取证为主。 问题场景 常见的 WebShell 入侵现场通常会有几个信号： Web 目录下出现异常 PHP、JSP、ASPX 文件，文件名看似正常，例如 cache.php、config_old.php、upload_tmp.php。 访问日志中存在少量 POST 请求，响应码为 200，User-Agent 非常规，访问路径集中在上传目录或插件目录。 服务器上出现可疑外连、异常计划任务、临时目录中的脚本文件。 业务代码近期没有发布，但文件修改时间集中在某个时间窗口。 复盘时建议先明确三个问题：入口在哪里、落地文件是什么、后续动作有哪些。不要一开始就急着删除文件，否则容易丢失时间线和证据。 第一步：保护现场与划定
T0xfce

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

背景 文件上传是 Java Web 项目里很常见的功能，头像、附件、导入模板、富文本图片都可能涉及。实际代码审计中，这类功能看起来简单，但经常把“业务可用”和“安全边界”混在一起：只判断后缀、不限制存储位置、上传后可直接访问、依赖前端校验等。 这篇文章整理一次偏真实项目的审计思路，重点放在如何发现风险、如何验证问题、以及如何修复。内容只讨论防护和复现验证，不涉及恶意利用。 常见场景 在 Java Web 项目中，上传逻辑通常分布在以下几类位置： Controller 层直接接收 MultipartFile。 统一文件服务，例如 FileService.upload()。 富文本编辑器插件上传接口。 Excel、CSV 等导入功能。 第三方对象存储封装，例如 MinIO、OSS、S3。 审计时不建议只搜索 upload，还可以关注以下关键词： MultipartFile CommonsMultipartFile transferTo getOriginalFilename FileOutputStream Files.copy Path.of new File @RequestPart
T0xfce

从一次代码审计看文件上传漏洞的定位与加固思路

背景 文件上传一直是 Web 安全里比较常见、也比较容易被低估的一类风险。很多项目在上线前会做登录、权限、SQL 注入等检查，但上传模块往往只验证了前端扩展名，或者简单判断 Content-Type，导致后续出现任意文件写入、存储型 XSS、敏感文件覆盖等问题。 这篇文章整理一次代码审计中的典型排查思路，重点放在如何定位风险点、如何验证安全边界、以及如何做可维护的加固。内容不涉及真实目标攻击，也不提供恶意利用链，只讨论防护和审计方法。 问题场景 审计对象是一个常见的后台管理系统，提供头像、附件、富文本图片三类上传入口。代码结构大致如下： src/ controller/ UploadController.java service/ FileStorageService.java config/ WebMvcConfig.java static/ upload/上传接口功能正常，业务上允许上传图片和部分文档。初看代码时，几个明显的关注点包括： 文件类型是否只依赖前端或请求头判断。 上传目录是否位于 Web 可访问路径。 文件名是否使用原始文件名，是
T0xfce

从一次代码审计看 Spring Boot 文件上传接口的常见风险

背景 文件上传是 Web 系统里很常见的功能，但也是代码审计中高频出问题的位置。很多业务接口看起来只是“上传头像”“导入 Excel”“上传附件”，实际会同时涉及文件类型校验、存储路径、访问权限、解析组件、对象存储权限等多个安全边界。 这篇文章整理一次 Spring Boot 项目审计中遇到的典型问题，重点放在风险识别和修复思路上。内容不讨论未授权攻击利用，也不提供绕过思路，主要用于研发和安全同学做自查。 问题场景 项目中有一个附件上传接口，供后台用户上传业务材料。接口大致逻辑如下： @PostMapping("/upload") public Result upload(@RequestParam("file") MultipartFile file) throws IOException { String fileName = file.getOriginalFilename(); String basePath = "/data/app/uploads/"; File dest = new File(basePath + fileName); fi
T0xfce

一次 WebShell 排查复盘：从异常请求到落点定位

背景 WebShell 排查是应急响应里很常见的一类工作，但真正落地时经常会遇到两个问题：一是告警信息很少，只有几条异常访问日志；二是业务目录复杂，上传目录、缓存目录、插件目录混在一起，单纯按文件名搜索很容易漏掉。 这篇文章整理一次偏通用的排查思路，重点放在如何从访问日志、文件时间线、代码特征和运行痕迹逐步缩小范围。内容只讨论防守侧定位、取证和加固，不涉及攻击利用或控制操作。 问题场景 某站点出现异常外连告警，出口设备记录到 Web 服务器在夜间访问了多个陌生 IP。初步看业务仍可访问，主机没有明显高负载。管理员提供的信息比较有限： 站点使用 PHP 部署，包含后台上传功能。 Nginx 反向代理到 PHP-FPM。 最近一周做过插件升级，也有运营人员上传过附件。 告警时间集中在凌晨 2 点到 4 点。 这类场景不要一开始就全盘删除文件。建议先保留现场，复制日志和可疑文件，避免破坏时间戳和后续分析线索。 第一步：固定现场与基础信息 先做只读式的信息收集，记录系统时间、进程、网络连接、定时任务和 Web 目录基本情况。下面的命令偏排查视角，执行前应结合生产环境权限和变更规范。 date
T0xfce

从请求链到证据链：SSRF 漏洞的审计、复现与加固实践

服务端请求伪造（SSRF）并不只是“让服务器代替用户发起一次请求”。在实际项目中，它往往和 URL 解析差异、重定向、DNS 解析、代理配置以及内网服务信任边界叠加出现。单纯增加一个“是否以 http 开头”的判断，通常只能拦住最简单的输入，无法形成可靠的防护。本文以代码审计和本地隔离实验为主线，整理一次 SSRF 问题从发现、确认到修复的完整思路。示例只针对本地测试服务和自有环境，不涉及访问真实云环境元数据或未授权内网系统。一、先明确 SSRF 的风险边界典型场景是后端提供了“抓取远程图片”“导入 Webhook”“检测 URL 是否可访问”“生成网页预览”等功能。用户提交一个 URL，服务端通过 HTTP 客户端访问该地址，再将响应内容返回或交给后续处理。风险通常来自三个方面：服务端网络位置比普通用户更接近内网，可能访问用户无法直接访问的管理面板、调试接口或内部 API。服务端携带了额外身份信息，例如内部请求头、环境凭据或代理认证信息。URL 解析和网络连接之间存在差异，应用层判断的目标地址与实际连接地址可能并不一致。因此，审计时不能只问“这个参数是否可控”，还要继续追踪：输入如何
T0xfce

从一次 SSRF 排查到纵深防护：URL 解析、重定向与出网控制的完整实践

SSRF（Server-Side Request Forgery，服务端请求伪造）并不是简单的“让服务器访问一个 URL”。在真实项目中，漏洞往往出现在图片抓取、Webhook、文档预览、远程资源导入、监控探针等功能里。攻击者能够影响请求目标后，风险取决于服务端网络位置、请求凭据、重定向处理方式以及云环境的出网策略。这类问题的难点通常不在于发现一个可以访问的地址，而在于确认：应用究竟如何解析 URL，DNS 解析发生在哪里，是否允许重定向，是否会自动携带内部凭据，以及网络侧有没有第二道限制。本文以防守和授权测试为前提，整理一套适合代码审计、复现和修复验证的排查方法。一、典型场景与风险边界常见入口包括以下几类：用户提交图片或附件地址，服务端负责下载并保存。Webhook、回调地址或第三方集成配置。Markdown、富文本或文档服务中的远程资源抓取。URL 预览、网页截图、PDF 转换和链接安全扫描。代理接口、健康检查接口和内部服务连通性检测。风险不一定表现为直接读取敏感数据。即使响应内容不可见，服务端仍可能因为请求内部地址而产生盲 SSRF，造成内网端口探测、管理接口访问、内部任务触发或
T0xfce

从一次组件漏洞复现看 Web 漏洞验证的安全边界与审计思路

背景 做漏洞分析时，很多人会把重点放在“能不能打通”上，但在真实项目里，更有价值的是确认影响面、定位根因、给出可落地的修复建议，并且保证验证过程不会对线上业务造成额外风险。尤其是涉及 Web 组件漏洞、反序列化、文件上传、模板注入这类问题时，复现环境和验证边界非常关键。 这篇文章整理一套偏防守视角的漏洞复现与代码审计流程。内容不会提供攻击利用链或可直接用于未授权入侵的步骤，而是侧重如何在授权环境中安全验证、如何从请求行为回溯代码逻辑、如何沉淀检测规则和修复方案。 典型场景 假设内部资产梳理时发现某业务系统使用了一个历史版本的 Web 组件。公开信息显示该版本存在高危漏洞，影响点可能包括参数解析、文件处理或表达式执行。此时常见问题有三个： 资产是否真的使用了受影响版本。 业务调用链是否暴露了漏洞触发点。 修复应该是升级组件、调整配置，还是在代码层补充校验。 如果只依赖版本号判断，很容易误报；如果直接在生产环境做激进验证，又可能引发业务异常。所以更稳妥的方式是搭建隔离复现环境，并结合代码审计确认漏洞是否可达。 复现环境的基本原则 复现环境建议尽量接近线上，但必须隔离网络和数据。不要使用真实
T0xfce

从一次反序列化告警看 Java Web 漏洞排查与加固思路

背景 Java Web 系统里的反序列化问题并不新，但在实际排查中，它经常不是以“漏洞利用成功”的形式出现，而是先表现为网关异常、WAF 告警、日志里出现可疑类名、接口返回 500 或 JVM 负载短时间升高。很多团队在处理这类问题时容易走两个极端：要么只看单条告警，封一个 IP 就结束；要么直接全站停机排查，影响业务。 这篇文章整理一套相对稳妥的排查思路，重点放在识别风险入口、定位反序列化链路、验证影响范围和加固措施上。内容只讨论防御和代码审计视角，不涉及攻击载荷构造和未授权利用。 典型场景 某 Java Web 服务前面有 Nginx 和应用网关，后端是 Spring MVC 老项目，依赖里包含若干历史包。某天网关出现如下特征： 部分 POST 请求体为二进制或 Base64 形态，接口路径并非上传接口。 日志中出现 java.io.ObjectInputStream、readObject、InvalidClassException 等异常。 应用进程短时间 CPU 升高，但没有明显业务峰值。 WAF 告警命中“Java 反序列化探测”规则。 这里不能简单判断为“已经被攻陷”，但至
T0xfce

从一次内网探测事件看 SSRF 的审计、验证与防护

SSRF（Server-Side Request Forgery，服务端请求伪造）并不算新漏洞，但在代码审计和真实事件中仍然非常常见。原因通常不是开发者完全不了解 SSRF，而是把问题简单归结为“禁止访问 127.0.0.1”，忽略了重定向、DNS 解析、IPv6、代理配置以及云环境元数据服务等边界条件。本文以一次典型的内网探测事件为背景，整理 SSRF 的分析思路、代码审计重点、验证方法和修复策略。示例均以本地测试环境为前提，不涉及对第三方系统的探测或利用。一、事件背景：一个图片抓取接口引发的内网访问某业务提供了远程图片抓取功能，客户端提交图片地址，服务端下载图片后保存到对象存储。接口最初的实现逻辑大致如下：String imageUrl = request.getParameter("url"); URL url = new URL(imageUrl); URLConnection connection = url.openConnection(); connection.setConnectTimeout(3000); connecti
T0xfce

从代码审计到修复：系统分析 Web 应用中的 SSRF 风险

SSRF（Server-Side Request Forgery，服务端请求伪造）并不是“让服务器发起一次 HTTP 请求”这么简单。它真正危险的地方在于：请求行为发生在受信任的服务器网络环境中，攻击者可能借此访问外部系统无法直接访问的管理接口、云平台元数据服务、内部调试端点，甚至触发带有副作用的业务接口。 在实际审计中，SSRF 往往不是单个函数的问题，而是输入校验、URL 解析、网络出口、重定向处理和权限边界共同失效的结果。下面以代码审计和修复为主线，整理一套适用于常见 Web 服务的分析方法。 一、典型业务场景 以下功能通常值得优先检查： 根据用户提交的 URL 抓取网页标题、下载远程图片或导入 RSS。 在线生成缩略图、PDF、网页快照或 Markdown 预览。 Webhook、回调地址、第三方接口连通性测试。 代理服务、URL 跳转、远程文件校验和云存储导入。 后台提供的“检测目标地址”“探测服务状态”等运维功能。 审计时不要只搜索 requests.get、HttpClient 或 curl。更有效的方式是从外部可控输入出发，沿数据流追踪到网络请求函数，确认中间是否存在可
T0xfce

从一次 Fastjson 告警复盘谈反序列化漏洞的验证与加固

背景前段时间在做一批历史系统的安全巡检时，遇到一类比较典型的告警：网关日志里出现了带有 @type 字段的 JSON 请求，目标接口本身是一个业务查询接口，不应该接收复杂对象。结合依赖清单发现，该系统仍在使用较老版本的 Fastjson。这个场景在存量 Java Web 系统里并不少见，尤其是多年未升级的后台管理系统、内部接口网关和数据同步服务。这篇文章不讨论利用链细节，也不提供攻击载荷，重点放在如何在授权环境下判断风险、定位代码入口、复现安全影响，以及最终如何加固。反序列化问题的坑点在于：很多时候漏洞不在某一个明显的控制器里，而是在框架封装、通用解析工具类、消息消费逻辑中被反复调用。问题场景这次排查的系统大致有几个特点：Java 8，Spring MVC 架构，部分模块较老。依赖中存在 Fastjson 1.2.x 早期版本。项目里大量使用 JSON.parseObject、JSON.parse 处理外部输入。部分接口直接接收 String body，再手动转换为对象。网关日志中出现异常 JSON 字段，如 @type、不符合业务字段的嵌套对象。这里需要注意一点：日志中出现类似字段不
T0xfce

从一次真实告警看 WebShell 排查与加固思路

背景 最近帮一位朋友复盘一台业务服务器的异常告警，现象并不复杂：EDR 提示 Web 目录下出现可疑脚本，Nginx 访问日志里也能看到少量异常请求。业务本身是一个常见的 PHP 后台系统，前面有 Nginx，后端 PHP-FPM，服务器上同时跑了定时任务和文件上传功能。 这类事件在社区里经常讨论，但很多排查记录要么只停留在“发现一句话木马”，要么直接跳到“重装系统”。实际工作中，更有价值的是把入口、执行链路、落地点、影响范围和加固动作串起来。本文整理的是一套相对通用的 WebShell 排查与加固流程，偏防守视角，不涉及未授权利用细节。 问题场景 初始告警文件位于 Web 根目录的上传目录下，文件扩展名伪装成图片，但内容里包含 PHP 代码片段。访问日志显示该文件曾被直接请求，且请求参数存在异常长字符串。 环境大致如下： 系统：Linux Web 服务：Nginx + PHP-FPM 业务语言：PHP 目录结构：存在用户上传目录、缓存目录、日志目录 安全设施：基础主机监控、Nginx 访问日志、应用日志 这里需要注意一点：发现 WebShell 文件，不等于已经完成排查。WebShe
T0xfce

一次面向真实业务的代码审计思路整理：从入口梳理到风险验证

背景 不少代码审计文章会直接从某个漏洞点开始讲，但在真实项目里，问题往往不是单点出现的。尤其是中后台、开放 API、文件处理、任务调度这类业务，漏洞通常藏在权限边界、数据流转和框架默认行为之间。 这篇文章整理一套偏实战但相对克制的审计方法，重点放在如何建立审计路径、如何验证风险、如何避免误报。内容适合用于内部安全评审、上线前代码检查，以及对历史系统做一次系统性体检。 审计前的准备 拿到一个项目后，不建议立刻全文搜索危险函数。更稳妥的做法是先理解项目结构和业务边界。至少需要确认以下信息： 项目语言与框架，例如 Spring Boot、Laravel、Django、Express、Go Gin 等。 鉴权方式，例如 Session、JWT、OAuth2、网关注入用户态。 权限模型，例如 RBAC、数据权限、租户隔离、接口白名单。 外部输入入口，例如 HTTP API、消息队列、定时任务、文件上传、Webhook。 敏感能力，例如文件读写、命令执行、模板渲染、SQL 拼接、反序列化、第三方回调。 如果是 Java 或 Go 这类大型后端项目，我一般会先整理一张入口清单，再从入口向服务层和数据
T0xfce

一次 Spring Boot Actuator 暴露风险的复盘与加固实践

背景 这几年做外网资产梳理时，Spring Boot Actuator 暴露仍然是比较常见的问题。它不一定等同于“直接拿权限”，但如果管理端点暴露在公网，往往会带来配置泄露、环境变量泄露、服务探测、健康状态枚举等风险。更麻烦的是，很多团队在测试环境开放了 Actuator，后续通过镜像、配置中心或脚手架同步到了生产环境。 本文整理一次比较典型的复盘思路，重点放在如何识别风险、验证影响、定位配置来源以及做长期加固。内容不涉及未授权攻击利用链，只讨论在授权范围内的安全检查和修复。 问题场景 某业务上线后做例行外网巡检，发现其中一个子域名存在 Spring Boot 特征。进一步检查时，服务返回了 Actuator 相关端点信息。该服务本身没有明显的登录入口，属于后端 API 网关后的一个业务服务，但由于历史配置原因，部分管理端点被暴露到了公网。 常见暴露入口包括： /actuator /actuator/health /actuator/info /actuator/env /actuator/configprops /actuator/metrics /actuator/loggers
T0xfce

从代码审计到验证：一次文件上传漏洞的安全分析与加固思路

背景文件上传功能在业务系统里很常见，比如头像、附件、工单材料、富文本图片等。它看起来只是一个普通功能，但在真实代码审计和安全测试中，上传点经常是高风险入口：一旦校验不严，可能导致任意文件写入、脚本执行、存储型 XSS、敏感文件覆盖，甚至成为后续攻击链的起点。这篇文章不讨论如何利用漏洞取得非法权限，而是从防守视角整理一套比较实用的分析方法：如何在代码审计中识别风险点，如何在授权环境里做安全验证，以及如何把上传模块加固到相对可靠的状态。典型场景假设一个 Web 系统提供附件上传接口，后端逻辑大致如下：POST /api/upload 参数： file: 上传文件 type: avatar / ticket / doc常见实现流程一般包括：前端限制文件后缀和大小；后端接收 multipart/form-data；读取原始文件名；拼接保存路径；保存到 Web 可访问目录；返回文件 URL 给前端展示。如果这几个环节只做了浅层校验，就很容易出现问题。实际审计时，我一般会重点看三个方面：文件类型校验、保存路径处理、访问与执行权限控制。问题一：只信任前端校验不少系统会在前端写类似限制：if (
T0xfce

一次 WebShell 事件复盘：从入口定位到代码审计加固

背景 最近整理了一起典型的 WebShell 入侵事件，环境是常见的 Linux + Nginx + PHP-FPM 架构，业务侧使用了一个较老的内容管理系统，并带有自定义上传接口。事件本身不复杂，但覆盖了日志排查、样本分析、入口确认、代码审计和加固验证几个环节，比较适合作为日常应急和审计的参考。 本文只讨论防守视角下的分析方法和修复思路，不涉及利用细节和攻击引导。实际处置时，建议先完整保全现场，再做隔离和清理，避免证据被覆盖。 问题场景 最初的告警来自主机侧 EDR：Web 目录下出现可疑 PHP 文件，文件名类似正常缓存文件，但内容包含动态执行特征。业务反馈近期没有发布操作，也没有新增插件。 现场观察到几个现象： Web 根目录下存在异常 PHP 文件，修改时间集中在凌晨。 Nginx 访问日志中出现少量对上传接口的异常请求。 PHP-FPM 慢日志没有明显异常，但错误日志中有上传目录权限相关报错。 业务代码中存在历史遗留的文件上传逻辑，没有统一走框架封装。 初步处置原则 这类事件不要上来就直接删除文件。比较稳妥的顺序是：隔离、保全、分析、清理、修复、验证。尤其是 WebShell
T0xfce