我们在日常工作中，每次新版本上线前其实都需要先做代码层面的安全审计，在确认代码没有重大安全漏洞后才可以上线。

今天老李给大家分享一个JAVA代码审计的案例，希望能够给大家的工作中提供一点帮助。

当然了，如果项目预算够的话，尽量找第三方的安全机构进行审核，这样更能有针对性的找出未知风险隐患。

目录

前台找回密码处验证码重复利用
XSS
SQL注入
前台用户横向越权
CSRF
前台文件上传getshell

环境部署

1. 下载源代码，使用IDEA进行部署，项目pom.xml进行maven依赖包添加、配置数据库账号密码、配置开启端口后即可使用tomcat7插件运行项目。
2. 搭建过程遇见两个坑点：
3. mysql建议直接使用5.5.*版本的，高版本的会因为mysql的默认配置需要额外配置而遇见各种问题，虽然最后都能搭建成功，但是直接使用低版本的就无需额外配置。
4. 项目路径建议直接使用 http://IP:port 形式，后面不要配置额外的路径，加入额外项目配置后虽然可以部署成功，但是会导致一些页面或者图片加载不成功。
5. 进行代码审计时，记得需要额外把srcmainwebappWEB-INFlib目录下的jar包反编译后再进行代码审计，因为使用IDEA进行源码关键字搜索时不会搜索jar包中的代码，我审计之前就没有注意到项目下的这个目录，导致前面审计过程中某些功能找不到源代码。

项目结构分析

这是一个SSM（即Spring Framework、Spring MVC、MyBatis）架构项目。

百科是这样介绍的：

• pom.xml：审计maven项目首先应该查看pom.xm，通过查看此文件可以知道项目用了哪些组件及组件版本，这样可以快速查看组件对应的版本是否有漏洞。
• 观察到项目使用了log4j 且版本为1.2.17，此版本存在反序列化漏洞CVE-2019-17571（经过分析，不存在此漏洞，因为本项目未使用产生此漏洞的类即SocketNode类）。
• 还使用了druid 1.0.1 组件，可以找一些未授权接口（经过测试未发现此组件产生的未授权）。
• mybatis 3.2.7 组件存在反序列化漏洞CVE-2020-26945（经过分析，不存在此漏洞，因为此项目未开启mybatis二级缓存功能）。

• web.xml：程序启动时会先加载这个文件，此文件用来配置Filter、Listener、Servlet。此文件需要重点关注Filter过滤器的全局配置。
  此项目只配置了两个全局的过滤器且这两个过滤器都未对输入输出进行转义之类的字符处理，所以未配置全局的XSS过滤。

• applicationContext.xml：spring的默认配置文件，当容器启动时找不到其他指定配置文档时，将加载这个配置文件，此文件也包含引用其他的配置文件。

• spring-mvc.xml：此文件主要的工作是：启动注解、扫描controller包注解；静态资源映射；视图解析（defaultViewResolver）；文件上传（multipartResolver）;返回消息json配置。
  
  web项目启动时，读取web.xml配置文件，首先解析的是applicationContext.xml文件，其次才是sping-mvc.xml文件。
• Interceptor：拦截器，用于拦截用户请求并进行相应的处理。比如通过它来进行权限验证，或者是来判断用户是否登陆，或者是像12306 那样子判断当前时间是否是购票时间。
  此项目有3个拦截器，分别对前台用户、后台用户、网站配置管理处的用户是否登录与权限做相应处理。

代码审计

前台找回密码处验证码重复利用

直接在代码中搜索关键字验证码，对相关代码进行分析。

此处是找回密码功能，先后获取客户端与服务端验证码进行校验，校验成功后进入校验邮箱是否注册，若未注册则直接返回结果，未删除服务端中的旧验证码，所以此处可对验证码重复使用来爆破出已经注册的邮箱。

继续分析可知，邮箱存在且重置密码之后才清除服务端中的验证码。因为前台登录处无验证码，所以此处可配合登录处继续密码爆破。

但是经过分析，后台管理员登录处就不存在验证码重复利用，因为验证码校验正确后就会立马进行清除。

XSS

开头已经分析未发现全局的XSS过滤器，所以直接注册账号进行登录，见框就插入XSS payload。

在问答功能下的我要提问功能处发现存储型XSS。

此处只有标题有XSS而内容无XSS，找到对应的入口进行分析原因，questionsService.addQuestions()为添加问答方法，追踪此方法

QuestionsController-->QuestionsService-->QuestionsServiceImpl-->QuestionsDao-->QuestionsDaoImpl-->QuestionsMapper

根据追踪过程分析未做字符过滤就直接保存到数据库中。并且标题和内容都保存数据库中。

由此可知，存储过程标题和内容未做差异化处理，说明在输出的时候对内容进行了过滤，继续分析输出部分。由以上可知,存在XSS的url为http://127.0.0.1:8080/question/list。

直接在*.jsp文件中搜索question/list找到对应的输出点。很明显标题处是直接拼接数据库中的值并未使用标签包裹，而内容处则使用了标签。在jsp文件中，使用标签是直接对代码进行输出而不当成js代码执行。

自此，产生XSS的来龙去脉都已经知道了，所以输出变量时，没有使用标签进行防护的都会产生XSS，经分析其他还有多处有XSS。

SQL注入

因为使用的时mybatis框架，所以直接在*Mapper.xml文件中搜索${即可。

发现存在多处使用${}进行拼接的地方，选择一处进行分析

找到对应的controller层入口。此处为后台管理员用户删除文章功能处。

抓取请求包直接使用sqlmap爆破即可。

其他还有几处也存在sql注入。类似分析即可。有几处因为是直接拼接路径中的字符作为参数的，所以这种情况即使使用${}也不会造成sql注入。

前台用户横向越权

在用户修改个人资料时，直接抓包修改 user.userId参数值即可越权登录到其他存在的用户。

分析代码可知，未对用户进行判断就直接把用户信息更新到数据库中，更新数据库中后直接使用userid进行自动重新登录从而可导致直接登录其他用户界面。

CSRF

后台管理员创建用户处存在CSRF漏洞，攻击者可结合此系统的XSS漏洞构造恶意代码从而导致创建系统管理员用户。

可用burpsuite自带的CSRF工具生成payload进行测试。

从代码处可知，未对请求体校验Referer字段，也无token机制。因此可造成CSRF。

前台文件上传getshell

前置知识点

jspx：以xml语法来书写jsp的文件，自定义的映射类型，jspx=jsp+xml；jspx文件本身符合xml的规范，但是它本质又是一个jsp文件，所以在所有jsp里面能够做到的事情在jspx里同样可以做到。

tomcat的web.xml中org.apache.jasper.servlet.Jspservlet配置关于jsp服务的解析，默认是都会解析jsp和jspx。

此处漏洞发生在前台用户上传头像处。

直接找到源代码进行分析，源码在srcmainwebappWEB-INFlibinxedu-jar.jar包中。

此处的fileType即为前端传入的文件类型后缀，分析代码可知，此处只过滤了jsp文件其他文件可随意上传，可以上传html文件造成XSS漏洞，由于此项目使用tomcat，所以可以上传jspx文件getshell。

使用哥斯拉工具生成jspx木马上传文件，上传成功。

连接成功。

本文作者：smworld

来源：FreeBuf.COM