前言

因为笔者也是代码审计初学者，写得不好的地方请见谅。该文章是以项目实战角度出发，希望能给大家带来启发。

审计过程

审计思路

1、拿到一个项目首先要看它使用了什么技术框架，是使用了ssh框架，还是使用了ssm框架，还是servlet等。

2、看看是否使用了shiro、spring security等统一的权限控制框架，如果未使用，则可以重点梳理一下逻辑漏洞。

3、通过lib、pom等查看开源组件版本信息，看看是否存在通用漏洞。

通过目录通识项目

从目录可知，该项目是ssh框架

审计SQL注入

思路：

1、追踪参数是否来自前端，并且来自前端的参数未经过安全处理。在jdbc技术、hibernate中使用+进行拼接，在mybatis中使用$符号拼接。

2、关键词直接搜：like、in、order by、group by等等

在上面提到该项目使用了ssh框架，也就是说项目如果使用了sql语句，则会用+进行拼接。所以按住ctrl+shift+R进行关键词全局搜索，like、IN、order by、group by，然后看看 SQL 是不是用加号 + 的就行了。

先搜索like，然后拉下来浏览文件，发现没有使用+拼接，所以这处不存在sql注入。

搜索in，然后拉下来浏览文件，然后点击进去

发现参数以数组绑定方式进行传参，有效地防止sql注入

搜索order by，然后拉下来浏览文件

随便点几个看看，发现order by后面的不是参数，所以不存在sql注入

搜索group by，发现没有SQL注入

审计XSS注入

思路：全局搜索XSS关键字是否设置了防御XSS的过滤且是否生效，因为有时候开发为了性能，虽然设置了XSS全局过滤器，但是没有开启，这也会导致XSS注入发生，也或者开启了全局过滤XSS，但是排除了某些API，那么这也会导致XSS注入事件发生。

注意：XSS全局过滤器无法过滤上传文件的内容，即可以上传一个带有弹窗功能代码的文件，这个也会导致XSS发生。

审计过程如下：

首先全局搜索XSS，发现似乎有xss防御机制。

点进去仔细分析一下看看，发现有一个正则匹配，

这个正则表达式的目的是在进行字符串检测时，优先考虑 ID 选择器（即以 # 开头的情况），以避免通过 location.hash 属性引发的 XSS 攻击。location.hash 是 URL 的片段标识符，如果直接将其内容当作 HTML 解析，可能导致安全漏洞。因此，通过优先识别 ID 选择器，可以有效降低这种攻击的风险。

但是 <script>alert('111')</script> 这样的字符串不能被这个正则表达式防止，因为这个正则表达式的主要目的是快速识别和区分 HTML 片段和 ID 选择器，并不是用于防止 XSS 攻击。

验证：

随便找一处，看看存不存在XSS注入。

点击保存，发现弹窗，即证明存在存储型xss注入。

从源码上分析：

首先根据页面特征找到对应的源码

我这里是通过【类型管理】找到对应的源码。

点进去看看是否能对应

看到上面的界面貌似是对应的后端，但是不敢确定所以打个断点，然后从前端提交数据，看看能不能进来

如下图所示，即找到了对应的后端。

补充：在Spring MVC中

@Valid 注解

@Valid 是一个用于启动Java Bean Validation的注解。它表示要对传入的对象（在这个例子中是 <code>SystemTypeList 实体）进行验证。

当你在方法参数上使用 @Valid 注解时，Spring会自动根据实体类中的注解（如 @NotNull, @Size, @Min, @Max 等）对传入的数据进行验证。

如果验证失败，验证错误信息会被存储在 BindingResult 对象中。

BindingResult 参数

BindingResult 是一个Spring框架提供的接口，用于存储验证结果和绑定错误。

BindingResult 必须紧跟在需要验证的对象参数之后，否则Spring会抛出一个异常。

如果验证失败，BindingResult 对象会包含错误信息。你可以使用它来检查是否有验证错误，并获取具体的错误信息

利用下面这行代码进行校验

ResultVO res = BindingResultVOUtil.*hasErrors*(br);

点击下一步，发现校验成功

校验成功，又因为我们不是通过编辑的界面来到的，所以来到下面这一步

当来到这一步时候，我们在想，这个会不会保存进去数据库里面，从而造成存储型XSS

我们看一下save方法是怎么样实现的

可以看到

知识补充：

上一个代码片段是一个 Spring 服务类的部分实现，使用了 Spring Data JPA 来处理数据库操作。让我们详细解释一下这个实现：

<code>@Autowired private TypeDao typeDao;

@Autowired 注解用于自动注入 TypeDao 实例。TypeDao 是一个数据访问对象（DAO），通常是一个接口，继承自 JpaRepository 或 CrudRepository。

保存和更新方法:

public SystemTypeList save(SystemTypeList list) { return typeDao.save(list); }

上面这个方法接受一个 SystemTypeList 对象，并调用 typeDao.save(list) 将其保存到数据库中。

typeDao.save(list) 是 Spring Data JPA 提供的方法，它会根据 list 对象的主键值来决定是进行插入操作（新增）还是更新操作。我们这里是插入操作。

总结：到了这里，相信大家都明白了代码逻辑了吧，我们从前端传入参数，后端在接受到参数时不进行任何过滤操作而直接对前端传来的参数进行处理并且插入了数据库里面，所以导致了存储型XSS注入。

审计文件上传

审计思路：

1、文件上传可以搜索以下关键词：

File

**FileUpload**

FileUploadBase

FileItemIteratorImpl

FileItemStreamImpl

FileUtils

UploadHandleServlet

FileLoadServlet

FileOutputStream

DiskFileItemFactory

MultipartRequestEntity

MultipartFile com.oreilly.servlet.MultipartRequest

write

fileName

filePath

2、在查看时，主要判断是否有检查后缀和文件的大小

3、查看配置文件是否有设置白名单或者黑名单（不推荐黑名单，可能被绕过）

实战审计过程如下：

可能是笔者习惯吧，就是在进行白盒审计的时候，总喜欢在前端页面找到功能点，然后再去找程序入口，我看有的师傅是关键词直接搜，然后再审，然后再找到前端进行验证（虽然有一些漏洞笔者审计思路也是这样），废话不多说，马上开干。

首先在前端找到一个文件上传功能点

接着，根据前端特征，如文件管理，上传，("file")等关键词，直接全局搜索。

找到一个貌似是对应的后端代码

还不确定，再根据路由（fileupload），这个一般都是通过action传过来的，直接搜前端代码，看到这个前端页面，看到很明显是对应的代码，如果想要再次确认，可以打开再次与浏览器上面的web界面对比。

那么，现在就要开始打断点调试了。

笔者经过反复的测试，发现xxx.jsp、xxx.jspx都不能被解析，也就是说，不能getshell，那么好不容易找到一个上传点，真的要止步于此了嘛，再结合黑盒的经验，看看能不能混个XSS漏洞。又想起这是任意文件上传的，那么，能不能上传一个带有弹窗代码的.html文件呢？经过测试确实可以这样。

1111111.html的文件内容如下：

<script>alert('1111');</script>

来到下面这一步，可以发现这一步是保存文件的

然后找到savefile这个方法

来到实现savefile方法的文件，发现这个方法没有对前端传来的文件作任何处理。

知识补充：

<code>transferTo 方法是 Java 中 MultipartFile 接口的一部分，用于将上传的文件直接写入目标文件。这个方法在 Spring MVC 中非常常见，因为它可以高效地处理文件上传。

transferTo主要功能

transferTo 方法将 MultipartFile 实例表示的文件内容直接传输到文件系统中的一个目标文件。与手动处理文件流相比，它提供了一种更简单且高效的方式来保存文件。

那么，我们的项目中的文件就是通过这个transferTo 方法将文件写入的。

点击下一步，就把带有弹窗代码的文件成功写入。

访问一下，看看能不能被解析。

很好，文件类XSS漏洞+1。