免杀是同所有的检测手段的对抗，目前免杀的思路比较多。本篇介绍了一个独特的思路，通过内存解密恶意代码执行，解决了内存中恶意代码特征的检测。同时提出了one click来反沙箱的思路，阐述了一些混淆反编译的想法。

原文链接：https://forum.butian.net/share/2683

本文为Java代码审计入门的一篇文章，学习SSM框架的开源代码审计

审计环境

jdk 7u80 
Tomcat 7 
Maven 3.6.3

下载源码后，导入数据库，IDEA导入项目，并修改数据库配置信息

配置Tomcat运行，即可访问系统

结构分析

开始审计前，先看看网站文件和结构

• src/main/java：存放java代码的目录

• src/main/resources：存放资源的目录，包括properties、spring、springmvc、mybatis等配置文件

• src/main/webapp：存放网站的JSP、html、xml等web应用源代码
  可以看出是一个SSM架构（即Spring+Spring MVC+MyBatis）

然后看一下几个文件：

• pom.xml：Maven的主要配置文件。在这个文件中，可以看到当前项目用了哪些组件以及组件的版本，如果使用了存在漏洞的组件版本，可以快速发现。

• web.xml：Tomcat启动时会自动加载web.xml中的配置，文件中配置了Filter、Listener、Servlet。主要关注Filter过滤器，查看网站的过滤措施。

• applicationContext.xml：Spring的全局配置文件。其中也会包含对其他的配置文件的引用。

• spring-mvc.xml：其中会有静态资源映射、拦截器配置、文件上传限制等配置

pom.xml

搜索发现该版本log4j存在CVE-2019-17571反序列化漏洞，寻找漏洞处触发点，搜索SocketNode类，发现项目中没有调用。
所以即使项目使用了存在漏洞版本的组件，也不代表就一定存在相应漏洞

web.xml

只配置了两个filter过滤器，一个是配置了对字符进行编码，另一个是使页面具有统一布局，没有看到对XSS和sql注入的过滤器。

applicationContext.xml

spring-mvc.xml

配置了拦截的路径、上传文件的大小

源码审计

SQL注入审计

已经知道项目使用的是Mybatis，所以SQL语句会有两种定义方式，一个是使用注解的方式，一个是在Mapper.xm文件中编写。

参数拼接也有两种常用的方式，即${}和#{}，#{}是采用预编译的方式，${}是采用简单的拼接。

然后Mybatis框架下易产生SQL注入漏洞的情况主要分为三种，like、 in和 order by 语句。

所以根据以上信息，在xml文件中搜索${（当然也可以去搜索这些语句来寻找审计参数是否可控）

后台SQL注入

在ArticleMapper.xml中，发现存在用 in 语句并使用${}方式传参

然后找到该mapper对应的实现类

然后找到类调用的地方，确定请求路径和传参方式，请求路径为/admin/article/delete，参数是通过articelId传入

漏洞验证

/admin/article/delete?articelId=1
sqlmap跑一下

前台SQL注入

同样在CourseFavoritesMapper.xml中找到${}传参语句

然后找到调用该mapper的地方

路径为/uc/deleteFaveorite/{ids}，{ids}直接输入参数即可，格式如图

漏洞验证：

前台登录后抓包，放到sqlmap跑一下

其他还有几处也存在sql注入，漏洞成因都差不多，这里就不多写了。

XSS审计

审计XSS要点是定位用户的输入输出，梳理数据交互以及前端展示的过程。找到一个对应的输入输出的地方后，根据现有的安全措施（编码、过滤器）判断是否存在绕过的可能。

在结构分析时，已经知道web.xml中并没有发现对xss的过滤，接下来就需要分析在代码中是否存在过滤。

首先看看插入过程中是否存在过滤

抓包查看路由请求

全局搜索路由关键字，定位到控制器QuestionsController.java

addQuestions()方法，接收的传参的为Questions类，然后判断用户是否登录，然后调用了sevice层中的addQuestions()方法

查看Questions类的属性中有哪些是String类型的，可以在这些属性中插入XSS语句

查看它的实现类，调用questionsDao的addQuestions()方法

跟进addQuestions()方法，是一个Service

继续跟进，调用insert插入数据库中

根据insert中的信息找到对应的Mapper查看，将数据插入到edu_question表中

在整个插入数据的过程中，都没有对数据进行过滤

接着看输出部分，访问问答页面时触发XSS

根据路由questions/list定位到jsp文件

搜索.title、.content

发现标题处直接拼接数据库中的值输出，而内容处使用了<c:out>标签包裹，<c:out>标签是直接对代码进行输出而不当成js代码执行。所以标题处存在XSS，内容处不存在。

文件上传

全局搜索upload、uploadfile等寻找上传功能点

fileType从逗号处分割，存入type中，后续与上传文件后缀对比。
如果fileType中包含了ext则返回true，然后用取反，所以fileType中必须要包含ext，否则直接返回错误。随后获取文件路径，进行文件上传。

这里注意fileType是从请求中传入参数获取的，所以在上传时，只要在fileType传入jsp、jspx，就可以成功上传

漏洞验证：

构造上传数据包，成功上传

连接webshell

越权漏洞

注册账号进入用户中心，点击更改个人信息抓包发现userid，可能存在越权漏洞

在项目中全局搜索/updateUser，找到UserController

直接调用了userService的updateUser接口

进入接口实现类

继续跟进，最终跟到UserDaoImpl的updateUser方法

直接引用UserMapper的updateUser进行更新

整个流程没有任何的权限校验，没有判断 userId 与当前用户的关系，所以只要修改为其他用户id，就可以修改其他的用户信息

漏洞验证

注册两个账号

第一个账号test1

用户id为70

第二个账号test2

Java代码审计初试

用户id为71

在登录test2的情况下，抓包修改userId为70，并修改userName

然后登录test1账号，发现个人信息被修改

总结

本文涉及漏洞有限，审计漏洞也不够全面，主要是学习SSM框架的代码审计过程记录，在审计中意识到某些漏洞单纯通过白盒的方式难以发现，所以想要让审计更加全面，还需黑白结合的方式。