跳转到帖子
应急响应中心

应急响应中心

保存

应急响应中心部落格

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

  • 篇帖子

    283

  • 篇意见

    0

  • 次查看

    2317

关于此博客

一次 WebShell 排查复盘：从异常请求到代码审计的闭环思路

背景 最近帮一个小型业务站点做应急排查，现象比较典型：服务器 CPU 偶发升高，访问日志里出现了大量非业务路径请求，站点目录下还发现了几个命名很像缓存文件的 PHP 文件。这个案例没有复杂的 0day，更多是常见薄弱点叠加：上传校验不足、历史测试文件未清理、目录权限过大。 这类问题在实际环境里很常见，也适合整理成一套可复用的排查流程。本文重点放在防守视角：如何从日志、文件、进程和代码审计几个维度定位 WebShell，并完成加固闭环。不会展开攻击利用细节。 问题场景 业务架构比较简单：Nginx + PHP-FPM + MySQL，站点部署在单台 Linux 服务器上。管理员最初反馈的问题有三个： 某些时间段服务器负载异常，但持续时间不长。 访问日志出现大量对 upload、cache、static 等目录下 PHP 文件的请求。 站点根目录下存在多个近期修改的陌生文件，文件名类似 image_cache.php、config.bak.php。 初步判断，这不是单纯爬虫扫描，更像是已经落地过可执行脚本，需要确认入口、影响范围和残留。 排查思路 我一般会先避免直接删除文件，而是先取证保存
T0xfce

一次文件上传风险排查的复盘：从入口验证到存储隔离

背景 文件上传是 Web 系统里很常见的功能，但也是长期高发的风险点。实际项目里，很多上传模块一开始只是为了满足业务：头像、附件、合同、日志包、工单截图等，后面随着功能迭代，上传类型越来越多，校验逻辑散落在不同接口里，最终容易形成安全边界不清的问题。 这篇文章整理一次上传模块安全排查的思路，不讨论真实站点攻击过程，也不提供绕过手法，重点放在防守侧如何识别风险、如何验证修复是否有效，以及代码审计时应该关注哪些细节。 问题场景 排查对象是一个典型的 Java Web 系统，提供多个上传入口： 用户头像上传 后台内容管理附件上传 工单系统截图上传 批量导入时的表格文件上传 最初的安全要求很简单：只允许上传图片、文档和表格文件，不允许上传可执行脚本，不允许上传后被服务端解析执行，不允许通过上传文件影响其他用户数据。 但在审计时发现，系统存在几个比较典型的问题： 不同上传接口各自实现校验逻辑，规则不一致 部分接口只校验文件后缀，没有校验实际内容类型 上传文件存储在 Web 可访问目录下 文件名直接使用用户提交的原始名称 部分预览功能会读取上传文件内容并返回给前端，缺少输出控制 技术分析 上传风险
T0xfce

从一次代码审计看 Java 文件上传漏洞的排查与加固

背景 文件上传是 Web 系统里很常见的功能，头像、附件、报表导入、工单截图都会用到。也正因为入口多、业务差异大，它一直是代码审计中容易反复出问题的点。很多团队已经知道要限制后缀、限制大小，但在实际项目里，问题往往出在“校验位置不对”“存储位置不对”“文件名处理不对”和“运行环境配置不对”。 这篇文章结合一次 Java Web 项目审计中遇到的上传模块，整理一套比较通用的排查思路。内容偏防守和复盘，不涉及利用链构造，也不提供攻击性操作步骤，重点放在如何识别风险、验证风险和落地修复。 典型场景 项目采用 Spring Boot，提供一个附件上传接口。上传后的文件会写入服务器本地目录，并将访问路径保存到数据库。业务侧要求支持图片、PDF、Office 文档等类型。审计时看到的简化代码大致如下： @PostMapping("/upload") public Result upload(@RequestParam("file") MultipartFile file) throws IOException { String originalName = file.getOriginal
T0xfce

Web 文件上传安全审计：从信任边界到可验证修复

文件上传看似只是一个业务功能，实际往往同时涉及输入校验、文件解析、存储隔离、访问控制和异步处理。上传点一旦把用户可控内容写入可执行目录，或者在后续解析环节缺少资源限制，就可能从“上传一个文件”演变为任意文件写入、敏感信息泄露、服务端请求伪造甚至拒绝服务。这类问题不适合只靠黑名单或增加一个扩展名判断来解决。更可靠的做法是先明确数据流和信任边界，再分别验证文件内容、文件名、存储位置、访问方式以及后续处理链路。一、先确定上传功能的真实边界审计前不要急着构造特殊文件，先回答几个基本问题：上传接口是否需要登录，是否有租户、项目或对象级权限校验。文件最终保存在哪里，是否位于 Web 根目录、静态资源目录或临时目录。保存后的文件是否能通过可预测 URL 直接访问。应用服务器是否会根据扩展名执行、解析或转发该文件。上传后的文件是否会进入图片缩略图、文档预览、杀毒扫描、OCR 或压缩解包流程。是否存在单文件大小、总容量、请求体和处理时长限制。这一步的目标是画出一条完整的数据流：客户端请求 → 网关或 WAF → 应用校验 → 临时文件 → 持久化存储 → 异步处理 → 文件访问。很多漏洞并不出现在上传接
T0xfce

从代码审计到安全修复：系统梳理 SSRF 风险的识别、验证与防护

SSRF（Server-Side Request Forgery，服务端请求伪造）并不是“让服务器发一个 HTTP 请求”这么简单。真正难处理的地方在于：业务往往确实需要访问外部资源，而攻击者能够影响请求目标、解析过程或重定向链路。审计时如果只搜索 HttpClient、requests.get 之类的调用，很容易漏掉经过多层封装的风险；修复时如果只增加一个字符串黑名单，也通常不够可靠。 本文以“服务端根据用户提交的 URL 抓取图片并生成缩略图”这一常见场景为例，整理一套偏工程化的分析方法。示例只用于本地测试和防御验证，不针对任何真实系统或第三方服务。 一、典型业务场景与风险边界 常见代码结构如下： String imageUrl = request.getParameter("url"); byte[] data = httpClient.get(imageUrl); return resize(data);从业务角度看，这段代码可能用于远程头像、图片转存、网页截图或文档解析。问题在于，url 由客户端控制，服务端网络权限通常又高于普通用户，因此请求可能被引导到不应暴露的内部资源。
T0xfce

从一次 Java Web 任意文件读取告警谈漏洞复现与代码审计思路

背景 最近在做一批 Java Web 系统的安全巡检时，遇到一类比较典型的告警：接口参数可控，后端根据参数拼接文件路径并返回文件内容。单看扫描器结论是“任意文件读取”，但实际风险需要结合代码路径、部署权限、过滤逻辑和业务场景判断。 这类问题在后台管理系统、报表下载、日志查看、模板预览、附件读取功能里比较常见。它不一定一上来就是高危，但如果能读取配置文件、密钥、日志、数据库连接串，往往会成为后续风险的入口。 本文整理一个偏通用的复现与审计思路，重点放在如何判断问题是否真实存在、如何定位代码根因，以及如何给出可落地的修复建议。内容仅用于授权测试和代码审计场景。 问题场景 业务系统中有一个文件预览接口，前端传入文件名，后端读取指定目录下的文件并返回内容。简化后的请求类似： GET /api/file/preview?name=report-2024.txt HTTP/1.1 Host: example.local Cookie: JSESSIONID=xxxx正常情况下，它只应该读取业务目录中的报表文件，例如： /data/app/reports/report-2024.txt但如果后端只是
T0xfce

从一次弱口令告警看 Web 登录面防护与审计落地

背景最近在内部做登录面巡检时，碰到一个比较典型的告警：某业务后台在短时间内出现大量登录失败记录，来源 IP 分散，用户名集中在 admin、test、operator、财务姓名拼音等常见组合。最终没有发现成功登录，但这类事件很适合拿来复盘登录面防护是否真的落地。很多团队对弱口令问题的理解还停留在“密码复杂度不够”，实际排查时会发现，弱口令只是结果，背后往往涉及账号枚举、日志缺失、限速策略缺位、历史测试账号未清理、统一身份认证未覆盖等多个问题。本文不讨论攻击操作细节，只从防守视角整理一套可复用的审计与加固方法。问题场景典型现象一般包括：登录接口出现大量 401、403 或业务层“密码错误”响应。失败用户名高度集中，存在明显的默认账号、姓名拼音、岗位名。来源 IP 较分散，但 User-Agent、请求间隔、参数结构相对固定。登录失败日志记录不完整，只记录了用户名和结果，没有源 IP、UA、请求 ID。系统没有统一验证码、限速、锁定或风险校验策略。这类问题的风险不只在于口令被猜中，还包括账号存在性泄露、后台路径暴露、员工信息被利用，以及后续撞库、社工风险提升。技术分析登录面安全可以拆成四层
T0xfce

从告警到结论：恶意样本分析中的证据链与可复现方法

在安全运营和应急响应中，最容易被忽略的不是工具，而是证据链。一个文件被杀毒软件标记为可疑，并不等于已经完成了分析；同样，看到几个字符串、几个网络地址，也不足以直接判断样本的功能和影响范围。比较稳妥的做法，是把样本分析拆成可复现的阶段：确认样本身份，建立隔离环境，进行静态分析，再根据风险决定是否动态验证，最后将结论转换为可检测、可处置的规则。本文以 Windows PE 样本为例，整理一套偏防守和研究用途的分析流程。一、先明确分析目标样本分析不应一开始就陷入反汇编细节。不同目标对应的证据要求不同，常见目标包括：确认文件是否为恶意程序，还是误报、测试工具或企业内部软件。判断样本是否执行了持久化、凭据访问、信息收集或横向活动。提取可用于检测和排查的 IOC，包括哈希、路径、注册表项、域名、互斥体和行为特征。评估同一活动中是否存在变种，避免只围绕单个文件做结论。建议在分析记录中区分“观察到的事实”和“基于事实的推断”。例如，“进程创建了一个计划任务”是事实；“该任务用于开机持久化”则是推断，需要结合触发条件和任务内容进一步确认。二、建立隔离且可回滚的实验环境动态分析必须在隔离环境中进行。实验机
T0xfce

一次 Java 文件上传漏洞审计的复盘：从入口定位到修复验证

背景 文件上传一直是 Web 系统里比较容易被低估的功能点。很多业务侧认为“限制一下后缀名”就够了，但在实际代码审计和应急排查中，上传链路往往牵涉到网关、应用框架、对象存储、静态资源服务、异步处理任务等多个环节。任何一个环节处理不严谨，都可能导致越权访问、任意文件覆盖、敏感信息泄露，甚至在特定部署条件下造成服务端代码执行风险。 这篇文章整理一次 Java Web 项目文件上传问题的审计思路。内容偏方法论和落地检查，不提供非法攻击操作，也不讨论绕过生产系统防护的细节。适合做代码审计、安全自查和修复验证时参考。 问题场景 某内部业务系统提供附件上传能力，常见入口包括头像、工单附件、富文本图片、导入模板等。系统采用 Spring Boot，上传后的文件会落到本地目录，再由 Nginx 映射为静态资源访问。审计目标是确认上传流程是否存在以下风险： 上传类型校验不完整，仅依赖文件名后缀。 文件保存路径可控，存在目录穿越或覆盖风险。 上传目录与可执行目录重叠，存在脚本文件被解析风险。 文件访问权限设计不当，导致未授权访问附件。 异常处理和日志记录暴露服务端路径、对象存储地址或临时凭证。 入口定位
T0xfce

从一次后台接口审计看水平越权问题的定位与修复

背景 后台管理系统里，越权问题一直不算“高深”，但在真实代码审计和测试中出现频率很高。尤其是基于 Spring Boot、MyBatis、JWT 或 Session 的业务系统，很多接口只做了“是否登录”和“是否具备菜单权限”的校验，却没有在数据层面限制资源归属，最后形成水平越权。 这篇文章整理一个偏实战的排查思路，重点放在代码审计、验证方法和修复方式上。示例均为本地简化代码，不涉及真实目标，也不提供未授权攻击引导。 典型场景 假设有一个工单系统，普通用户只能查看和修改自己创建的工单。接口大概如下： GET /api/ticket/detail?id=1001 POST /api/ticket/update Content-Type: application/json { "id": 1001, "title": "修改后的标题", "content": "补充说明" }从表面看，接口需要登录后访问；从权限菜单看，普通用户也确实有“工单查看”和“工单编辑”的功能权限。问题在于，如果后端只根据传入的 id 查询或更新数据，而没有校验这条工单是否属于当前用户，就可能产生水平越
T0xfce

从一次文件上传缺陷复盘谈 Web 代码审计的落地方法

背景 文件上传是 Web 安全里很常见的风险点，但真正做代码审计时，问题往往不在“有没有上传接口”这么简单，而是出现在校验链路不一致、存储位置不合理、解析行为被忽略、权限边界缺失等细节上。 这篇文章整理一次典型文件上传缺陷的复盘思路，重点放在如何审计、如何验证风险、如何修复和加固。内容只讨论授权环境下的安全测试与代码审计，不涉及未授权攻击或恶意利用。 典型场景 某业务系统提供附件上传功能，用于上传头像、工单附件、富文本图片等。系统后端通常会做以下限制： 限制文件后缀，例如只允许 jpg、png、pdf、docx。 限制 Content-Type，例如 image/jpeg、image/png。 限制文件大小。 将文件保存到固定目录。 返回文件访问 URL，供前端展示或下载。 表面看这些措施已经比较完整，但在审计中经常能看到几个问题：只校验客户端传来的文件名、只校验 Content-Type、不校验真实文件内容、上传目录可执行、文件名可控、下载接口缺少权限判断。 问题拆解 文件上传风险可以按链路拆成四段来看：接收、校验、存储、访问。 阶段常见问题审计重点接收信任前端参数、未限制大小Mul
T0xfce

一次 Java Web 文件上传漏洞的代码审计与修复思路

背景 文件上传是 Java Web 项目里很常见的功能，头像、附件、导入模板、富文本图片都会用到。它看起来只是一个业务能力，但安全边界比较复杂：文件名、扩展名、MIME、文件内容、存储路径、访问方式、后续解析链路都会影响风险。 这篇文章整理一次偏通用的代码审计思路，重点放在如何发现问题、如何验证风险、如何修复。内容不提供可直接用于入侵的攻击载荷，主要用于研发自查、安全评审和漏洞复盘。 问题场景 某 Java Web 系统提供附件上传接口，业务逻辑大致如下： @PostMapping("/upload") public String upload(@RequestParam("file") MultipartFile file) throws IOException { String fileName = file.getOriginalFilename(); String uploadDir = request.getServletContext().getRealPath("/upload/"); File dest = new File(uploadDir
T0xfce

从一次 Shiro 反序列化告警看 Web 漏洞复现与加固思路

背景 Shiro 反序列化问题已经不是新漏洞，但在实际资产排查和事件复盘里仍然经常出现。原因通常不是团队不知道这个风险，而是历史系统多、依赖版本混乱、默认密钥残留、网关改造后暴露面变化等问题叠加，导致风险长期存在。 这篇文章基于一次内部安全告警的复盘整理，重点放在如何安全确认风险、理解漏洞成因、做代码与配置层面的加固。文中不提供武器化利用链，也不讨论未授权控制主机等内容，只记录对防守和代码审计有价值的细节。 问题场景 某业务系统接入统一认证前，曾经单独使用 Apache Shiro 管理登录态。后续虽然改造到统一登录，但旧的 Shiro 依赖和过滤器配置没有完全移除，线上仍然返回 rememberMe 相关 Cookie。 监控侧看到异常请求集中命中以下特征： 请求中存在异常长度的 rememberMe Cookie； 部分请求触发后端反序列化异常日志； 访问路径并不集中在登录接口，而是覆盖多个普通业务路径； 异常来源 IP 分散，疑似自动化扫描。 从防守角度看，这类现象至少说明两个问题：第一，应用仍然启用了 Shiro rememberMe 处理逻辑；第二，应用可能暴露了可被探测的反
T0xfce

从 URL 预览到 SSRF 防护：一次完整的代码审计与修复实践

服务端请求伪造（SSRF）经常出现在“看起来很普通”的功能里，例如 URL 预览、远程图片抓取、Webhook 回调、文档导入和在线截图。它的危险不在于某一行代码本身，而在于应用把用户可控的字符串交给了具有网络访问能力的服务端组件。这类问题在审计中并不难被发现，难的是判断实际影响范围，并设计出不会被重定向、DNS 解析变化、IPv6 表示形式和代理配置绕过的修复方案。本文以一个 URL 预览服务为例，整理从入口定位、数据流分析、风险验证到修复和回归测试的完整过程。示例均面向本地授权测试环境，不涉及访问第三方内网或云平台元数据。一、背景：为什么 URL 预览容易引入 SSRF典型的 URL 预览流程如下：客户端提交一个 URL。服务端解析 URL，并发起 HTTP 或 HTTPS 请求。服务端读取响应内容，提取标题、摘要或图片。结果返回给前端，或者缓存到数据库。如果服务端对目标地址没有做严格限制，攻击者就可能让应用代替自己访问本机服务、内网管理面板、容器内部服务或其他受信任网络资源。即使响应内容不会直接返回，状态码、响应时间、错误信息和页面标题也可能成为信息泄露通道。在实际审计中，以下代
T0xfce

一次文件上传漏洞的代码审计复盘：从风险点定位到加固落地

背景 文件上传是 Web 系统里很常见的功能，头像、附件、工单截图、导入模板都会用到。它看起来只是一个业务入口，但如果校验、存储、访问控制处理不完整，往往会变成高危漏洞的起点。 这篇文章整理的是一次内部代码审计中的复盘。目标不是讲“如何打穿系统”，而是从安全审计视角拆解一个典型文件上传风险：后端只校验扩展名，上传目录又位于 Web 可访问路径下，最终导致非预期文件被直接访问。文章会重点放在风险识别、代码问题、修复方式和验证方法上。 问题场景 业务系统提供了一个附件上传接口，用于提交工单截图和文档。开发侧认为已经做了安全限制，因为前端限制了文件类型，后端也检查了文件后缀。但审计时发现几个明显问题： 前端校验可被绕过，不能作为安全边界。 后端只通过文件名后缀判断类型，没有校验实际内容。 上传文件保存到了 Web 根目录下的静态资源目录。 文件名使用用户原始文件名，存在覆盖、路径字符处理不严等风险。 上传接口缺少权限边界和大小限制，容易被滥用。 这类问题在老系统和快速迭代项目里很常见。单点看似不严重，组合起来就会变成高风险入口。 风险代码示例 下面是一段经过简化的 Java/Spring 风
T0xfce

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

背景 这篇整理来自最近一次内部系统代码审计复盘。系统是比较典型的 Spring Boot 后端，前端通过 JWT 登录后调用 REST API，权限模型包含用户、角色、部门、项目四层关系。问题本身不算新，但在真实项目里很常见：接口做了登录校验，也做了菜单权限控制，但业务数据权限没有落到具体资源上，最终形成了水平越权。 这里不讨论攻击利用，也不提供针对真实站点的操作指引。重点放在代码审计时如何定位这类问题、如何构造本地复现、以及修复时需要注意哪些边界。 问题场景 审计中发现一个项目详情接口，大致形式如下： GET /api/project/detail?id=1024后端控制器只校验了用户是否登录，以及是否具备“项目查看”菜单权限： @GetMapping("/detail") @PreAuthorize("hasAuthority('project:view')") public ProjectDetailVO detail(@RequestParam Long id) { return projectService.getDetail(id); }这个写法的问题在于，proj
T0xfce

一次 WebShell 入侵事件的复盘：从日志痕迹到代码审计闭环

背景 最近帮一套老旧业务系统做安全排查，起因是主机侧监控发现 Web 目录下出现了异常 PHP 文件，并且访问时间集中在凌晨。业务本身不大，典型的传统 PHP + Nginx + MySQL 架构，后台有文件上传、富文本编辑、插件管理等功能。 这类事件在中小型系统里很常见：入侵点未必复杂，往往是上传校验不严格、历史组件未更新、后台弱口令或配置暴露。本文不讨论攻击利用过程，而是整理一次偏防守视角的排查方法：如何从日志中定位入口，如何确认影响范围，如何回到代码层修复问题，并建立后续检查清单。 问题场景 现场环境大致如下： Web 服务：Nginx 1.20 运行环境：PHP 7.4-FPM 应用类型：自研 CMS，部分历史模块多年未维护 上传目录：/data/www/app/public/uploads/ 日志路径：/var/log/nginx/access.log、/var/log/nginx/error.log 异常现象包括： 上传目录出现随机命名的 PHP 文件 Nginx access log 中存在访问该文件的记录 业务用户反馈偶发 500 错误 Web 目录内部分文件 mtim
T0xfce

从 URL 预览功能看 SSRF 漏洞审计：定位、复现与工程化修复

URL 预览、网页截图、远程文件导入、Webhook 测试等功能，通常都需要由服务端主动访问用户提交的地址。这类功能本身并不危险，但一旦缺少严格的目标校验，就可能演变为服务端请求伪造（SSRF）。 SSRF 的风险不只在于“访问了一个不该访问的 URL”，更在于请求发生在服务器所在的网络环境中：服务器可能具备访问内网管理面板、服务注册中心、云平台元数据接口或本地调试端口的权限。因此，审计这类问题时，重点不是寻找一个能发起请求的接口，而是完整分析“输入如何到达网络连接点”，以及应用是否在每个跳转和解析阶段持续执行安全策略。 一、典型场景与审计目标 常见代码形态包括： 用户提交 URL，后端抓取标题并生成预览卡片； 后台导入远程图片、压缩包或文档； Webhook 配置页面允许管理员测试回调地址； 服务端根据 URL 生成二维码、截图或转码结果； 代码审计中出现 HTTP 客户端、文件下载器或 XML 外部实体解析器。 审计目标可以拆成四个问题： 外部输入是否能够影响请求目标、协议、端口或请求方法？ 应用是否允许访问本机、内网、环回地址、链路本地地址或 Unix Socket？ 域名解析、
T0xfce

从一次 SSRF 告警复盘看内网探测风险与代码侧防护

背景 SSRF（Server-Side Request Forgery）这类问题在日常代码审计和应急排查中出现频率很高。它的危险点不在于“服务端发起了一次请求”本身，而在于请求目标、协议、重定向链路、DNS 解析结果、云环境元数据地址等因素叠加后，可能让一个普通的 URL 抓取功能变成内网探测入口。 这篇整理来自一次真实业务场景的复盘：某系统提供“远程图片抓取”和“URL 预览”能力，安全设备发现服务端对多个内网地址产生异常请求。最终确认问题并非单点漏洞，而是 URL 校验、重定向处理、DNS 解析和出网策略都存在缺口。 问题场景 业务接口大致逻辑如下：用户提交一个 URL，后端请求该 URL，获取图片或网页标题，然后存储或展示给前端。常见代码形态包括： POST /api/fetch-preview Content-Type: application/json { "url": " }看起来只是一个普通的服务端 HTTP 客户端调用，但风险点通常出现在以下位置： 只用字符串前缀判断 URL 是否以 http 或 https 开头。 只校验用户输入的原始域名，没有校验最终解析出的
T0xfce

从一次 WebShell 告警复盘看 PHP 站点的入侵排查思路

背景 最近在做一批老旧 PHP 站点的安全巡检时，遇到一个比较典型的 WebShell 告警案例。站点本身业务不复杂，LNMP 架构，PHP 版本偏旧，目录里存在历史遗留的上传接口和多个第三方插件。告警来自主机侧文件监控，提示某个图片上传目录下出现异常 PHP 文件。 这类事件在实际环境里很常见：单点文件被查杀后删除，但没有继续追溯入口、持久化和横向影响，几天后又会反复出现。本文整理一套偏实战的排查流程，重点放在定位入侵路径、确认影响范围和加固闭环，不涉及攻击利用细节。 场景与初步现象 主机告警文件路径类似： /data/www/example.com/public/uploads/2024/11/.cache.php从文件名看有伪装痕迹，位置在上传目录，且以点开头隐藏。进一步查看文件属性： stat /data/www/example.com/public/uploads/2024/11/.cache.php ls -la /data/www/example.com/public/uploads/2024/11/ file /data/www/example.com/public/u
T0xfce

从一次代码审计看文件上传风险的完整治理思路

背景 文件上传一直是 Web 安全里比较容易被低估的功能点。很多系统在设计时只把它当作“业务附件”处理，比如头像、合同、工单图片、日志压缩包等，但从攻击面角度看，上传功能同时涉及文件类型识别、存储路径、访问权限、解析行为、内容安全、后续处理链路等多个环节。 我在做代码审计和漏洞复现时，经常遇到一种情况：单点看上传接口似乎做了扩展名校验，也限制了大小，但结合部署环境、中间件解析规则、对象存储策略、异步解压任务之后，风险会被放大。本文整理一套偏长期价值的审计思路，重点是如何发现问题、如何验证风险、如何修复治理，不涉及恶意利用引导。 典型场景 常见的上传链路大致如下： 前端选择文件并提交到后端接口。 后端检查文件名、扩展名、MIME、大小。 服务端生成存储路径，并将文件保存到本地目录、NFS 或对象存储。 数据库记录文件 URL、原始文件名、上传人、业务 ID。 后续由下载接口、预览接口、图片处理服务、解压任务或杀毒引擎处理。 真正需要关注的不是“能不能上传一个特殊后缀”，而是上传后的文件是否会被不安全地解析、访问、包含、执行或二次处理。 问题拆解 审计上传功能时，我一般按以下几个问题拆解：
T0xfce

一次较完整的 Web 代码审计思路：从入口梳理到可复现修复

背景 很多代码审计文章会直接从某个漏洞点切入，比如 SQL 注入、文件上传、反序列化。但实际项目审计时，更常见的问题是：代码量不小、框架不统一、业务逻辑杂，单点检索容易漏掉关键路径。本文整理一套偏实战的 Web 代码审计流程，重点放在如何建立入口视图、跟踪数据流、确认风险边界，以及如何把问题整理成可复现、可修复的结论。 这里不针对某个具体系统，也不提供攻击性利用链，示例代码和命令仅用于本地审计、测试环境验证和修复确认。 审计目标与常见场景 代码审计的目标不是“找几个洞”这么简单。比较可靠的审计结果至少要回答几个问题： 外部输入从哪里进入系统，例如路由参数、表单、JSON Body、Header、Cookie、文件上传、第三方回调。 输入经过哪些校验、转换、拼接、存储和输出。 敏感操作是否有统一鉴权和权限边界。 危险函数或组件是否被业务包装过，包装层是否可靠。 漏洞能否在测试环境稳定复现，修复是否能被回归验证。 实际审计中，比较容易产生高价值发现的场景包括：后台管理接口、导入导出功能、文件处理、模板渲染、报表查询、第三方登录回调、消息队列消费、定时任务、插件扩展机制。 第一步：建立项目入
T0xfce

一次 Spring 应用 SSRF 风险排查与加固记录

SSRF 是 Web 安全里很常见的一类问题，但在实际代码审计中，它往往不是以“明显漏洞点”的形式出现，而是藏在图片抓取、Webhook 回调、URL 预览、文件导入、第三方接口转发等业务逻辑里。本文整理一次 Spring 应用中的 SSRF 风险排查思路，重点放在如何识别风险、如何验证边界、以及如何做工程化加固。 文章内容仅讨论授权环境下的安全测试和防护实现，不涉及对第三方系统的攻击利用。 背景 某业务系统提供了一个“远程资源导入”功能，用户提交一个 URL，后端会下载该 URL 对应的图片或文档，并保存到对象存储。功能本身很常见，代码逻辑大致如下： String url = request.getParameter("url"); RestTemplate restTemplate = new RestTemplate(); ResponseEntity<byte[]> resp = restTemplate.getForEntity(url, byte[].class); byte[] data = resp.getBody(); // 后续进行类型识别、上传对象存储
T0xfce

一次后台接口越权问题的代码审计复盘：从权限模型到修复验证

背景 最近整理历史项目代码审计记录时，发现一类问题出现频率很高：后台接口已经做了登录校验，也有菜单权限控制，但在具体数据访问层缺少对象级权限校验，最终形成越权访问。这个问题不算新，但在企业内部系统、SaaS 管理后台、低代码平台里很常见，影响也比较实际。 本文基于一个脱敏后的场景做复盘，重点放在审计思路、问题定位、修复方式和验证方法。文中不会涉及真实目标，也不会给出可用于未授权攻击的操作引导。 问题场景 系统是一个典型的前后端分离后台，后端使用 Java Spring Boot，权限模型大致如下： 登录态通过 JWT 或 Session 维护； 菜单和按钮权限通过 RBAC 控制； 用户归属于不同租户或部门； 业务对象包括项目、工单、客户记录等； 接口层多数使用注解做权限校验。 表面看权限体系比较完整，但在审计时发现一个细节：部分详情接口、导出接口、状态修改接口只校验了“是否有功能权限”，没有校验“当前用户是否有权访问该条业务数据”。这就是典型的 IDOR / BOLA 类问题。 技术分析 先看一个简化后的接口示例： @GetMapping("/workorder/detail") @
T0xfce

从一次 SSRF 复现看内网探测风险与代码审计要点

背景SSRF（Server-Side Request Forgery，服务端请求伪造）在实际漏洞挖掘和代码审计里出现频率不低。它的本质不是“让浏览器访问某个地址”，而是诱导服务端以自己的网络位置、权限和出口策略去访问攻击者指定的资源。这类问题的危险点在于：服务端通常位于内网、云环境或受信任网段，能访问到普通用户无法直接访问的接口，例如内部管理服务、元数据服务、未鉴权的 RPC、运维面板等。本文不讨论攻击利用链，只从安全研究和防护视角整理一次典型 SSRF 风险的复现思路、代码审计要点和修复建议。本文示例均以本地测试环境为前提，重点是识别风险与加固，不提供针对真实目标的攻击操作。典型场景SSRF 常见于以下业务功能：远程图片抓取、头像上传、文章封面解析URL 预览、网页标题抓取、链接转码PDF/截图生成服务，例如传入 URL 后服务端渲染页面Webhook 回调测试、HTTP API 调试工具文件导入功能，例如支持从 URL 拉取 CSV、XML、JSON从代码层面看，只要存在“用户可控 URL”并由服务端主动请求，就应该按 SSRF 风险处理。问题代码示例下面是一段简化后的 Java
T0xfce