跳转到帖子
应急响应中心

应急响应中心

保存

应急响应中心部落格

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

  • 篇帖子

    283

  • 篇意见

    0

  • 次查看

    2314

关于此博客

一次 Java Web SSRF 风险的代码审计与修复思路

背景 SSRF（Server-Side Request Forgery）在企业内部系统里并不少见，尤其是带有“URL 预览、远程图片抓取、Webhook 回调、文件导入、第三方接口代理”等能力的业务。它的问题不在于某一行代码有多复杂，而是服务端代替用户发起了网络请求，如果边界没收紧，就可能访问到本不该暴露的内部资源。 这篇文章整理一次比较典型的 Java Web 代码审计过程，重点放在识别风险点、分析常见绕过、设计可落地的修复方案。内容偏防守视角，不涉及对真实目标的攻击操作。 场景描述 业务里有一个“远程资源导入”功能，用户提交一个 URL，后端拉取资源并保存到对象存储。简化后的代码如下： @PostMapping("/import") public ResponseEntity<String> importResource(@RequestParam String url) throws Exception { RestTemplate restTemplate = new RestTemplate(); byte[] data = restTemplat
T0xfce

从一次 WebShell 告警到根因定位：Web 入侵事件的取证与代码审计方法

在实际的 Web 安全事件中，最难处理的往往不是发现某个可疑文件，而是回答三个问题：攻击者从哪里进入、哪些数据可能被读取或篡改、修复后是否还存在残留访问路径。只删除一个所谓的“木马文件”，通常无法完成处置，甚至可能破坏后续取证。 本文以一次典型的 WebShell 告警为背景，整理从告警确认、证据保全、日志关联到代码审计和修复验证的完整思路。示例以常见的 PHP 应用为主，但其中的方法同样适用于 Java、Node.js 和 Python Web 服务。 一、事件背景与初步判断 假设主机安全产品报告 Web 目录下出现可疑 PHP 文件，文件内容包含动态执行函数，且该文件在凌晨被访问过。此时不应立即删除文件或重启主机，而应先确认告警是否具备真实攻击特征。 初步判断可以围绕以下几个维度展开： 文件的创建时间、修改时间和属主是否异常，是否与发布窗口一致。 访问日志中是否存在对该文件的外部请求，以及请求来源、User-Agent 和响应状态。 文件是否被其他脚本包含，或者是否存在同目录下的关联文件。 应用进程、计划任务、启动项和 Web 服务配置是否出现异常变更。 数据库、对象存储和业务日志
T0xfce

从代码审计到事件复盘：系统化分析与治理 SSRF 风险

SSRF（服务端请求伪造）并不是“让服务器替客户端发一个 HTTP 请求”这么简单。真正难处理的地方在于：URL 解析存在差异、DNS 解析结果可能变化、重定向会改变目标，以及应用所在网络通常比普通用户拥有更高的访问权限。很多实际事件并非由单一漏洞触发，而是由“任意 URL 请求能力 + 缺少出口控制 + 内部服务认证薄弱”共同造成。 一、问题场景与风险边界 常见业务功能包括图片抓取、远程文件导入、Webhook 测试、在线网页预览、PDF 转换和第三方接口代理。这些功能本身并不等于漏洞，关键在于服务端是否允许用户完全控制请求目标，以及请求是否能够访问不应暴露的网络区域。 应用服务器访问本机回环地址、内网地址或链路本地地址。 应用所在网络可以访问管理面板、配置中心、监控接口等内部服务。 请求组件默认跟随重定向，导致初始校验通过后又跳转到受限地址。 域名校验和实际连接之间存在时间差，DNS 结果发生变化后仍继续连接。 日志只记录用户输入的 URL，没有记录最终解析地址、重定向链和出口策略。 在授权测试或内部实验环境中，应使用专门的模拟服务验证行为，不要直接探测生产内
T0xfce

从一次代码审计看 SpEL 表达式注入的识别、验证与修复

背景 Spring 生态里 SpEL（Spring Expression Language）用得很广，常见于权限表达式、配置解析、缓存 Key 生成、规则引擎、动态模板等场景。它本身不是漏洞，问题通常出在“把外部可控输入当作表达式执行”。这类问题在代码审计中不算高频，但一旦出现在关键路径，影响面会比较大。 这篇文章整理一次比较典型的审计思路：如何从代码里识别 SpEL 注入风险，如何做安全验证，如何判断真实影响，以及如何修复。重点放在防守和工程落地，不讨论恶意利用链。 问题场景 某业务系统提供了一个“自定义规则”能力，管理员可以配置规则表达式，用于决定消息是否进入后续流程。最初设计时只考虑了内部人员使用，后来配置入口被接入到运营后台，并且部分字段可以由上游接口间接写入。 审计时看到类似代码： ExpressionParser parser = new SpelExpressionParser(); StandardEvaluationContext context = new StandardEvaluationContext(); context.setVariable("user"
T0xfce

从请求链路到证据闭环：一次 SSRF 风险的代码审计与修复实践

SSRF（服务端请求伪造）在实际项目中并不总是以一个明显的“URL 参数直接传给 HTTP 客户端”形式出现。更常见的情况是：业务允许导入远程图片、解析 Webhook、抓取网页标题，或者通过内部服务生成预览；随着代码分层和功能迭代，用户输入可能经过多次拼接、解码和重定向，最终形成一条不容易被发现的服务端请求链路。 这类问题的风险也不能只看“能不能访问内网”。真正需要评估的是请求发起位置、解析和连接过程、重定向行为、响应处理方式，以及云环境中的凭证和管理接口是否暴露。本文以一次典型的代码审计为例，整理一套偏工程化的发现、复现、修复和验证方法。示例均使用本地测试环境，不涉及对第三方系统的探测。 一、问题场景：图片预览功能为何容易出问题 某内容系统提供远程图片预览功能，接口接收一个图片地址，服务端下载图片后生成缩略图。初始实现大致如下： def fetch_image(url: str) -> bytes: response = requests.get(url, timeout=5) response.raise_for_status() return re
T0xfce

从误报到闭环：一次 SSRF 风险的代码审计与防护实践

SSRF（服务端请求伪造）经常出现在“根据 URL 抓取内容”“图片远程转存”“Webhook 测试”“网页截图”等功能中。它的危险性不只在于访问内网地址，更在于应用自身拥有网络权限、身份凭据和信任关系，一旦请求边界设计不清晰，就可能把一个普通的业务接口变成内部网络访问代理。 本文以一次典型代码审计为背景，讨论如何判断 SSRF 是否成立、如何在不触碰真实敏感系统的前提下完成验证，以及如何从 URL 解析、重定向、DNS 解析和出口控制多个层面建立防护闭环。 一、问题场景：一个看似普通的远程抓取接口 目标功能是让用户提交一个图片地址，服务端下载图片并保存到对象存储。初始代码逻辑大致如下： public byte[] fetch(String url) throws IOException { URL target = new URL(url); HttpURLConnection connection = (HttpURLConnection) target.openConnection(); connection.setConnectTimeout(3000)
T0xfce

一次面向内网 Web 资产的代码审计与风险收敛实践

背景 很多内网 Web 系统上线时间早、业务依赖重，平时很少有人系统性审计。真正出问题时，常见情况不是单点漏洞特别复杂，而是几个普通风险叠加：老旧框架、调试接口遗留、上传目录可访问、权限校验分散、日志缺失。本文整理一次偏防守视角的代码审计与风险收敛方法，重点放在如何发现问题、验证风险边界、推动修复，不涉及未授权攻击或恶意利用。 场景假设是企业内部自研 Web 系统，技术栈为 Java Spring MVC / Spring Boot 混合，前端有少量老 JSP，部署在 Linux + Nginx + Tomcat 环境。目标不是“打穿系统”，而是通过代码审计和受控验证，把可被利用的缺陷收敛到可修复、可复测的清单。 问题与场景 这类系统常见的问题并不新，但因为业务迭代多年，风险点往往藏在边角位置： 接口权限校验不一致：部分 Controller 依赖前端菜单控制，没有后端鉴权。 文件上传处理粗糙：只校验后缀或 Content-Type，上传目录又能被直接访问。 SQL 拼接遗留：新模块使用 ORM，老模块仍有字符串拼接 SQL。 配置暴露：测试配置、默认口令、调试开关混入生产分支。 日志
T0xfce

一次 Java Web 文件读取漏洞的复盘：从代码审计到修复加固

背景 文件读取类漏洞在 Java Web 项目里并不稀奇，但实际排查时经常被低估。很多业务代码本意只是提供“下载日志”“导出附件”“预览模板”等功能，参数看起来也只是一个文件名，一旦路径拼接和权限校验处理不严，就可能变成任意文件读取。 这篇文章整理一次相对典型的代码审计和复盘过程。内容只讨论本地测试环境中的漏洞成因、验证方式和修复思路，不涉及真实目标攻击，也不提供越权利用指导。重点放在：如何在代码审计中识别风险点，如何构造安全的复现环境，以及如何把问题修干净。 场景描述 某个内部 Java Web 系统提供附件下载接口，接口大致功能如下： 用户传入文件名参数。 服务端从固定目录读取文件。 以流的形式返回给浏览器下载。 开发侧认为文件都存放在固定目录下，因此没有额外做权限检查。问题出在“固定目录 + 用户输入”这种组合上，如果直接字符串拼接路径，攻击者可能通过路径穿越读取目录外文件。 问题代码示例 下面是经过简化的示例代码，便于说明问题。实际项目里类似逻辑可能散落在 Controller、Service 或工具类中。 String baseDir = "/data/app/uploads
T0xfce

一次 SSRF 代码审计的完整方法：从危险 URL 入口到防护闭环

SSRF（Server-Side Request Forgery，服务端请求伪造）在实际项目中并不一定表现为一个明显的“请求外部 URL”接口。图片抓取、Webhook 调试、文件导入、URL 预览、第三方回调检测等功能，都可能让服务器代替用户发起网络请求。审计这类问题时，单纯搜索 requests.get 或 HttpClient 往往不够，更重要的是沿着“用户可控输入—URL 解析—网络连接—响应处理”的完整链路确认风险边界。 一、问题背景与典型场景 SSRF 的核心不是“服务器访问了一个 URL”，而是攻击者能够影响服务器访问的目标、协议、端口或请求内容，并借助服务器所在网络环境获得普通客户端无法获得的访问能力。 图片或网页预览：后端接收 URL，下载内容后返回给前端。 Webhook 测试：用户输入回调地址，服务端向该地址发送测试请求。 文档解析：服务端根据文档中的外部资源地址加载图片、字体或样式。 云资源集成：后端根据用户提交的地址访问对象存储、内部 API 或代理服务。 健康检查功能：管理员输入地址，系统主动探测服务是否可用。 这些功能本身未必存在问题
T0xfce

从一次可疑 WebShell 告警看服务器侧入侵排查思路

背景 最近整理了一次 Web 服务器可疑文件告警的排查过程，场景并不复杂：业务侧反馈某台 PHP 应用服务器被安全设备提示存在疑似 WebShell 文件，但没有明确说明入口点。类似事件在日常应急里很常见，难点通常不在于“删掉一个可疑文件”，而是要判断它从哪里来、是否被执行过、是否还有持久化或横向痕迹。 这篇文章按一次相对完整的排查链路来写，重点放在防守视角的取证、日志关联、代码审计和加固建议上，不涉及攻击利用细节。 问题场景 已知信息比较有限： 服务器为 Linux，运行 Nginx + PHP-FPM。 业务目录存在近期新增的可疑 PHP 文件。 安全设备提示文件具有 WebShell 特征。 业务方不确定是否存在异常登录或数据泄露。 这类场景建议先不要急着删除文件。直接删除会破坏时间戳、文件内容和权限等取证信息，也可能漏掉其他关联文件。更稳妥的做法是先隔离访问、保全证据，再做关联分析。 初始处置：先控风险，再保全 如果业务允许，优先在网关、WAF 或 Nginx 层面临时限制该站点的外部访问，避免可疑文件继续被触发。对于生产环境，通常不建议立即关机，因为关机会丢失部分内存态和进程
T0xfce

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

SSRF（Server-Side Request Forgery，服务器端请求伪造）并不是一个只靠“禁止访问内网 IP”就能彻底解决的问题。实际审计中，漏洞往往出现在图片抓取、Webhook 回调、文档转换、远程资源导入、健康检查等功能里。开发者通常只关注了参数是否为合法 URL，却忽略了 URL 解析差异、DNS 解析变化、重定向链以及非 HTTP 协议等边界情况。 本文以代码审计和修复验证为主线，整理一套适用于 Web 应用的 SSRF 分析方法。示例均以本地测试服务或受控地址为前提，不涉及访问真实内网资产、云平台元数据或第三方系统。 一、典型业务场景与风险边界 常见的 SSRF 入口包括以下几类： 根据用户提交的 URL 下载头像、附件或远程图片。 服务端生成 PDF、截图或预览页面时访问指定地址。 Webhook、回调地址、消息推送等功能由用户配置目标 URL。 导入 RSS、OpenAPI 文档或远程配置文件。 后台健康检查功能允许管理员输入待检测地址。 这类功能本身并不一定存在漏洞，关键在于服务端是否会按照用户可控的地址发起网络请求，以及请求是否能够到达不应暴露的网络区域。
T0xfce

一次较完整的 SSRF 漏洞分析与加固思路整理

背景 SSRF（Server-Side Request Forgery）这类问题在代码审计和漏洞复现里很常见，但真正处理起来并不只是“禁用内网地址”这么简单。很多业务会天然需要服务端发起请求，例如：远程图片抓取、Webhook 回调、在线文档预览、URL 健康检查、第三方接口转发等。如果只做简单黑名单，通常很容易被各种地址表示法、跳转链、DNS 解析变化绕过去。 这篇文章整理一个偏工程化的 SSRF 分析方法，重点放在安全验证、漏洞定位和加固落地。内容不会展开攻击性利用，只讨论如何识别风险、复现边界和修复设计。 典型场景 下面这些接口在审计中需要重点关注： 根据用户提交的 URL 抓取图片、头像、封面、文件。 Webhook、Callback、OpenAPI 回调地址配置。 在线代理、站点截图、URL 预览、网页转 PDF。 后端请求第三方资源，并将响应内容返回给前端。 文件导入功能支持 HTTP/HTTPS 远程地址。 一个常见的风险接口可能长这样： POST /api/fetch-image HTTP/1.1 Content-Type: application/json {
T0xfce

从请求边界到证据闭环：SSRF 漏洞的代码审计、验证与修复实践

SSRF（Server-Side Request Forgery，服务端请求伪造）并不是“服务端发起了一次 HTTP 请求”这么简单。真正需要关注的是：用户可控数据是否进入了服务端的网络请求链路，服务端是否能够访问不应暴露的网络区域，以及应用、代理和云环境之间是否存在边界失效。 这类问题在代码审计中比较常见，尤其容易出现在图片抓取、Webhook 调试、文档转换、远程资源导入、URL 预览和第三方接口探测等功能中。本文以防守视角整理一套可复用的方法，重点放在审计思路、低风险验证、修复设计和复测证据上。 一、问题场景与风险边界 典型业务流程是：用户提交一个 URL，服务端下载内容后进行解析、转码或展示。风险通常来自以下几类位置： 直接调用 HTTP 客户端，例如 requests、urllib、OkHttp、axios 或内部封装的 fetch 方法。 用户输入先经过重定向、短链接或 URL 解析，再由后台任务异步访问。 文件解析器、Markdown 渲染器、网页截图服务间接触发外部请求。 代理服务允许访问内部域名、管理接口或容器网络。 应用层做了域名校验，但 DNS 解析、重定向和底层
T0xfce

从一次登录接口异常看 Web 风险排查与加固思路

背景 最近在做一个内部业务系统的安全复盘时，遇到一个比较典型的场景：登录接口没有出现明显漏洞利用痕迹，但日志里能看到大量异常请求，包括高频失败登录、参数结构异常、不同 User-Agent 的批量访问，以及少量疑似探测请求。 这类问题在实际环境中很常见。它不一定意味着系统已经被入侵，但通常说明接口暴露面、认证策略、日志可观测性和风控策略存在短板。本文不讨论任何攻击利用方法，重点放在如何从防守视角复盘、分析和加固。 问题场景 业务系统采用常见的前后端分离架构，登录接口大致如下： POST /api/auth/login HTTP/1.1 Content-Type: application/json { "username": "test", "password": "******", "captcha": "1234" }排查时发现几个现象： 短时间内出现大量登录失败，来源 IP 分散。 部分请求缺失 captcha 字段，或字段类型不符合预期。 接口返回信息区分了“用户不存在”和“密码错误”。 同一账号在不同 IP 下连续失败，但应用层没有统一限速。 日志记录了请求结果，
T0xfce

从一次 SSRF 代码审计出发：识别请求边界、验证风险与建立纵深防护

SSRF（Server-Side Request Forgery，服务端请求伪造）并不只是“让服务器代替用户发起一次请求”。在真实系统中，它往往与网络分区、云环境元数据服务、内部管理接口以及权限模型相互叠加，最终形成从外部输入到内部资源的访问链路。对这类问题进行审计时，单纯搜索 requests.get() 或 HttpClient 并不够，更重要的是理解数据流、请求边界和部署环境。 一、问题背景与常见场景 SSRF 通常出现在以下功能中： 根据用户提交的 URL 抓取远程图片、网页或 RSS。 Webhook、回调地址、第三方通知地址配置。 在线预览、文档转换、PDF 生成和远程资源解析。 服务端健康检查、连通性测试和网络探测功能。 代理下载、跳转跟随和文件导入功能。 这些功能本身并不一定有问题。风险主要取决于三个因素：用户是否能够影响目标地址，服务端是否会访问不应暴露的网络区域，以及返回内容是否会被直接回显或进一步处理。 二、先画出请求链路，再判断风险 一个典型的远程资源获取流程可以抽象为： 用户输入 URL ↓ 参数校验与规范化 ↓ DNS 解析 ↓ 建立
T0xfce

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

背景 文件上传是 Web 系统里很常见的功能：头像、附件、工单截图、合同文档、插件包导入等都会涉及。也正因为它离用户输入很近，一旦校验和存储策略处理不好，风险往往不是单点问题，而是会串到解析、访问控制、存储桶权限、静态资源服务和后端任务处理链路。 这篇文章整理的是我在日常代码审计和漏洞复现中比较常用的一套检查方法，重点放在“如何识别风险”和“如何把风险收敛掉”。不讨论非法利用，也不提供面向攻击的操作路径，更多是给开发、安全同学做自查时参考。 典型场景 某业务系统提供附件上传能力，后端使用 Spring Boot，文件最终落到本地磁盘或对象存储，数据库中保存文件名、访问路径、上传人、业务类型等信息。常见代码大概长这样： @PostMapping("/upload") public Result upload(@RequestParam("file") MultipartFile file) throws IOException { String originalName = file.getOriginalFilename(); String path = uploadD
T0xfce

从一次后台未授权访问看接口鉴权与代码审计要点

背景 最近在做内部系统安全复盘时，遇到一个比较典型的问题：某业务后台已经接入统一登录，但部分管理接口仍然可以在未登录状态下被访问。问题本身不复杂，却很有代表性，涉及路由鉴权、前后端权限边界、接口设计习惯以及代码审计方法。 这类问题在中小型后台、快速迭代的运营系统、历史项目迁移中比较常见。前端页面可能已经做了登录拦截，菜单也按角色隐藏，但后端接口如果没有统一鉴权，实际风险仍然存在。 问题场景 系统大致结构如下： 前端：Vue 单页应用，通过路由守卫判断是否存在 token。 后端：Spring Boot 提供 REST API。 登录：统一认证服务签发 JWT。 权限：部分接口使用注解校验，部分接口依赖网关或前端控制。 问题接口位于后台管理模块，例如用户列表、配置查询、导出任务状态等接口。页面层面无法直接进入，但接口在缺少登录态时仍返回数据。 典型表现包括： 访问管理页面会跳转登录页，但直接访问接口仍返回 200。 同一 Controller 中部分方法有权限注解，部分方法没有。 新增接口未纳入统一拦截器白名单/黑名单策略。 测试环境配置被复制到生产环境，导致部分路径被放行。 技术分析
T0xfce

从代码审计角度复盘一次文件上传风险排查

背景 文件上传是 Web 系统里非常常见的功能，头像、附件、工单截图、导入模板都会涉及。它看起来只是业务能力，但在安全审计里经常是高风险入口：一旦校验逻辑不完整，可能引发任意文件写入、存储型 XSS、服务端解析异常、敏感文件覆盖等问题。 这篇文章整理一次比较典型的文件上传风险排查思路，重点放在代码审计和防护设计上。内容不会涉及未授权入侵或攻击利用细节，更多是从研发和安全评审角度，说明如何判断一个上传功能是否可靠。 常见场景 在实际项目里，文件上传通常存在几类实现方式： 后端应用直接接收文件并保存到本地目录。 后端接收后转存到对象存储，例如 S3、OSS、COS、MinIO。 前端直传对象存储，后端只负责签发上传凭证。 上传后进入异步处理流程，例如图片压缩、文档解析、病毒扫描。 不同实现方式风险点不完全一样，但核心问题基本围绕三个方面：文件内容是否可信、文件路径是否可控、文件访问是否安全。 问题分析 审计上传功能时，不建议只看扩展名判断。扩展名是用户可控输入，只能作为辅助信息。更稳妥的方式是从以下几个维度交叉验证。 一、文件类型校验不能只依赖后缀 很多历史代码会这样判断： String
T0xfce

SSRF 代码审计与防护：从 URL 解析到出口控制的完整排查方法

服务端请求伪造（SSRF）并不是简单的“用户可控 URL”问题。真正决定风险的，通常是 URL 解析方式、DNS 解析行为、重定向处理、网络出口策略以及响应内容是否会返回给用户。很多修复只增加了一个内网 IP 判断，实际仍可能被 IPv6、十进制 IP、DNS 重绑定或重定向绕过。本文以代码审计和防守验证为主线，整理一套适用于 Java Web 服务的 SSRF 排查方法。示例均应在本地靶场或经授权的测试环境中进行，不直接访问生产内网、云平台元数据服务或其他未授权目标。一、常见业务场景与风险边界SSRF 通常出现在以下功能中：远程图片、头像、附件抓取；Webhook、回调地址或第三方通知配置；URL 预览、网页截图、Markdown 远程资源解析；导入远程 XML、JSON、RSS 或 OpenAPI 文档；代理下载、在线转码和远程健康检查。审计时不要只搜索 HttpClient 或 RestTemplate。更重要的是追踪数据流：用户输入是否进入 URL 构造函数，是否进入 DNS 解析、TCP 连接或 HTTP 客户端，响应是否被读取并返回给攻击者。判断 SSRF 的关键不是“是否
T0xfce

从代码审计到纵深防御：一次 SSRF 风险分析与修复实践

服务端请求伪造（SSRF）并不只是一个“能否访问内网”的简单问题。实际审计中，风险通常分散在 URL 解析、DNS 解析、重定向、代理配置和网络出口策略等多个环节。单纯增加一个正则表达式，往往只能拦住最直观的测试用例，却无法覆盖 IPv6、DNS 重绑定、编码差异以及跳转链等场景。 本文以一个常见的“远程图片抓取”功能为例，整理从代码定位、风险确认、修复设计到上线验证的完整思路。示例仅用于本地测试环境和防御性审计，不涉及访问真实内网服务或敏感信息。 一、问题背景与典型场景 很多业务会提供类似功能：用户提交一个图片或文档 URL，后端下载资源后进行转码、缓存或内容审核。伪代码通常如下： def fetch_resource(url): response = http_client.get(url, timeout=10) return response.content如果这个 URL 完全由用户控制，服务端就可能成为一个网络请求代理。风险主要包括： 访问本不应由公网用户触达的管理接口、监控接口或内部服务。 将内网服务的响应内容带回前端，造成信息泄露。 借助重定向、代理或特
T0xfce

从代码审计到修复验证：一套可落地的 SSRF 风险分析方法

服务端请求伪造（SSRF）是代码审计中经常遇到的一类问题。它通常不是由某个危险函数单独造成，而是由“用户可控地址”“服务端发起请求”“缺少目标限制”三个条件共同形成。实际项目里，SSRF 可能出现在图片抓取、Webhook、远程文件导入、URL 预览、文档转换和代理接口等功能中。 这类问题的难点在于：简单的黑名单很容易被绕过，单纯判断字符串是否包含内网地址也不可靠，而修复时还要兼顾 DNS 解析、重定向、IPv6、代理配置和网络分区。本文以代码审计和防守验证为主线，整理一套适合实际项目的分析方法。 一、先明确风险边界 审计 SSRF 时，不要一开始就把所有“服务器发起的 HTTP 请求”都判定为漏洞。更准确的判断方式是分析请求目标是否受到攻击者控制，以及服务端能访问到什么网络区域。 高风险场景：接口允许用户提交任意 URL，服务端再将响应内容返回给用户，或将内容解析、保存、转发到其他系统。 中风险场景：目标地址可控，但服务端有固定域名白名单；需要进一步确认白名单校验是否可靠。 低风险场景：请求目标完全由服务端配置决定，用户只能选择有限的业务对象，且网络层也有访问控制。 需要重点确认的影
T0xfce

一次 SSRF 漏洞的完整分析：从数据流定位到修复验证

SSRF（Server-Side Request Forgery，服务端请求伪造）在代码审计中并不少见。它通常不是一个单独的“危险函数”问题，而是外部输入经过 URL 解析、网络请求、重定向和响应处理等多个环节后，形成了服务端可控的请求能力。真正有效的分析，不能只盯着某个 HTTP 客户端调用，而应当沿着数据流判断：谁能控制请求地址、请求会发往哪里、是否允许重定向、响应是否会回显，以及修复是否覆盖了所有变体。一、问题场景与风险边界常见业务包括图片抓取、Webhook 回调、远程文件导入、站点连通性检测和第三方接口代理。例如，应用提供如下接口：POST /api/import { \"source\": \" /> }服务端为了读取远程内容，可能直接使用用户提交的地址发起请求。如果缺少目标限制，攻击者就可能诱导服务端访问本不应由外部访问的网络资源，例如内部管理接口、云环境元数据地址或仅绑定在回环地址上的调试服务。这里需要区分两个问题：服务端是否能向攻击者无法直接访问的网络位置发起请求；请求结果是否会返回给攻击者，或者是否会改变服务端状态。即使响应内容不直接回显，盲 SSRF
T0xfce

从输入边界到权限边界：Web 文件上传漏洞的审计、复现与修复验证

文件上传功能看似只是把一个文件保存到服务器，但它同时涉及文件名处理、内容校验、存储位置、访问控制、解析器行为和部署配置等多个边界。实际审计中，很多问题并不来自某一行明显的危险代码，而是来自“校验了一部分、信任了另一部分”的组合。本文以防守和修复验证为主线，整理一次文件上传功能的审计方法。示例使用抽象代码和本地测试思路，不涉及对真实系统的攻击操作。一、问题场景与风险边界典型上传接口通常包含以下流程：接收 multipart/form-data 请求。读取原始文件名、扩展名和 MIME 类型。检查大小、后缀或文件头。生成保存路径并写入磁盘或对象存储。返回文件 URL，供用户后续访问。风险主要集中在四个方面：文件内容被当作脚本、模板或配置解析，形成远程代码执行风险。上传文件覆盖已有文件，导致配置、缓存或业务数据被破坏。通过路径拼接影响保存位置，形成路径穿越或任意文件写入。上传后的文件缺少访问控制，导致敏感文档越权读取。审计时不要只问“扩展名是否限制”，还要问“文件最终被谁解析、保存在哪里、谁可以访问、生命周期如何管理”。二、审计的第一步：画出数据流建议先从控制器或路由入口开始，沿着数据流跟踪
T0xfce

一次 Java 反序列化风险排查：从依赖识别到代码审计落地

背景 Java 反序列化问题在很多老系统里并不罕见，尤其是历史项目中混用了多种 JSON、RPC、缓存和消息队列组件时，风险点经常不是单一漏洞，而是“危险依赖 + 不受控输入 + 宽松配置 + 缺少边界校验”的组合。 这篇文章整理一次偏防守视角的排查思路，重点放在如何识别项目中的反序列化风险、如何做代码审计、如何验证风险是否存在，以及如何给出可落地的修复建议。文中不会提供攻击载荷或外部目标利用步骤，适合作为内部安全评审、上线前检查和历史系统治理的参考。 问题场景 某 Java Web 系统经历过多次迭代，早期模块使用了多种序列化方式，包括 Java 原生序列化、JSON 反序列化、Redis 缓存对象序列化、消息队列消费端对象转换等。安全排查时发现几个典型特征： pom.xml 中存在较老版本的 JSON 处理库和通用工具库。 部分接口接收字符串后直接反序列化为对象。 缓存层使用 JDK 默认序列化器存储复杂对象。 消息消费端缺少消息来源校验和字段白名单校验。 历史代码中存在 Object、Map、泛型擦除等宽泛类型接收方式。 这类系统不一定马上存在可利用漏洞，但已经具备较高的审计优先
T0xfce

SSRF 代码审计中的边界判断：从 URL 解析到出站访问控制

SSRF（服务器端请求伪造）在代码审计中并不难被识别，难点通常在于判断它是否真的能够触达高风险网络资源。很多审计结果停留在“用户可控 URL 传入 HTTP 客户端”这一层，没有继续分析 URL 解析、DNS 解析、重定向、代理配置和出站网络策略，最终容易出现误报或低估风险。 本文以常见的“服务端抓取 URL”功能为例，整理一套适合代码审计和安全验证的分析方法。示例均限定在本地测试环境，不涉及对真实内网、云平台元数据服务或第三方系统的访问。 一、问题场景与审计入口 常见业务包括图片代理、网页预览、Webhook 调试、PDF 转换、RSS 抓取和远程文件导入。代码形式可能不同，但通常具备以下数据流： HTTP 参数、JSON 字段或消息队列内容进入 URL 变量。 URL 经过字符串拼接、模板替换或简单过滤。 程序调用 HTTP 客户端发起服务端请求。 响应内容被返回给用户、写入文件，或继续交给解析器处理。 审计时建议先从出站请求 API 反向追踪输入来源，而不是只搜索“ssrf”关键字。Java 中常见的入口包括 HttpURLConnection、Apache HttpClient
T0xfce