跳转到帖子

黑客攻防博客

T0xfce的博客在 黑客攻防

  • 篇帖子

    6

  • 篇意见

    0

  • 次查看

    2

关于此博客

网络安全，渗透测试

一次 SSRF 漏洞复现与代码审计思路整理

背景 SSRF（Server-Side Request Forgery）在实战和代码审计中都很常见，尤其出现在图片抓取、Webhook 回调、URL 预览、文件导入、云存储同步、PDF 转换等功能里。它的特点是入口看起来不敏感，但一旦服务端可以代用户发起请求，就可能访问到原本外部不可达的内网资源。 这篇文章不讨论如何攻击真实目标，主要整理一个偏防守视角的复现与审计方法：如何搭建安全测试环境、如何识别风险代码、如何验证问题边界，以及如何做相对可靠的修复。 典型场景 一个常见业务功能是“通过 URL 上传图片”。用户提交一个图片地址，后端下载后保存到对象存储或本地目录。伪代码大致如下： POST /api/image/import { "url": " }后端逻辑可能会做一次 HTTP 请求： resp = httpClient.get(userInputUrl) if resp.statusCode == 200: save(resp.body)如果没有对目标地址做限制，服务端可能会请求任意 URL。风险不只在于访问内网地址，还包括探测内部服务、读取云环境元数据、触发内部管理
T0xfce

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

背景 任意文件读取是 Java Web 项目里比较常见、但经常被低估的一类问题。它不一定直接导致代码执行，但如果能读取配置文件、密钥文件、日志或源码，后续风险会明显放大，例如数据库凭据泄露、JWT 密钥泄露、云服务 AK/SK 泄露等。 这篇文章整理一次代码审计中遇到的文件下载接口问题。为了避免误导，文中示例均为脱敏后的本地测试代码，重点放在漏洞成因、复现思路、修复方式和排查清单上，不涉及真实目标。 问题场景 某业务系统提供附件下载功能，接口大致形式如下： GET /api/file/download?name=report.pdf服务端根据 name 参数拼接文件路径，然后把文件内容写回响应。开发初衷是只允许下载某个固定目录下的业务附件，但代码中没有对路径穿越做严格限制。 脱敏后的问题代码类似这样： String baseDir = "/data/app/upload/"; String name = request.getParameter("name"); File file = new File(baseDir + name); if (!file.exists()) {
T0xfce

从一次未授权访问排查谈内网 Web 服务暴露面治理

背景 内网 Web 服务未授权访问是很多安全事件的起点。它不一定表现为高危漏洞，有时只是一个调试接口、一个默认后台、一个临时部署的管理端口，但一旦被纳入横向移动路径，就会放大成真实风险。 这篇文章整理一次常见的内网排查思路，重点放在暴露面识别、风险判断、日志验证和治理闭环上。内容不涉及攻击控制或绕过类操作，适合作为企业内网自查、红队复盘后的加固参考。 问题场景 某业务内网中存在多个历史系统，包含 Java 管理后台、Node.js 调试服务、Prometheus 指标接口、对象存储控制台以及若干临时测试页面。安全巡检时发现部分接口无需认证即可访问，其中部分接口返回了敏感运行信息。 典型表现包括： 管理后台直接访问，无登录或默认弱认证。 调试端口暴露，如 Spring Boot Actuator、Node inspector、Swagger UI。 指标接口泄露主机名、服务名、数据库连接状态等信息。 测试接口返回配置片段、异常堆栈或内部 IP。 反向代理配置不严，导致内部路径可被直接访问。 技术分析 未授权访问的本质不是“有没有漏洞利用代码”，而是访问控制边界失效。常见原因主要有三类。
T0xfce

一次可复现的 Web 代码审计流程：从入口面梳理到风险验证

背景 很多漏洞不是靠“扫一下”就能稳定发现的，尤其是业务系统里的鉴权缺失、越权、文件处理、模板渲染等问题。工具能提高覆盖率，但最终还是要回到代码路径和数据流本身。这里整理一套我在审计 Web 项目时常用的流程，偏长期可复用的方法，不针对某个具体系统，也不包含真实目标攻击操作。 文章里的示例以常见 Java/Spring Web 项目为主，思路同样适用于 PHP、Node.js、Python Web 框架。重点是如何把“看代码”变成一套可复现、可记录、可验证的工作流。 审计前的准备 拿到代码后，第一步不是直接搜索危险函数，而是先把项目跑起来或至少把结构理清。建议先关注以下信息： 框架类型：Spring MVC、Spring Boot、ThinkPHP、Express、Django 等。 路由入口：Controller、Router、Servlet、Filter、Interceptor。 认证方式：Session、JWT、OAuth2、自研 Token、网关注入用户信息。 数据访问层：MyBatis、JPA、原生 SQL、ORM Query Builder。 文件处理：上传、下载、导入导出
T0xfce

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

背景 文件上传一直是 Web 安全里比较常见、也比较容易被低估的风险点。很多业务团队会认为“只要限制后缀名”“只要上传目录不在 Web 根目录”就足够了，但在实际代码审计和应急排查中，上传链路往往会牵涉文件名处理、存储路径拼接、对象存储回调、图片解析、异步任务、预览接口等多个环节。 这篇文章整理一个相对通用的排查方法，以 Spring Boot 项目为例，讨论如何从代码审计角度识别文件上传风险，并用安全、可控的方式做复现验证。内容偏防守和工程落地，不涉及恶意利用或未授权攻击。 典型场景 某业务系统提供附件上传功能，接口大致如下： 用户上传头像、合同、工单附件等文件； 后端根据原始文件名生成存储路径； 上传后返回文件访问 URL； 部分文件支持在线预览或下载。 审计时看到类似代码： @PostMapping("/upload") public Result upload(@RequestParam("file") MultipartFile file) throws IOException { String originalName = file.getOriginalFilen
T0xfce

一次 Spring Boot 管理接口暴露引发的风险复盘与加固实践

背景 最近整理历史安全巡检记录时，发现 Spring Boot Actuator 管理接口暴露仍然是企业内网和测试环境里很常见的问题。它不一定直接等同于高危漏洞，但在真实攻防里，经常会成为信息收集、横向定位、配置泄露甚至进一步利用的入口。 这篇文章不写攻击链细节，也不讨论未授权利用手法，主要从防守视角复盘一个典型场景：某业务系统将 Actuator 暴露在办公网和部分公网出口后，导致应用运行状态、环境变量、路由信息、Bean 信息被非预期访问。文章重点放在如何识别风险、判断影响面，以及如何做可落地的加固。 问题场景 目标系统是一个常见的 Java 微服务，使用 Spring Boot 2.x，接入了注册中心、配置中心、Redis、MySQL 和消息队列。由于早期为了方便排障，研发在配置中启用了较多 Actuator endpoint，并且网关层没有针对管理路径做单独访问控制。 风险点主要集中在以下几类： /actuator 入口可被非运维人员访问。 /actuator/env、/actuator/configprops 等接口暴露敏感配置键名或部分值。 /actuator/mappin
T0xfce