Java安全-常规漏洞问题（SQL注入,XXE,SSRF,RCE）

靶场搭建

靶场下载 ：

https://github.com/whgojp/JavaSecLab

这个靶场是使用Springboot搭建的所以不要下载 jar 文件运行，要使用IDEA运行他的文件夹

先打开pom 然后进行maven一下

改一下端口

配置完成之后修改一下 运行的模式

使用phpstudy搞一个sql数据库

导入sql文件

运行应用

SQL注入

先了解一下sql注入的修复形式和漏洞成因 ：成因说白了就是使用字符串拼接的形式进行查询数据库才导致数据的恶意插入       修复形式就是把字符串拼接的形式改为预编译（预编译分为函数的调用和形式的调用）如果只是调用了函数那还是会造成sql问题

第一类：JDBC

JDBC数据库是一种通过API接口进行数据存储交互的形式 所以它是可以加载远程的数据库的

先看payload

1' and updatexml(1,concat(0x7e,(SELECT user()),0x7e),1) AND '1'='1

这是个报错注入

从白盒角度去审计一下：

场景二是

漏洞出现的原因 ：sql语句仍是拼接模式下的

安全场景 ：

第二类MyBatis

还有个注意点就是  #{}  这样处理下 {} 内的内容 会转为字符串

介绍一下Mybatis 数据库 他的配置和jdbc完全是不一样的

他不是和JDBC一样使用一个单个的文件进行处理

所以他的安全问题按理来说是非常好的

但是就是因为    #{}  这样处理下 {} 内的内容 会转为字符串

所以一些如order by 1  如果使用     #{}   1会被转为字符串  但是 by后面跟的必须是int数字 所以会报错   这样的话程序员就只能使用 ${} 进行字符串的拼接  所以就能使用在这个点上进行注入 

可以先把前面的整数进行闭合就能进行注入语句的插入

Order by 漏洞问题

语句：

1' and updatexml(1,concat(0x7e,(SELECT user()),0x7e),1) AND '1'='1

漏洞点 ：

通过审计处理 就是因为 ${}

% 和 Like模糊匹配 安全问题

审计一下 上面的多余代码

// Controller层
public R special1OrderBy() {
  List<Sqli> sqlis = new ArrayList<>();  //新创一个数据库数据交互列表
  switch (type) {  //选择 查询的类型 
      case "raw":   //原始类型   
          sqlis = sqliService.orderByVul(field);   //这个是引用mapping 层的那个 ${} 拼接执行
          break;
      case "prepareStatement":  //这个就是使用预编译参数  
          sqlis = sqliService.orderByPrepareStatement(field);  //这个是执行的是mapping 中的#{}
          break;
      case "writeList":   // 使用白名单模式
          sqlis = sqliService.orderByWriteList(field);
      ...
// Service层
//自定义SQL-使用#{}
@Override  
//服务层就是对查询的数据进行回显		  
public List<Sqli> orderByVul(String field) {
    return sqliMapper.orderByVul(field);
}
@Override
public List<Sqli> orderByPrepareStatement(String field) {
    return sqliMapper.orderByPrepareStatement(field);
}
@Override
public List<Sqli> orderByWriteList(String field) {
    return sqliMapper.orderByWriteList(field);
}

in 后参数问题

我们知道 

第三类  Hibernate

这个漏洞仍然是 原生的拼接导致的 ：

预编译的使用并不是执行的代码不管用了  而是被当做了字符串

第四类 SPA

缺陷仍然是原生

小结SQl注入

以上四个不是数据库，而是数据库处理的框架  他们的本意就是优化数据库到代码中间的操作

黑盒测试就是使用找参数点 然后盲注

白盒 ： 需要先分辨数据库 ：最容易分辨的  MyBatis，所以他的判断就是 在maping文件中看是否有三个危险的语句

其他的就是寻找 控制器有没有相应的配置

找到数据库之后就先找 语句是否使用拼接模式  或者看是否使用预编译

各个数据的预编译 ：

-JDBC
1、采用Statement方法拼接SQL语句
2、PrepareStatement会对SQL语句进行预编译，但如果直接采取拼接的方式构造SQL，此时进行预编译也无用。
3、JDBCTemplate是Spring对JDBC的封装，如果使用拼接语句便会产生注入
4、自定义过滤（黑白名单）
安全写法：SQL语句占位符（?） + PrepareStatement预编译

-Hibernate
1、setParameter：预编译
2、username=:username 预编译

-JPA
1、username=:username 预编译

XXE漏洞

XXE类似于反序列化  不过就是xml框架的权限比较高可以支持直接进行一些修改框架插入恶意代码就能执行一些命令

XXE的前提是项目没有禁用外部的实体（一般是不会禁用的）

他主要就是解析 <> 内的内容实现注入

代码审计SINK点：
  1、XMLReader
  2、SAXReader
  3、DocumentBuilder
  4、XMLStreamReader
  5、SAXBuilder
  6、SAXParser
  7、SAXSource
  8、TransformerFactory
  9、SAXTransformerFactory
  10、SchemaFactory
  11、Unmarshaller
  12、XPathExpression

RCE

白盒审计下的相关函数

命令执行 ：

1、ProcessBuilder

Runtime.getRuntime().exec()

3、ProcessImpl

代码执行：  Groovy代码注入