跳转到帖子
应急响应中心

应急响应中心

保存

应急响应中心部落格

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

  • 篇帖子

    283

  • 篇意见

    0

  • 次查看

    2339

关于此博客

一次 Java Web 任意文件读取漏洞的审计与加固思路

背景 任意文件读取是 Java Web 项目里比较常见、也比较容易被低估的一类问题。它不像远程命令执行那样直观，但在真实环境中，一旦能读取配置文件、日志、密钥文件或源码片段，后续风险会明显放大。 这篇文章整理的是一次代码审计中遇到的文件下载接口问题。内容重点放在审计思路、漏洞成因、复现边界和修复方式上，不涉及对第三方系统的攻击利用。类似问题在 Spring MVC、Servlet 老项目、管理后台附件下载模块里都比较常见。 问题场景 项目中有一个附件下载接口，业务设计是根据前端传入的文件名，从服务器指定目录下读取文件并返回给用户。简化后的代码如下： @GetMapping("/download") public void download(@RequestParam("file") String file, HttpServletResponse response) throws IOException { String baseDir = "/data/app/upload/"; File target = new File(
T0xfce

从一次接口越权排查谈 Web 代码审计的落地方法

背景 在实际业务安全评估里，接口越权是我见得比较多、也比较容易被低估的一类问题。它不像反序列化、RCE 那样“显眼”，但一旦出现在订单、工单、文件、审批、租户管理等模块，影响往往不小。 这篇文章不讨论如何攻击具体系统，而是整理一次典型接口越权排查的思路：如何从现象定位到代码，如何判断是水平越权还是垂直越权，如何把修复建议落到开发可执行的层面。适合用于内部安全测试、代码审计和缺陷复盘。 问题场景 一个常见场景是：系统中存在“查看详情”接口，前端页面通过资源 ID 查询数据。例如订单详情、项目详情、文件详情、客户详情等。 GET /api/order/detail?id=1024正常情况下，用户只能查看自己名下或自己组织范围内的数据。但如果服务端只根据传入的 id 查询记录，没有校验当前登录用户与该资源之间的关系，就可能导致水平越权。 另一个常见场景是后台功能入口被前端隐藏，但接口本身没有做角色校验。例如普通用户无法在菜单里看到“用户管理”，但直接访问接口仍然能查询敏感数据，这类通常属于垂直越权。 技术分析 越权问题的核心不是“接口有没有登录态”，而是“登录态与资源、动作、角色之间是否建立
T0xfce

从一次 SSRF 漏洞复盘看内网探测风险与修复要点

背景SSRF（Server-Side Request Forgery）在实际代码审计和漏洞复现中很常见，尤其出现在图片抓取、Webhook 回调、URL 预览、PDF 生成、文件导入等功能里。它的危险点不在于“能不能请求一个外部 URL”，而在于请求是由服务端发起的，可能触达普通用户访问不到的内网地址、云厂商元数据接口或本机管理端口。这篇文章整理一次典型 SSRF 风险的分析思路，重点放在安全验证、代码审计和修复方案上。内容不涉及非法攻击目标，也不提供对第三方系统的攻击引导，适合作为内部安全评审或研发自查参考。常见场景在业务里，以下功能比较容易引入 SSRF：用户提交图片 URL，服务端下载后转存到对象存储。文章链接预览，服务端抓取标题、描述、favicon。Webhook 配置，系统主动向用户填写的地址发送通知。PDF/截图服务，后端渲染用户提供的页面地址。远程文件导入，例如通过 URL 导入 CSV、XML、JSON。这些功能本身没有问题，问题通常出在“把用户输入的 URL 原样交给服务端 HTTP 客户端请求”，并且缺少协议、地址、重定向、DNS 解析等限制。问题样例下面是一段简
T0xfce

一次 Webshell 排查与溯源的实战整理：从日志到代码审计

背景 Webshell 排查是应急响应里很常见的一类工作。很多时候，告警并不会直接告诉你“哪个文件是木马”，而是给出一些零散线索：异常 POST 请求、Web 目录新增文件、进程启动了系统命令、某个 PHP 文件被频繁访问等。 这篇文章整理一套偏实战的排查思路，重点放在日志分析、文件定位、代码审计和加固复盘上。内容只讨论防守侧分析方法，不涉及未授权利用、恶意控制或规避检测。 典型场景 场景可以简化为：一台运行 PHP 站点的服务器出现异常安全告警，告警信息包括： Web 服务进程存在异常子进程，例如 sh、bash、cmd、curl、wget 等； 站点目录出现近期新增的 PHP 文件； 访问日志中存在异常 POST 请求，URL 不属于正常业务接口； 部分请求 User-Agent、Referer、请求体长度明显异常； 服务器对外发起了不符合业务特征的连接。 实际排查时，不建议一开始就凭经验删除文件。更稳妥的做法是先保全证据，再做定位，最后做清理和修复。 第一步：保全现场与确认影响面 如果是生产环境，建议先做最小化影响处理，例如临时下线可疑入口、限制外联、备份日志和可疑文件。直接重启
T0xfce

一次内网 WebShell 告警的复盘：从日志定位到代码层加固

背景 最近在一次内网安全巡检中，某业务系统触发了 WebShell 行为告警。系统本身不对公网开放，但部署链路较长，包含反向代理、应用容器、共享文件目录和定时任务。这个场景比较典型：外部攻击迹象不明显，告警来自运行时行为，排查重点不能只停留在“删文件”，需要把入口、落点、执行链和加固项梳理清楚。 本文整理这次排查过程中的方法和注意点，偏防守和复盘视角，不涉及攻击利用步骤。类似工作中，建议优先在隔离环境或只读方式下分析证据，避免破坏时间线。 问题场景 告警信息比较简短，核心字段包括： 可疑脚本路径：应用上传目录下的一个非预期 PHP 文件 触发行为：执行系统命令相关函数 来源进程：Web 服务进程 时间点：凌晨业务低峰期 初看像是上传目录落了脚本，但实际排查时不能直接下结论。上传目录出现脚本通常只是“结果”，入口可能来自文件上传校验缺陷、历史遗留后台、备份包泄露、依赖组件漏洞，甚至是运维误操作导致的写入权限扩大。 排查思路 我一般按四条线并行推进：文件线、日志线、进程线、代码线。 文件线：确认可疑文件的创建时间、修改时间、属主、权限、哈希和同目录异常文件。 日志线：按时间窗口回溯访问日志
T0xfce

从代码审计到修复：系统化分析 URL 代理服务中的 SSRF 风险

服务端请求伪造（SSRF）并不只存在于“允许用户提交 URL”这一类明显场景中。图片抓取、网页预览、Webhook 测试、文档转换、远程资源导入等功能，只要由服务端代替用户发起网络请求，就可能形成 SSRF 攻击面。实际审计中，真正困难的部分通常不是找到一个请求点，而是判断请求是否能访问不应暴露的网络区域、是否能被重定向绕过限制，以及修复后是否仍存在解析差异。 本文以 URL 代理服务为例，整理一套适合代码审计、漏洞复现和上线前验证的分析方法。示例均以本地测试环境和防御性验证为前提，不涉及访问真实内网资源。 一、问题场景：一个看似普通的 URL 抓取接口 典型业务代码可能类似下面这样： def fetch_url(url): response = requests.get(url, timeout=10) return response.text如果接口直接接受外部输入并返回响应内容，风险通常包括： 访问仅对服务器可见的内部管理页面、监控接口或开发服务。 利用服务器所在网络的访问权限探测内网端口。 通过云环境中的特殊地址获取实例身份凭据等敏感信息。 借助重定向、DNS
T0xfce

从代码审计到修复：系统梳理 Web 应用 SSRF 风险与防护要点

SSRF（Server-Side Request Forgery，服务端请求伪造）在代码审计中很常见。它通常不是一个“单点漏洞”，而是由用户可控 URL、服务端网络访问能力、协议处理不严谨以及出站访问缺少隔离共同造成。实际排查时，如果只过滤几个字符串，往往只能挡住最简单的测试用例，无法覆盖重定向、IPv6、DNS 解析和代理配置等场景。本文以代码审计和防守为主线，整理 SSRF 的形成条件、常见误区、可复现的安全测试方法，以及更适合生产环境的修复思路。示例均应在自建靶场或已授权的测试环境中使用。一、问题背景：为什么 SSRF 容易被低估很多业务都需要服务端访问外部资源，例如图片抓取、Webhook 回调、在线文档解析、第三方接口代理和 URL 预览。典型代码大致如下：from urllib.parse import urlparse import requests def fetch_url(url): parsed = urlparse(url) if parsed.scheme not in ('http', 'https'): raise
T0xfce

从一次代码审计看 Java Web 文件上传风险的定位与加固

背景 文件上传是 Java Web 项目里很常见的功能，头像、附件、导入模板、工单图片都会用到。它本身不是高危功能，但一旦边界处理不严，往往会变成比较典型的入口风险：覆盖文件、任意类型上传、路径穿越、服务端解析异常、对象存储权限失控，甚至在特定部署条件下引发代码执行。 这篇文章整理的是我在日常代码审计和整改复盘里比较常见的一类问题。重点不放在“如何利用”，而是放在如何发现风险点、判断影响面，以及如何做一套相对稳妥的工程化加固。 典型场景 很多业务项目里的上传接口大致会写成下面这种形式：前端限制文件后缀，后端接收 MultipartFile，然后用原始文件名拼接保存路径，最后返回一个可访问 URL。 @PostMapping("/upload") public Map<String, Object> upload(@RequestParam("file") MultipartFile file) throws IOException { String fileName = file.getOriginalFilename(); File dest = new
T0xfce

从代码审计到修复验证：一次 SSRF 风险的完整分析方法

SSRF（Server-Side Request Forgery，服务端请求伪造）并不只存在于“允许用户提交 URL”的简单接口中。文件预览、Webhook、图片抓取、富文本转码、PDF 生成以及第三方回调检测等功能，都可能间接产生服务端出网请求。实际审计中，真正困难的部分通常不是发现一个 URL 参数，而是确认请求是否由服务端发起、是否能够触达不应访问的网络区域，以及修复后是否仍存在 DNS 重绑定、重定向或协议解析差异。 一、问题背景与典型场景 以下代码看起来只是一个远程图片下载功能： public byte[] download(String url) throws IOException { return httpClient.get(url).getBody(); }如果 url 完全由用户控制，服务端就可能访问内网管理页面、本机服务或云环境中的特殊地址。即使应用本身没有返回响应内容，攻击者仍可能通过状态码、响应时间、错误信息或业务副作用判断目标是否可达。 常见风险来源包括： 图片、头像、Markdown 或文档预览服务支持远程地址。 Webhook 校验功能会主动请
T0xfce

从一次代码审计视角看 SSRF 漏洞的识别与加固

背景SSRF（Server-Side Request Forgery，服务端请求伪造）在实际业务里并不罕见，尤其常见于图片抓取、URL 预览、Webhook、文件导入、远程资源同步等功能。它的风险点不只在于“服务端能替用户发请求”，更关键的是服务端所处的网络位置通常比外部用户更敏感，可能访问到内网服务、云厂商元数据接口或未暴露在公网的管理端口。这篇文章主要从代码审计和防护落地角度整理 SSRF 的识别思路，不讨论攻击内网目标或获取敏感凭据的具体利用过程，重点放在如何发现风险点、如何验证边界、如何加固。典型场景在审计 Web 项目时，下面几类功能需要重点关注：根据用户提供的 URL 抓取图片、头像、封面、视频信息。在线文档转换、PDF 生成、HTML 转图片。Webhook 回调地址配置。URL 健康检查、站点连通性测试。导入远程文件、远程模板、RSS 或 sitemap。后端代理下载文件，再上传到对象存储。这些功能的共同点是：用户输入最终影响了服务端发起网络请求的目标地址。如果缺少严格校验，就可能形成 SSRF 风险。问题代码示例下面是一个常见的远程图片下载逻辑，业务上看起来很正常，但
T0xfce

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

背景 任意文件读取是 Java Web 项目里比较常见、也容易被低估的一类问题。它不一定直接导致系统被控制，但一旦能够读取到配置文件、密钥、日志、备份包，后续风险会被明显放大，例如数据库凭据泄露、JWT 密钥泄露、云访问密钥泄露等。 这篇文章整理一个偏通用的审计思路：从一个文件下载接口入手，分析路径拼接、参数校验、目录限制和修复方式。内容以防护和代码审计为主，不涉及未授权入侵或真实目标攻击。 问题场景 项目中常见一个下载接口，前端传入文件名或相对路径，后端从指定目录读取文件并返回： @GetMapping("/download") public void download(@RequestParam String file, HttpServletResponse response) throws IOException { String baseDir = "/data/app/upload/"; File target = new File(baseDir + file); response.setHeader("Content-Disposition",
T0xfce

一次内网 WebShell 事件的复盘：从日志异常到代码审计闭环

背景 最近整理了一次较典型的 WebShell 事件处置过程。场景并不复杂：一套老旧 PHP 业务系统部署在内网，前面挂了反向代理，业务方反馈后台偶发 500，并且服务器上出现异常 PHP 文件。由于这类事件在企业环境里比较常见，复盘时我更关注两件事：第一，如何从有限日志中尽快确认入侵路径；第二，如何把处置结果反推到代码审计和加固清单中，避免只删文件不修洞。 本文不会展开攻击利用细节，重点放在取证、分析、定位漏洞和修复建议上。命令和配置示例也以排查、防护为目的。 问题场景 业务架构大致如下： Nginx 反向代理到 PHP-FPM。 业务代码为多年维护的传统 PHP 项目。 存在后台文件上传、富文本编辑器、导入导出等功能。 服务器保留了 Nginx access/error 日志、PHP-FPM slow log、系统审计日志不完整。 初始告警来自两个现象： Web 根目录下新增了若干命名随机的 PHP 文件。 access.log 中出现大量对这些文件的 POST 请求，User-Agent 固定且不像正常浏览器。 这种情况下不要急着直接删除文件。更稳妥的做法是先隔离、保全证据、确认
T0xfce

从代码审计到修复验证：系统化分析 Webhook SSRF 风险

Webhook、回调地址和“导入远程资源”功能，往往需要服务端主动访问用户提供的 URL。这个设计本身并不等于漏洞，但如果缺少协议限制、目标校验和网络出口控制，攻击者可能借助应用服务器访问原本不应暴露的内部服务，形成服务端请求伪造（SSRF）风险。这类问题的难点不在于找到一个可以发起 HTTP 请求的参数，而在于判断请求链路是否真的由服务端执行、跳转和 DNS 解析是否可控、最终连接的目标是否经过有效校验，以及修复后是否能够抵抗编码、重定向和解析差异带来的绕过。一、常见业务场景与审计入口在代码审计中，可以优先关注以下功能：Webhook、回调通知、第三方集成配置。头像、文档、图片或远程压缩包导入。在线预览、网页截图、Markdown 远程渲染。通过 URL 检查站点状态、生成分享卡片或抓取网页标题。后台任务、消息队列消费者和定时同步程序中的远程请求。审计时不要只搜索参数名。更可靠的方法是从网络请求的调用点反向追踪数据流，重点搜索 HTTP 客户端、URL 解析器、重定向处理和代理配置。例如 Java 项目中可以关注 RestTemplate、WebClient、HttpURLConne
T0xfce

企业内网 SSRF 风险的审计与加固：从数据流追踪到出网控制

服务端请求伪造（SSRF）并不是简单的“把 URL 交给 HTTP 客户端”问题。真正难审计的地方在于：请求入口可能隐藏在图片抓取、Webhook、文档解析、URL 预览、云资源探测等业务中；而防护也不能只靠拦截几个内网 IP。本文以代码审计和安全验证为主线，整理一套适合企业项目的 SSRF 排查、复现与加固方法。 一、问题背景与典型场景 当应用允许用户提交一个 URL，并由服务端代为访问时，服务端就成为了请求发起者。如果访问目标、协议、跳转策略或网络出口缺乏限制，攻击者可能诱导应用访问本不应暴露的管理接口、内部服务或云环境元数据地址。 常见功能包括： 远程图片下载、头像抓取和图片转存； Webhook、回调地址或第三方通知配置； URL 预览、网页截图、网页转 PDF； RSS、Markdown、Office 文档中的远程资源解析； 在线导入、镜像同步和健康检查功能。 这里需要强调，SSRF 的风险不一定表现为“读取敏感内容”。在实际事件中，更常见的是利用服务端网络位置访问内部管理面板、调用缺少认证的内部接口，或者借助出网能力进行内网资产探测。因此，审计时应同时关注数据读取、内部访问
T0xfce

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

背景 任意文件读取在 Java Web 项目里并不少见，尤其是历史系统中存在大量下载、预览、导出接口时，很容易因为路径拼接不当引入问题。它通常不像 RCE 那样显眼，但实际影响不低：配置文件、日志、源码片段、密钥文件一旦被读取，后续风险会被放大。 这篇文章整理一次偏通用的代码审计过程，重点放在如何定位问题、如何确认风险边界，以及如何修复。文中的代码和路径均做了脱敏处理，不涉及真实目标。 场景描述 某 Java Web 系统提供文件预览接口，前端传入文件名，后端从指定目录读取并返回内容。功能本身很常见，例如读取用户上传的附件、导出报表或查看模板文件。 问题出在后端只做了简单字符串拼接，没有限制最终读取路径必须位于业务目录内。典型代码如下： String basePath = "/data/app/files/"; String fileName = request.getParameter("file"); File file = new File(basePath + fileName); if (!file.exists()) { response.setStatus(40
T0xfce

从一次未授权访问告警谈内网 Web 服务暴露面的收敛

背景 这类问题在内网并不少见：某个业务系统原本只打算给少量运维或研发使用，后来因为联调、临时排障、容器迁移等原因，被挂到了更大的网段，甚至被反向代理统一入口带了出去。等到日志平台出现未授权访问告警时，往往已经很难一句话说清楚“这个服务到底应该被谁访问”。 本文整理一次比较典型的排查思路，重点放在暴露面识别、访问控制校验、日志证据链和修复收敛上。内容只讨论防护和审计，不涉及攻击利用细节。 问题场景 场景大致如下： 某内网 Web 管理服务出现异常访问告警，访问来源并非预期运维网段。 服务本身没有完整登录体系，只依赖 Nginx 反向代理上的 IP 白名单。 近期做过容器化改造，服务从物理机迁移到 Kubernetes 集群。 日志中出现对管理接口的批量探测请求，但没有发现明确的数据修改行为。 这种问题的核心不是单点漏洞，而是“边界假设失效”。很多内部系统默认认为自己处在可信网络里，权限模型会比较粗糙，一旦网络边界变化，风险会快速放大。 技术分析 1. 先确认入口链路 排查时不建议直接盯着应用代码看，第一步应该画清楚访问链路。常见入口包括： 办公网到内网服务的直连访问。 Nginx、Apa
T0xfce

从一次代码审计看文件上传链路的风险收敛

背景 文件上传是 Web 系统里很常见的功能，但也是代码审计中反复出现问题的模块。很多团队会在入口处做扩展名校验，却忽略存储路径、解析行为、对象存储回源、预览服务、异步处理任务等后续链路，最后导致风险并不在“上传接口本身”，而是在上传后的使用方式里被放大。 这篇文章结合平时审计中的经验，整理一套偏长期可复用的分析思路。内容聚焦于防守视角和安全验证，不提供未授权攻击或恶意利用步骤。 典型场景 一个常见业务链路大概是这样： 用户通过前端选择头像、附件、合同、图片素材等文件； 后端接口接收 multipart/form-data 请求； 服务端校验文件大小、扩展名、Content-Type； 文件保存到本地、NFS、对象存储或 CDN 源站； 业务侧返回可访问 URL； 后续可能进入图片压缩、文档预览、OCR、病毒扫描、异步转码等流程。 审计时如果只盯着上传接口，通常只能发现一部分问题。真正需要关注的是：这个文件最终会被谁读取、以什么权限读取、在哪里被解析、是否会被当作可执行内容处理。 风险拆解 1. 扩展名校验不足 最基础的问题是仅依赖前端限制或简单字符串判断，例如只检查文件名是否包含 .
T0xfce

从一次 SSRF 代码审计看 URL 校验的边界与工程化防护

SSRF（服务端请求伪造）在实际项目中并不难被忽略：业务代码往往只是接收一个 URL，调用 HTTP 客户端抓取内容，再把结果返回给用户。问题在于，请求是由服务器发出的，攻击者可以借此让服务器访问本不应暴露的内部服务、云平台元数据接口或管理端口。 这类问题的难点通常不在于发现一个危险函数，而在于判断 URL 是否真正受控、校验是否覆盖了完整请求链路，以及 DNS 解析、重定向、代理配置和 IPv6 等边界条件是否被考虑。下面以代码审计和修复为主线，整理一套适合项目落地的分析方法。 一、常见业务场景与风险边界 以下功能都可能引入服务端请求： 头像、网页缩略图或远程文件导入。 Webhook、第三方回调测试、站点连通性检测。 PDF、Markdown、RSS、在线文档或图片转换。 支付、消息、监控系统中的 URL 探测功能。 后台管理页面提供的接口调试或数据同步功能。 审计时不能只关注参数名为 url 的接口。只要用户输入最终参与了 HTTP、HTTPS、TCP 或其他网络客户端调用，都应纳入检查范围。 二、代码审计的切入点 第一步是从网络请求函数反向追踪输入来源。不同语言中常见的危险调用
T0xfce

一次 WebShell 告警排查复盘：从入口定位到加固闭环

背景 最近帮一个中小型业务站点做安全排查，起因是主机侧 EDR 报了一条 WebShell 行为告警：Web 进程在站点目录下创建了一个可执行脚本文件，并在短时间内出现了异常 POST 请求。这个场景在实际运维里比较常见，难点不在于“删掉木马”，而是确认入口、影响范围和后续加固是否闭环。 本文整理一次相对完整的排查思路，重点放在日志关联、文件取证、代码审计和修复验证。涉及的命令和样例均为防守排查用途，不包含利用细节。 问题场景 业务环境大致如下： Linux 主机，Nginx + PHP-FPM。 站点存在后台文件上传功能，用于上传图片和附件。 告警文件位于 /data/www/example.com/public/uploads/2024/ 目录。 访问日志中出现针对该文件的多次 POST 请求。 初看像是上传目录被写入了可执行脚本，但实际排查不能只看文件名和路径。常见误区是直接删除可疑文件后结束处理，这样很容易遗漏入口，比如上传校验缺陷、历史插件漏洞、弱口令后台、定时任务被篡改等。 技术分析 1. 先固定现场，避免证据丢失 排查开始时建议先做只读备份，至少包括可疑文件、访问日志、错
T0xfce

一次 Web 登录接口审计复盘：从认证逻辑到日志留痕的安全加固

背景登录接口是 Web 系统里最常见、也最容易被忽视的攻击面。很多安全问题并不是出在密码学算法本身，而是出在认证流程、错误处理、频率控制、会话管理和日志留痕这些细节上。这篇文章整理一次比较典型的登录模块代码审计思路，重点放在可复用的检查方法和加固建议上。内容不涉及未授权攻击利用，不提供针对真实系统的攻击操作步骤，更偏向研发、安全测试和代码审计人员做内部自查。场景描述假设一个常见的后台登录接口，调用链大致如下：前端提交用户名、密码、验证码或一次性令牌。后端查询用户信息，校验密码哈希。校验通过后创建会话或签发 Token。记录登录日志，返回用户基础信息。从功能角度看这套流程很简单，但实际审计时经常能看到以下问题：用户名不存在和密码错误返回不同提示，导致账号枚举风险。密码校验前后逻辑分支明显不同，响应时间差异较大。验证码只在前端控制，后端未强制校验。失败次数限制只按用户名统计，容易被换用户名或换来源绕过。登录成功后未刷新 Session ID，存在会话固定风险。日志只记录成功登录，失败行为无法追踪。技术分析登录接口审计不建议只盯着“能不能登录成功”，而应该按认证链路拆开看。比较实用的审计维度
T0xfce

从一次未授权访问排查看 API 鉴权与越权漏洞审计

背景 最近在做一轮内部系统安全复盘时，遇到一个比较典型的问题：某业务后台的接口没有明显报错，也没有高危组件漏洞，但通过日志可以看到少量异常访问命中了用户信息查询接口。最后确认问题不是传统意义上的“未登录访问”，而是接口鉴权边界不清导致的水平越权。 这类问题在 Web 安全里很常见，尤其是前后端分离、微服务拆分后，很多接口默认依赖前端控制入口，后端只做了登录态校验，却没有做资源归属校验。本文整理一下排查思路、审计重点和修复建议，偏长期可复用的方法，不涉及真实目标攻击操作。 问题场景 业务形态大致如下：用户登录后可以查看自己的订单、资料、工单等信息，前端通过用户 ID、订单 ID 或工单 ID 调用后端 API。接口示例类似： GET /api/order/detail?id=10086 Authorization: Bearer eyJxxx...表面上接口已经要求登录，并且 token 校验正常。但如果后端只判断“当前请求是否已登录”，没有判断“当前用户是否拥有该订单”，就会出现越权风险。 常见表现包括： 修改 URL 或请求体中的 id 参数后，返回了其他用户资源。 列表接口做了用户
T0xfce

从代码审计到修复验证：系统梳理 Web 应用中的 SSRF 风险

SSRF（Server-Side Request Forgery，服务端请求伪造）并不是一个只靠“拦截内网 IP”就能解决的问题。实际审计中，风险通常出现在图片抓取、Webhook、URL 预览、文档转换、第三方接口探测等功能里。应用一旦允许用户影响服务端发起网络请求，就需要同时考虑协议限制、地址解析、重定向、DNS 变化、响应大小和网络出口控制。 一、问题背景与典型场景 常见代码模式是接收一个 URL，然后由后端下载内容并返回给用户。例如： String target = request.getParameter("url"); URL url = new URL(target); URLConnection connection = url.openConnection(); InputStream input = connection.getInputStream(); 这段代码的危险不在于 Java API 本身，而在于 target 完全由外部输入控制。攻击者可能让服务端访问不应该暴露的管理接口、云环境元数据服务、内部调试端口，或者借助重定向绕过初始校验。 从防守角度
T0xfce

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

背景 文件上传是 Web 安全测试里很常见的一类入口，但真正能造成风险的点通常不是“能不能上传文件”这么简单，而是上传后的文件存储位置、访问方式、扩展名处理、内容校验、解析规则、权限控制等多个环节共同失效。 这篇整理基于一次内部测试中遇到的文件上传缺陷，重点放在漏洞分析、复现思路和修复验证。文中不提供可直接用于攻击的恶意载荷，也不讨论未授权入侵场景，适合用于代码审计、自查和安全加固。 问题场景 某业务系统提供头像、附件、工单图片等上传能力。表面看接口限制了扩展名，只允许上传图片类文件。但测试中发现，服务端对文件类型的判断主要依赖客户端传入的文件名和 Content-Type，且上传目录位于 Web 可访问路径下。 简化后的风险链路如下： 前端限制扩展名，但后端校验不足。 服务端将用户可控文件名参与拼接保存路径。 上传目录可被直接访问。 部分中间件或框架存在错误解析配置。 文件上传后缺少二次处理和隔离。 这类问题在老系统、快速迭代项目、后台管理系统里比较常见。单点问题不一定立刻形成高危，但多个弱点叠加后风险会明显放大。 技术分析 文件上传安全通常要关注三个层面：输入校验、存储隔离、访问控
T0xfce

一次内网 Web 漏洞复盘：从弱点定位到修复验证的完整思路

背景最近整理了一次内部演练中的 Web 漏洞复盘。目标系统是一个常见的企业后台，前端为 Vue，后端为 Java Spring Boot，网关层使用 Nginx，鉴权依赖 JWT 与服务端权限表。本文不讨论真实攻击目标，也不提供未授权利用流程，重点放在漏洞定位、成因分析、修复方案和验证方法上，适合作为代码审计和安全加固参考。这类问题在企业系统里比较常见：单点漏洞本身不一定高危，但多个设计缺陷叠加后，会导致越权、敏感信息泄露、接口被滥用等风险。真正有长期价值的地方，不是某个 payload，而是如何把问题定位清楚，并让修复闭环。场景概述系统的业务逻辑大致如下：普通用户登录后可查看自己的工单、资产和审批记录。部门管理员可以查看本部门数据。平台管理员拥有全局查询和配置权限。前端根据菜单接口返回结果展示不同入口。后端接口主要通过 JWT 识别用户身份，通过注解和业务代码做权限控制。复盘过程中发现的问题集中在三个方面：部分接口只校验登录态，没有校验资源归属。列表查询接口存在过度返回，响应中包含前端未展示字段。后台导出接口的权限判断与页面权限不一致。很多越权问题不是因为“没有鉴权”，而是“鉴权粒度
T0xfce

从一次代码审计看 Spring Boot 文件上传风险的定位与加固

背景 文件上传是 Web 系统里很常见的功能，但也是安全问题高发点。很多漏洞并不是因为框架本身有问题，而是业务代码在文件类型判断、文件名处理、存储路径控制、访问权限隔离等环节做得不够严谨。 这篇文章整理一次偏实战的代码审计思路，以 Spring Boot 项目中的文件上传接口为例，讨论如何定位风险点、如何复现验证、以及如何做相对稳妥的修复。内容只面向防御、审计和加固，不涉及未授权攻击或恶意利用。 常见场景 审计中经常遇到这样的上传接口：前端限制只能上传图片，后端接收 MultipartFile，然后根据原始文件名拼接路径并保存到服务器某个目录。代码大致类似： @PostMapping("/upload") public String upload(@RequestParam("file") MultipartFile file) throws IOException { String filename = file.getOriginalFilename(); File dest = new File("/data/upload/" + filename); f
T0xfce