跳转到帖子
应急响应中心

应急响应中心

保存

应急响应中心部落格

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

  • 篇帖子

    283

  • 篇意见

    0

  • 次查看

    2338

关于此博客

从代码审计到工程防护：系统梳理 SSRF 风险与安全验证方法

SSRF（Server-Side Request Forgery，服务器端请求伪造）并不是单一的参数校验问题，而是应用在处理外部 URL、回调地址、文件导入、图片抓取和 Webhook 时，缺少网络边界控制所形成的一类风险。它的危险性通常不在于请求本身，而在于请求由服务器发起后，继承了服务器所在网络的访问能力。在实际审计中，SSRF 往往和其他问题叠加出现：应用服务器可以访问内部管理接口，云环境提供实例元数据服务，代理层会自动跟随重定向，或者 DNS 解析结果在校验与连接之间发生变化。因此，单纯增加一个 startsWith(' 或屏蔽几个字符串，通常不能形成可靠防护。一、常见业务场景与审计入口首先应当从数据流而不是关键词出发。凡是用户能够影响目标地址，并且服务端会发起网络请求的功能，都值得重点检查。图片、头像、远程附件或 Markdown 图片的服务端下载。Webhook、回调地址、第三方通知和接口连通性检测。PDF、网页快照、网页转图片等服务端渲染功能。通过 URL 导入配置、RSS、视频封面或远程字典。跳转服务、代理接口、在线抓取和 URL 预览。微服务之间根据请求参数动态选择下
T0xfce

从 URL 参数到内网请求：SSRF 漏洞的审计、复现与修复实践

服务端请求伪造（SSRF）并不是“让服务器代替用户访问一个 URL”这么简单。真正危险的地方在于：应用服务器通常处于比普通用户更可信的网络位置，能够访问本地管理接口、云平台元数据服务、内网 API 或仅绑定在回环地址上的调试端口。一旦 URL 参数、Webhook、图片抓取、文档转换等功能缺少边界控制，原本的业务能力就可能变成跨网络边界的请求代理。 本文从代码审计和防守视角，整理一套适用于 Java、Python 等常见后端的 SSRF 分析方法。示例均以本地测试环境和无敏感数据的服务为前提，重点放在漏洞判断、根因定位和修复验证。 一、哪些功能容易引入 SSRF 审计时不要只搜索名为 url、uri、link 的参数，更应关注“服务端根据外部输入发起网络请求”的行为。常见入口包括： 远程图片下载、头像抓取、网页预览。 Webhook、回调地址、第三方通知地址。 文件导入、在线 XML 或 Office 文档解析。 URL 转 PDF、截图、网页内容转 Markdown。 代理接口、健康检查、连通性测试功能。 根据用户输入访问 Git、对象存储或内部配置中心。 代码层面可以优先检索 HT
T0xfce

文件上传漏洞审计：从入口校验到存储隔离的完整验证方法

文件上传是 Web 系统中较常见、也容易被低估的一类风险。很多项目只在前端限制扩展名，或仅依赖请求头中的 Content-Type，结果导致恶意脚本被当作静态资源执行、路径穿越覆盖文件、压缩包消耗过多资源等问题。 这类问题的审计重点并不是“能不能上传一个文件”，而是要完整梳理文件从接收、解析、存储到访问的生命周期。只有把入口校验、文件内容识别、权限控制、存储位置和后处理流程放在一起分析，才能判断实际影响。 一、先明确上传功能的安全边界 审计开始前，建议先回答几个问题： 允许上传哪些业务类型，例如头像、附件、报表或压缩包？ 文件是否会被直接通过 URL 访问？访问时由 Nginx、对象存储还是应用程序处理？ 上传后的文件是否会进入图片解析、Office 预览、OCR、解压或杀毒流程？ 上传目录是否与应用代码目录、配置目录处于同一文件系统？ 普通用户能否修改文件名、目录、Content-Type 或其他元数据？ 如果这些问题没有明确答案，通常说明系统的文件处理边界还不清晰。安全设计的第一原则是：用户上传的内容应被视为不可信数据，而不是“图片”“文档”这类可信对象。 二、常见风险点及审计思路
T0xfce

从一次代码审计看内网 SSRF 风险的识别与收敛

背景 SSRF（Server-Side Request Forgery）在实际项目里并不算新问题，但它经常藏在一些看起来“业务合理”的功能里，例如图片抓取、URL 预览、Webhook 校验、文件转存、在线导入配置等。很多团队在修复时只做了简单的黑名单判断，比如禁止 127.0.0.1，结果遇到 DNS 解析、IPv6、重定向、云厂商元数据地址等场景仍然会失效。 这篇文章整理一次偏防守视角的 Java/Spring 项目代码审计思路，重点不是讲攻击利用，而是说明如何在代码层面识别 SSRF 风险、如何验证风险边界，以及如何做相对稳妥的收敛。 典型场景 审计中遇到的功能大致如下：用户提交一个图片 URL，服务端下载图片并上传到对象存储，前端只保存最终的存储地址。这类功能很常见，问题通常出在服务端直接信任了用户传入的 URL。 POST /api/image/fetch Content-Type: application/json { "url": " }对应代码可能类似下面这样： public String fetchImage(String url) throws IOExcep
T0xfce

一次内网 Web 漏洞排查的复盘：从异常请求到代码修复

背景 最近协助排查了一起内网业务系统的异常访问事件。系统本身不是互联网暴露资产，但通过办公网、VPN 和若干跳板环境被多人使用。事件最初表现为应用日志中出现大量异常参数、404 探测请求以及少量接口报错。虽然没有确认发生数据泄露，但从日志形态看，已经不再是普通误操作。 这类事件在企业内网里比较常见：系统上线多年，缺少持续安全测试；业务接口依赖历史框架；权限模型逐步叠加，代码里留下不少临时逻辑。排查时如果只盯单个告警，很容易漏掉真正的问题链路。本文整理一套相对通用的分析思路，重点放在日志研判、漏洞定位、代码审计和修复验证，不涉及未授权攻击操作。 问题场景 业务系统为 Java Web 应用，前端通过传统表单和少量 AJAX 接口提交数据，后端使用 Spring MVC + MyBatis。排查入口来自网关日志中的异常请求，特征大致如下： 同一来源 IP 在短时间内访问多个不存在路径，如备份文件、管理入口、测试接口。 部分参数中出现特殊字符组合，例如引号、括号、路径跳转符号。 少量接口返回 500，且集中在查询类接口。 请求 User-Agent 比较混乱，既有正常浏览器，也有脚本化特征。
T0xfce

一次面向 Java Web 的文件上传漏洞复盘与加固实践

背景 文件上传是 Java Web 项目里很常见的功能，头像、附件、工单截图、导入文件都会用到。它看起来只是业务能力，但在实际代码审计和应急排查中，上传点经常是高风险入口：一旦校验不严，可能引入 WebShell、恶意脚本、存储型 XSS、任意文件覆盖，甚至配合解析缺陷形成远程代码执行。 这篇文章整理一次典型的上传漏洞复盘思路，重点放在防守侧：如何识别风险代码、如何复现安全问题、如何设计加固方案。文中示例均为本地靶场或脱敏代码，不涉及真实目标攻击。 问题场景 某 Java Web 系统提供附件上传功能，后端使用 Spring MVC 接收 MultipartFile，上传后把文件保存到 Web 根目录下的 upload 目录，并将访问路径返回给前端。 @PostMapping("/upload") public String upload(@RequestParam("file") MultipartFile file) throws IOException { String fileName = file.getOriginalFilename(); File des
T0xfce

文件上传漏洞审计：从入口校验到对象存储落地的防护清单

文件上传是 Web 系统里很常见的能力，但也是代码审计和应急排查中反复出问题的模块。很多事故并不是因为某个单点校验缺失，而是上传入口、文件解析、存储位置、访问控制、异步处理几个环节叠加后，形成了可利用面。 这篇文章整理一套偏实战的审计思路，适合做代码审计、自查加固和上线前安全评审。内容只讨论防护和验证方法，不涉及未授权攻击操作。 一、背景：为什么上传模块容易出问题 一个完整的上传流程通常包含这些步骤： 前端选择文件并提交 multipart/form-data 请求。 后端接收文件流，读取文件名、后缀、Content-Type、大小等信息。 后端进行格式校验、重命名、落盘或上传到对象存储。 系统生成访问 URL，供用户预览、下载或进一步业务处理。 后台任务可能对文件做解压、转码、缩略图、OCR、病毒扫描等处理。 风险也基本围绕这些环节产生：校验不严格、文件可执行、路径拼接不安全、对象存储权限过大、解析库存在历史漏洞、压缩包处理不当、下载接口越权等。 二、常见问题场景 审计中比较高频的问题包括： 只依赖前端限制文件类型，后端没有强制校验。 只检查文件后缀，不检查真实文件头和解析结果。 使
T0xfce

从误报到可验证修复：SSRF 漏洞分析与防护实践

SSRF（Server-Side Request Forgery，服务端请求伪造）在代码审计中很常见。它往往不是一个单独的“危险函数”问题，而是由 URL 解析、DNS 解析、重定向、代理配置和访问控制共同决定的。实际排查时，最容易出现两种情况：一是把所有服务端请求都当成漏洞，产生大量误报；二是只拦截几个常见内网地址，修复后仍然可以通过 IPv6、DNS 解析差异或重定向绕过。 本文以一个常见的“远程资源预览”功能为例，讨论如何在授权测试环境中确认 SSRF 风险、定位触发条件，并设计更可靠的修复方案。示例只使用本机或隔离实验网络，不涉及访问第三方系统、云平台元数据或未授权资源。 一、问题场景与风险边界 假设应用提供如下接口：用户提交一个 URL，服务端抓取内容后生成预览。伪代码如下： public String preview(String url) { return httpClient.get(url).getBody(); } 如果这个 URL 完全由用户控制，服务端通常具备比普通浏览器更高的网络可达性。攻击者可能借此让应用访问： 应用所在主机的本地管理接口
T0xfce

一次面向内网 Web 应用的代码审计与漏洞验证思路整理

背景 最近在做一批内网 Web 应用的安全复核，类型比较典型：Java/Spring MVC 为主，少量 PHP 管理后台，部署环境封闭但业务权限复杂。这里整理一套比较通用的代码审计与漏洞验证流程，重点放在“如何定位问题、如何验证风险、如何给出修复建议”，不展开任何未授权攻击或破坏性操作。 这类系统的共性是：上线时间长、历史接口多、权限逻辑散落在不同层、文件上传和报表导出功能较多。真正有价值的审计，不只是扫出几个高危告警，而是把入口、数据流、权限边界和修复成本都梳理清楚。 典型场景 本次讨论的目标可以抽象为一个内部管理系统： 后端：Spring MVC / Spring Boot，部分老模块使用 JSP。 数据库：MySQL，存在历史拼接 SQL。 认证：统一登录，业务系统自行维护角色权限。 常见功能：用户管理、文件上传、报表导出、审批流、富文本公告。 部署：Nginx 反向代理，应用运行在 Tomcat 或内置容器中。 这类系统最容易出问题的地方通常不是单个框架漏洞，而是业务代码里的边界缺失。例如：接口只在前端隐藏按钮，后端未校验权限；下载接口只校验文件名，不校验归属；导出功能把用户
T0xfce

一次 URL 预览服务 SSRF 风险的分析、验证与修复

URL 预览、远程图片抓取、Webhook 测试和文档转码等功能，都需要由服务端访问用户提交的地址。这类功能实现起来并不复杂，但如果缺少严格的目标校验，就可能演变为服务端请求伪造（SSRF）风险。 SSRF 的危险不只在于访问内网地址。实际事件中，更常见的问题是：校验逻辑只检查字符串、忽略重定向、DNS 解析结果可变、IPv6 处理不完整，以及出站网络权限过大。本文以一次典型的 URL 预览服务为例，整理从代码审计、受控验证到修复落地的完整思路。 一、问题背景与典型场景 某应用提供 URL 预览接口，用户提交一个页面地址，后端抓取标题、描述和首张图片，再返回给前端展示。简化后的代码如下： public PreviewResult preview(String input) throws IOException { URL url = new URL(input); HttpURLConnection conn = (HttpURLConnection) url.openConnection(); conn.setConnectTimeout(3000);
T0xfce

从一次弱口令告警看 Web 登录面的防护与审计思路

背景很多入侵事件并不是从复杂漏洞开始的，而是从一个暴露在公网的登录入口开始：后台、运维平台、测试系统、Grafana、Jenkins、GitLab、VPN、堡垒机等。弱口令、默认口令、口令复用、验证码设计不当、日志缺失，都会让登录面成为长期风险点。这篇文章整理一次偏防守视角的登录面审计思路，重点放在如何识别风险、验证问题和加固系统。文中不会提供批量爆破、撞库或绕过控制的攻击流程，只讨论在授权范围内的排查与改进。问题场景某业务收到安全设备告警，提示后台登录接口出现异常失败请求。初看请求量不算大，但来源 IP 分散，User-Agent 混杂，且失败用户名集中在 admin、test、operator、root、system 等常见账号。这类告警容易被误判为普通扫描，但如果系统存在以下问题，风险会明显升高：后台入口直接暴露公网，没有访问控制。存在默认账号或历史测试账号。登录失败没有限速、锁定或二次验证。验证码只在前端校验，或可被重复使用。日志只记录成功登录，不记录失败原因和来源信息。不同系统之间存在口令复用。技术分析登录面风险不只是“密码弱”这么简单，通常涉及账号体系、认证逻辑、审计日志、
T0xfce

一次 Java 表达式注入风险的代码审计复盘：从入口定位到修复验证

背景 最近在做一轮内部系统代码审计时，遇到了一类容易被低估的问题：把用户可控内容拼进表达式引擎里执行。这个问题在业务系统里并不少见，常见场景包括规则引擎、动态模板、报表筛选、工作流条件判断等。单看代码往往像是“配置灵活性”的实现，但如果边界没收紧，就会把本来只该做布尔判断或字段映射的能力，扩展成任意方法访问、对象遍历甚至更危险的行为。 本文不讨论攻击利用细节，重点放在代码审计时如何识别风险、如何缩小影响面、以及如何做可验证的修复。内容基于一次真实审计过程整理，具体类名和业务字段已做脱敏处理。 问题场景 业务中有一个“动态规则”模块，运营可以在后台配置规则，例如根据订单金额、用户等级、地区等字段判断是否命中某个策略。后端为了实现灵活判断，引入了表达式解析能力。 简化后的代码结构类似下面这样： public boolean matchRule(Map<String, Object> context, String ruleExpression) { ExpressionParser parser = new SpelExpressionParser(); Sta
T0xfce

从一次代码审计看 Java Web 任意文件读取漏洞的定位与修复

背景 任意文件读取是 Java Web 项目里比较常见、但经常被低估的一类漏洞。它不像命令执行那样直观，也不一定能直接拿到权限，但在真实环境中，如果能读取配置文件、日志、密钥、源码或运行时信息，后续风险会被迅速放大。 这篇文章整理一次代码审计中的典型定位过程，重点放在漏洞成因、审计思路、复现边界和修复方式。内容只讨论授权测试和自查场景，不涉及未授权目标的攻击利用。 问题场景 某 Java Web 系统提供了文件预览和下载功能，接口大致用于读取服务器上的附件文件。业务侧最初的设计是：前端传入文件路径或文件名，后端读取对应文件并返回给浏览器。 常见接口形态类似下面几种： GET /file/download?path=/upload/2024/report.pdf GET /preview?fileName=report.pdf POST /api/file/read {"file":"/upload/demo.txt"}如果后端直接信任用户输入，并把参数拼接到本地文件路径中，就容易出现目录穿越和任意文件读取问题。 漏洞成因分析 审计时看到的风险代码通常有几个明显特征： 用户可控参数参与文
T0xfce

一次面向真实项目的 Java 代码审计思路整理：从入口到数据流

背景 代码审计最容易走偏的地方，是一上来就全局搜索危险函数，然后在大量误报里消耗时间。真实项目里，漏洞通常不是单点 API 使用错误，而是“入口、权限、数据流、业务约束、框架特性”共同作用的结果。 这篇文章整理一套我在审计 Java Web 项目时常用的流程，偏实战复盘，不针对某个具体漏洞利用场景，也不提供攻击性操作。重点放在如何更高效地识别风险点、确认影响范围，并给出可落地的修复建议。 适用场景 本文更适合以下几类场景： 接手一个 Spring Boot / Spring MVC 项目，需要做上线前安全评审。 对历史系统做安全巡检，希望快速定位高风险接口。 漏洞响应阶段，需要判断某个输入点是否能影响敏感操作。 团队希望建立一套可重复执行的代码审计 checklist。 不适合单纯依赖自动化扫描的场景。工具可以帮助发现一部分问题，但业务鉴权缺失、越权、状态机绕过这类问题，仍然需要结合代码和业务流程判断。 审计前的准备 开始前建议先把项目跑起来，至少要能完成编译和单元测试。无法运行的项目也能审，但效率和准确性会明显下降。我的习惯是先做三件事： 确认技术栈：Spring MVC、MyBat
T0xfce

从代码审计到安全验证：系统化分析 Web 应用中的 SSRF 风险

SSRF（Server-Side Request Forgery，服务端请求伪造）并不是“发现一个可控 URL”这么简单。真正影响风险等级的，通常还包括请求发起位置、网络出口权限、DNS 解析行为、重定向处理、协议支持范围以及云环境中的基础设施配置。 本文以代码审计和本地验证为主线，整理一套适合实际项目的 SSRF 分析方法。示例均针对自建测试服务和本地网络，不涉及访问第三方系统、云平台敏感接口或绕过授权。 一、问题场景与审计目标 常见业务功能包括图片抓取、Webhook 回调、远程文件导入、PDF 转换、站点连通性检测和 URL 预览。这些功能往往需要服务端根据用户输入发起 HTTP 请求，因此形成了 SSRF 的潜在入口。 审计时不要只关注参数名是否叫 url。更重要的是确认以下数据流： 用户输入是否进入了 HTTP、HTTPS、FTP 或其他网络客户端。 请求是否经过了统一的 URL 校验组件，还是在业务代码中直接拼接。 是否允许自动跟随重定向，以及重定向后的地址是否重新校验。 DNS 解析发生在校验之前还是连接之前，解析结果是否可能变化。 应用运行账户能够访问哪些内网网段和本机
T0xfce

从日志到根因：一次 Web SSRF 风险的审计、复现与加固

SSRF（Server-Side Request Forgery，服务端请求伪造）并不是“让服务器访问一个 URL”这么简单。真正难处理的地方在于：业务通常允许服务器主动访问外部资源，而攻击者又可能影响目标地址、请求协议、重定向链或解析结果。两者边界一旦没有定义清楚，就容易形成从内网探测、云元数据访问到敏感信息泄露的风险。本文以一次常见的“远程图片抓取”功能为例，整理如何从代码、日志和网络行为定位 SSRF 根因，并给出适合工程落地的修复方案。示例均以本地实验环境和防御验证为前提，不涉及对第三方系统的探测。一、问题场景：业务需求本身并不等于漏洞假设系统提供以下接口：用户提交图片地址，服务端下载图片后保存到对象存储或本地缓存。POST /api/image/import { \"url\": \" /> }后端最初的实现可能类似这样：import requests def import_image(url): response = requests.get(url, timeout=10) response.raise_for_status()
T0xfce

从代码审计到防护落地：一次 SSRF 风险的系统化分析方法

SSRF（服务端请求伪造）并不是“让服务器代替用户发一个 HTTP 请求”这么简单。真正需要关注的是：哪些输入能够影响出站请求、服务器能够访问哪些网络区域、请求是否会跟随重定向、解析结果是否可被重新绑定，以及响应内容是否会进一步进入业务流程。 在实际审计中，SSRF 往往隐藏在图片抓取、Webhook、文档转换、URL 预览、远程文件导入和健康检查等正常功能里。单纯搜索 http.get 或 requests.get 容易漏报，也容易把正常的固定地址请求误判为漏洞。比较可靠的方法是围绕“输入—解析—连接—响应处理”建立完整的数据流。 一、先明确场景和威胁边界 审计前应先回答三个问题： 用户是否能够控制完整 URL，或者至少控制主机名、端口、路径中的一部分？ 服务端所在网络是否拥有浏览器或普通用户无法获得的访问权限？ 请求响应是否会被返回给用户、写入文件、进入解析器，或触发后续业务动作？ 这三个问题分别对应输入控制、网络能力和影响面。即使响应不会直接回显，只要请求能够触发内部服务的状态变化，或者造成敏感信息泄露、日志污染、资源消耗，也需要纳入风险评估。 在授权的测试环境中，建议使用本地
T0xfce

从一次代码审计视角看 SSRF 漏洞的识别、验证与修复

背景 SSRF（Server-Side Request Forgery，服务端请求伪造）一直是 Web 安全里比较容易被低估的问题。它不像 SQL 注入那样直接，也不像文件上传那样容易被肉眼识别，但一旦出现在具备内网访问能力的服务端组件上，影响面往往会被放大。 这类问题常见于图片抓取、URL 预览、Webhook 回调、文件转存、在线文档解析、第三方接口代理等场景。开发侧通常认为“只是服务端帮用户请求一个 URL”，但安全风险正是来自这个“帮用户请求”。 本文从代码审计和漏洞验证的角度，整理一套相对克制、可落地的 SSRF 分析方法。重点放在识别风险点、构造安全验证、定位根因和修复方案，不涉及对真实内网资产的未授权探测。 典型场景 在一次业务代码审计中，遇到过类似功能：用户提交一个图片 URL，后端下载图片后上传到对象存储，再返回新的图片地址。简化后的逻辑如下： public String uploadByUrl(String imageUrl) { URL url = new URL(imageUrl); HttpURLConnection conn = (HttpU
T0xfce

从一次代码审计看 Java Web 文件上传漏洞的风险边界与修复思路

背景 文件上传是 Java Web 项目里很常见的功能，但也是代码审计中高频出问题的点。很多项目看起来做了扩展名限制、大小限制，甚至还把文件名改成了 UUID，但实际风险往往不只在“能不能上传 jsp”这一层。 我在审计业务系统时，通常会把文件上传当成一个独立攻击面来看：上传入口、文件存储位置、文件访问方式、后续解析链路、异步处理逻辑、对象存储策略，都可能影响最终风险。本文整理一套相对通用的分析方法，重点放在安全边界和修复建议上，不涉及利用型攻击操作。 典型场景 常见业务包括头像上传、附件上传、Excel 导入、富文本图片、工单附件、合同扫描件等。不同场景的风险不完全一样： 头像、富文本图片：通常会被前端直接访问，关注内容类型校验、图片重编码、存储桶权限。 附件、合同文件：关注敏感信息泄露、越权下载、路径穿越、文件名注入。 Excel/CSV 导入：关注解析库漏洞、公式注入、压缩包炸弹、异步任务异常处理。 压缩包上传：关注解压路径穿越、软链接、超大文件膨胀比。 很多问题不是单点漏洞，而是“上传 + 可访问 + 可解析 + 权限缺失”组合出来的风险。 技术分析 1. 只校验后缀是不够的
T0xfce

从代码审计到复现验证：一次 Spring Boot 文件上传风险的排查思路

背景 文件上传一直是 Web 安全里比较容易被低估的点。很多业务在设计时只关注“能不能上传成功”，但在安全层面，文件类型校验、存储路径、访问控制、解析行为、清理策略都会影响最终风险。尤其是 Spring Boot 项目里，上传接口通常写起来很快，代码量不大，但如果边界处理不清晰，后续很容易演变成任意文件写入、敏感文件覆盖、越权访问或存储型 XSS 等问题。 这篇文章整理一次偏通用的审计和验证思路，不针对特定厂商或真实线上目标。内容重点放在如何识别风险点、如何在本地环境做安全验证，以及如何给出可落地的修复建议。 常见场景 在代码审计中，文件上传功能通常出现在头像上传、附件上传、工单材料、富文本图片、导入模板、日志打包上传等场景。风险并不一定来自“上传 WebShell”这种极端情况，更多时候是业务和框架组合后的细节问题。 只校验文件后缀，没有校验 MIME、魔数和实际解析结果。 使用用户传入的文件名直接拼接保存路径。 上传目录位于静态资源目录下，文件上传后可被直接访问。 未做鉴权或只做前端限制，接口可被未授权调用。 同名文件覆盖导致业务文件、配置文件或其他用户文件被覆盖。 错误配置 Ng
T0xfce

从一次文件上传漏洞复盘看 Web 风险验证与加固

背景 文件上传一直是 Web 安全里比较“老”的问题，但在真实环境中它仍然反复出现。原因并不复杂：业务上确实需要上传头像、附件、合同、图片、压缩包；开发侧又容易把重点放在功能可用性上，而忽略文件类型识别、存储隔离、访问控制和后续处理链路。 这篇文章不讨论攻击利用细节，也不提供任何恶意控制手段，重点放在一次常见上传风险的复盘方法：如何在授权测试或内部自查中确认风险、定位问题代码、给出可落地的修复方案，并避免修复只停留在“限制后缀名”这种表层。 典型场景 一个业务系统提供附件上传功能，后端使用 Java Web 框架接收 multipart/form-data 请求，上传后的文件会被保存到服务器本地目录，并通过静态资源路径直接访问。 表面上看，系统已经做了限制： 前端限制只能选择 jpg、png、pdf、docx 等格式； 后端检查文件名后缀； 上传目录不允许目录遍历； 文件名会被重命名为 UUID。 但复盘时发现，风险并不一定来自“文件名能不能控制”，而是来自几个组合问题：后缀判断不严谨、内容类型信任客户端、上传目录位于 Web 可访问路径、应用服务器或中间件对特定扩展名存在解析行为。
T0xfce

一次 URL 预览功能的 SSRF 审计：从输入校验到出站访问治理

URL 预览、网页截图、Markdown 远程图片解析等功能，通常需要由服务端主动访问用户提交的地址。它们看起来只是普通的网络请求，但如果缺少严格的目标校验和出站访问控制，就可能演变为服务端请求伪造（SSRF）。 SSRF 的风险不只在于“能不能访问内网”，更在于应用本身往往拥有比普通用户更高的网络可见性和身份权限。一次看似简单的 URL 请求，可能触及内部管理面板、服务发现接口、容器网络或云环境的实例身份服务。因此，审计这类功能时，不能只检查黑名单是否完善，而应从解析、解析结果校验、连接建立、重定向、DNS 变化以及网络出口策略等多个层面建立完整边界。 一、问题场景与审计目标 假设业务提供了一个 URL 预览接口： POST /api/preview Content-Type: application/json { 'url': ' }服务端收到请求后，会抓取页面标题、摘要和缩略图，再将结果返回给前端。最初的实现可能类似下面这样： import requests def fetch_preview(url): response = requests.get(url,
T0xfce

一次 Web 代码审计中的文件上传风险梳理：从入口到落地验证

背景文件上传是 Web 系统里很常见的功能，头像、附件、合同、工单图片、导入模板都会涉及。它的问题在于看起来业务简单，实际跨了权限、存储、解析、访问控制、内容安全等多个边界。很多漏洞并不是单点过滤缺失，而是多个细节叠加后形成风险。这篇文章整理一次代码审计中比较典型的文件上传风险分析方法，重点放在如何从代码层面识别问题、如何做安全验证，以及如何给出可落地的修复建议。内容只讨论授权测试和防护思路，不涉及非法利用。问题场景审计目标是一个 Java Web 系统，后端使用 Spring MVC，上传文件通过统一接口处理。业务侧声称已经做了白名单校验，上传目录也不在 Web 根目录下。但在审计过程中发现，部分接口复用了上传服务，却传入了不同的参数，导致实际防护并不一致。简化后的调用关系大致如下：Controller -> UploadService.upload(file, bizType, userId) -> FileNameUtil.normalize(originalName) -> FileTypeValidator.check(fi
T0xfce

一次内网 WebShell 排查与溯源思路整理

背景 WebShell 排查是应急响应里比较常见、也比较容易被低估的一类工作。很多站点被入侵后，最先看到的不是漏洞利用过程，而是异常文件、异常进程、可疑访问日志或者主机告警。真正难的地方在于：如何判断 WebShell 是否仍然可用、攻击入口在哪里、是否存在持久化和横向扩散。 这篇文章整理的是一次较典型的内网 Web 服务器排查思路，重点放在文件分析、日志关联、代码审计和处置闭环上。内容尽量偏方法论，不涉及攻击利用引导，适合做日常排查清单参考。 场景描述 某业务系统部署在 Linux 主机上，技术栈为 Nginx + PHP-FPM，应用目录存在历史遗留代码和多个上传功能。安全设备告警显示：某 PHP 文件存在高危木马特征，同时 Web 访问日志中出现少量异常 POST 请求。 初步信息如下： 异常文件位于业务上传目录下，扩展名为 .php。 文件修改时间集中在凌晨低峰期。 访问来源 IP 较少，但 User-Agent 不稳定。 业务目录中存在多个可写目录，权限管理较粗。 排查目标 这类事件不建议只删除单个可疑文件就结束。比较稳妥的目标应该包括： 确认 WebShell 的数量、位置
T0xfce

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

SSRF（Server-Side Request Forgery，服务端请求伪造）并不是单纯的“请求了一个危险 IP”问题。实际审计中，风险往往来自 URL 解析不一致、重定向未限制、DNS 解析时机不当，以及应用所在网络缺少出口控制。本文从代码审计、授权验证和事件复盘三个角度，整理一套可落地的 SSRF 排查与防护方法。 一、问题背景：为什么 SSRF 容易被低估 常见业务功能包括头像抓取、Webhook、在线导入、网页截图、PDF 转换、远程文件解析和第三方 API 代理。这些功能都需要服务端根据用户输入访问一个 URL，本身并不等于存在漏洞，但如果访问目标、协议和网络出口没有经过严格约束，就可能形成 SSRF。 SSRF 的影响取决于应用权限和网络位置，常见风险包括： 访问云环境元数据服务、内部管理接口或仅监听在内网地址的服务。 通过服务端网络身份访问内部 API，造成越权读取或配置变更。 探测内网端口和服务类型，扩大后续攻击面。 利用高权限服务访问本地文件、Unix Socket 或特殊协议处理器。 将服务变成代理，影响审计溯源并增加出口带宽和资源消耗。 在实际风险评估中，不能
T0xfce