0day | 某在线拍卖系统代码审计
字数 3145 2025-10-26 18:21:34
某在线拍卖系统代码审计教学文档
文档概述
本教学文档基于一篇真实的代码审计文章,旨在引导安全研究人员或开发者学习如何对一个典型的Spring Boot项目进行安全审计。文档将涵盖从环境搭建、架构理解到具体漏洞挖掘的完整流程,重点分析鉴权逻辑缺陷和文件上传漏洞。
第一章:环境搭建
在进行代码审计之前,首先需要搭建一个可运行的系统环境,以便进行动态测试和验证。
步骤 1:数据库准备
- 创建一个名为
springbootp0eo6的 MySQL 数据库。 - 使用数据库管理工具(如 MySQL命令行或Navicat)的
source命令,导入项目提供的xxx.sql文件,以初始化数据表结构及默认数据。 - 修改项目配置文件(通常是
application.properties或application.yml),将数据库连接密码更新为您自己的密码。
步骤 2:系统启动与访问
- 直接启动Spring Boot应用。
- (可选)简化访问路径:项目中可能配置了
context-path(上下文路径)。如需简化URL,可以删除此配置,但需注意,修改后端配置后,前端的请求基地址(通常在https.js和config.js文件中定义)也需要相应地进行修改,否则前端页面将无法正确调用后端接口。
第二章:系统架构与鉴权机制分析
理解系统的安全控制机制是代码审计的核心,尤其是过滤器和拦截器。
2.1 拦截器(Interceptor)配置定位
Spring MVC的拦截器通常位于 config 包下。审计发现,系统的安全配置类继承了 WebMvcConfigurationSupport 并重写了关键方法。
-
addInterceptors方法:- 功能:此方法用于注册自定义拦截器并定义其拦截规则。
- 关键代码逻辑:
- 将自定义的
AuthorizationInterceptor(鉴权拦截器)添加到拦截器注册表中。 - 设置拦截路径:通过
.addPathPatterns("/**")拦截所有请求。 - 设置排除路径:通过
.excludePathPatterns("/static/**")放行所有静态资源请求。这意味着/static/目录下的文件无需鉴权即可访问。
- 将自定义的
-
addResourceHandlers方法:- 功能:指定静态资源(如图片、CSS、JavaScript文件)的存放位置。
- 配置:将
classpath:/static/目录映射为Web服务的根路径,客户端可通过类似http://localhost:8080/filename的URL直接访问这些资源。
2.2 鉴权拦截器(AuthorizationInterceptor)深度解析
这是整个系统安全的核心,其工作流程如下:
-
检查
@IgnoreAuth注解:- 拦截器首先判断当前请求的控制器方法上是否存在
@IgnoreAuth注解。 - 关键逻辑:如果存在该注解,则拦截器直接放行请求,不做任何身份验证。这是未授权访问漏洞的根源。
- 拦截器首先判断当前请求的控制器方法上是否存在
-
Token验证流程:
- 对于没有
@IgnoreAuth注解的请求,拦截器会从HTTP请求头中获取Token字段的值。 - Token生成机制:通过跟踪
tokenService,发现Token是一个32位的随机字符串,生成后会被存储在数据库中。 - Token验证机制:拦截器调用
tokenService.getTokenEntity(token)方法来验证Token的有效性。该方法使用MyBatis的selectOne方法执行SQL查询,逻辑等价于SELECT * FROM token_table WHERE token = ?。由于使用了参数化查询,此处不存在SQL注入漏洞。 - 会话(Session)设置:如果Token有效,拦截器会将与该Token关联的用户信息(如用户ID、角色、表名、用户名等)存入当前请求的Session中,然后放行请求。
- 对于没有
第三章:漏洞审计与利用
基于对架构的理解,我们可以系统地挖掘安全漏洞。
3.1 高危漏洞:未授权密码重置
这是本次审计中发现的最严重的逻辑漏洞。
- 漏洞位置:
/users/resetPass接口。 - 漏洞成因:该接口的控制器方法上标记了
@IgnoreAuth注解,导致其完全绕过了上述的鉴权拦截器。 - 请求方式:由于方法参数直接绑定且未使用
@RequestBody注解,该接口通过 GET请求 即可调用。 - 利用方式:
- 审计数据库,发现默认存在一个管理员用户,用户名为
abo。 - 构造URL直接访问:
http://localhost:8080/users/resetPass?username=abo。 - 系统会执行密码重置逻辑,将指定用户的密码重置为一个默认或随机的新密码(具体逻辑取决于
resetPass方法的实现)。
- 审计数据库,发现默认存在一个管理员用户,用户名为
- 漏洞验证:攻击者无需登录,即可通过此接口重置任意用户(包括管理员)的密码,从而完全接管账户。
3.2 文件上传漏洞
- 漏洞位置:
FileController.java中的upload方法。 - 漏洞分析:
- 该方法接收用户上传的文件。
- 文件保存路径为服务器的固定目录(如
resources/static/upload/)。 - 为防止文件名冲突,系统对保存的文件名进行了重命名,通常是在原文件名前添加时间戳。关键点在于,它未对文件内容进行严格的安全检查(如病毒扫描、内容校验),也未禁止上传特定类型的文件。
- 利用方式:
- 由于系统不支持JSP解析,因此无法直接上传Webshell。
- 但可以上传包含恶意JavaScript代码的HTML文件(XSS攻击载荷)。
- 上传成功后,文件会被保存在静态资源目录下,可通过Web直接访问,例如
http://localhost:8080/upload/12345678_malicious.html。当其他用户(尤其是管理员)访问此链接时,XSS脚本将被执行。
- 攻击场景:此漏洞可用于钓鱼攻击、窃取用户Cookie或会话信息,与密码重置漏洞结合可能产生更严重的后果。
第四章:总结与加固建议
审计总结
本次审计揭示了该在线拍卖系统在安全设计上的主要问题:
- 鉴权机制设计缺陷:过度依赖
@IgnoreAuth注解,且对重要敏感接口(如密码重置)未施加权限控制,导致严重的未授权访问漏洞。 - 输入验证不足:文件上传功能缺乏对文件类型和内容的有效验证与过滤,存在安全风险。
加固建议
- 最小权限原则:重新审查所有标记了
@IgnoreAuth的接口,确保只有真正的公共接口(如登录、注册)才无需鉴权。密码重置、个人信息修改、资金操作等敏感接口必须进行严格的身份验证,例如,除了验证Token,还应通过短信/邮箱验证码进行二次确认。 - 强化文件上传安全:
- 使用白名单机制,严格限制允许上传的文件扩展名(如只允许
.jpg,.png,.pdf等)。 - 对文件内容进行校验,例如检查图片文件的文件头(Magic Number)。
- 将上传的文件存储在Web根目录之外,并通过一个专门的文件下载控制器来提供访问,在该控制器中对请求进行权限校验。
- 避免使用用户可控的输入(如原文件名)直接构成服务器上的存储路径,防止路径遍历攻击。
- 使用白名单机制,严格限制允许上传的文件扩展名(如只允许
- 安全开发生命周期(SDL):在代码开发阶段引入安全代码规范,并定期进行代码审计和渗透测试。
文档结束