java sql注入包_java代码审计之SQL注入

前言

在java中，操作SQL的主要有以下几种方式：

•java.sql.Statement

•java.sql.PrepareStatment

•使用第三方ORM框架，MyBatis或者Hibernate

java.sql.Statement

java.sql.statement是最原始的执行SQL的接口，使用它需要手动拼接SQL语句。

String sql = "SELECT * FROM user WHERE id = '" + id + "'"; Statement statement = connection.createStatement(); statement.execute(sql);

这里很明显就是存在问题的。将id直接拼接到SQL语句并执行，所以可以构造语句进行注入。

java.sql.PrepareStatement

这是一个接口是对上面的Statement的扩展。使用了预编译。拥有防护SQL的特性

使用时，在SQL语句中，用 ? 作为占位符，代替需要传入的参数，然后将该语句传递给数据库，数据库会对这条语句进行预编译。如果要执行这条SQL，只要用特定的 set 方法，将传入的参数设置到SQL语句中的指定位置，然后调用 execute 方法执行这条完整的SQL。示例如下：

String sql = "SELECT * FROM user WHERE id = ?"; //预编译语句 PreparedStatement preparedStatement = connection.prepareStatement(sql); //填入参数 preparedStatement.setString(1,reqStuId); preparedStatement.executeQuery();

此时，如果我用之前的请求攻击，执行的SQL会变成 SELECT * FROM user WHERE id = ''or 1 #'，可以看到单引号是被转义了，同时参数也被一对单引号包裹，数字型注入也不存在了

特殊情况ORDER BY注入

我们已经知道，通过占位符传参，不管传递的是什么类型的值，都会被单引号包裹。而使用 ORDER BY 时，要求传入的是字段名或者是字段位置，如：

String sql = "SELECT * FROM user ORDER BY " + column;

那么这样依然可能会存在SQL注入的问题，在 Java 中会有两种情况：

column 是字符串型

这种情况和 Statement 中描述的一样，是存在注入的。要防御就必须要手动过滤，或者将字段名硬编码到 SQL 语句中，比如：

String column = "id"; String sql =""; switch(column){ case "id": sql = "SELECT * FROM user ORDER BY id"; break; case "username": sql = "SELECT * FROM user ORDER BY username"; break; ...... }

同样group by也存在同样的问题

MyBatis

MyBatis简介

MyBatis的使用方式主要有俩种，一种是使用注解，直接将SQL语句和方法绑定在一起，如下

package org.mybatis.example; public interface BlogMapper { @Select("SELECT * FROM blog WHERE id = #{id}") Blog selectBlog(int id); }

这种方式，适合简单的SQL语句，一旦语句长了，注释会变得复杂混乱，维护起来很麻烦，所以它只适合小项目(小项目用的也不多)。

用的最多的是第二种——XML配置，将SQL语句和Java代码分离，有独立的xml文件，描述某个方法会和某个SQL语句绑定。

如图，每一个接口，在资源文件目录中，都有对应的xml。接口中的方法，和xml中id相同的SQL语句关联。

例如，IArticleCateDao 的 list()方法被调用，那么就会找到 ArticleCateMapper.xml中 id等于 list 的方法，执行它的 SQL，然后根据 resultMap 描述的 字段-属性 映射关系，返回相应的实例对象。

这里的 resultMap 具体如下：

其中，id属性是该映射的名称，type属性代表映射的类。里面有 5 个子元素，id元素映射到ArticleCate的id属性。其它四个result元素中的column属性会映射到对应的property属性。

MyBatis注入问题

${} (不安全的写法)

使用 ${foo} 这样格式的传入参数会直接参与SQL编译，类似字符串拼接的效果，是存在SQL注入漏洞的。所以一般情况下，不会用这种方式绑定参数。

SELECT * FROM student WHERE stu_id = ${stuId}

{}(安全的写法)

使用 #{} 做参数绑定时， MyBatis 会将SQL语句进行预编译，避免SQL注入的问题。

MyBatis 预编译模式的实现，在底层同样是依赖于 java.sql.PreparedStatement，所以 PreparedStatement 存在的问题，这里也会存在。

ORDER BY 只能通过 ${} 传递。为了避免SQL注入，需要手动过滤，或者在SQL里硬编码 ORDER BY 的字段名。

此外，还有一种情况 —— LIKE 模糊查询。

看下面这个写法：

SELECT * FROM student WHERE student.stu_name LIKE '%#{stuName}%'

在这里，MyBatis 会把 %#{stuName}% 作为要查询的参数，数据库会执行 SELECT * FROM student WHERE student.stu_name LIKE '%#{stuName}%'，导致查询失败，经过查询失败的原因是这么写经MyBatis转换后(‘%#{name}%’)会变为(‘%?%’),而(‘%?%’)会被看作是一个字符串，所以Java代码在执行找不到用于匹配参数的 ‘?’ ,然后就报错了。

所以这里只能用 ${} 的方式传入。而如果用 ${} 又存在SQL注入的风险，怎么办呢？

最好的方法是，使用数据库自带的 CONCAT ，将 % 和我们用 #{} 传入参数连接起来，这样就既不存在注入的问题，也能满足需求啦。示例：

SELECT * FROM student WHERE student.stu_name LIKE CONCAT('%',#{stuName},'%')

还有一下几种方式避免模糊查询

把’%#{name}%’改为”%”#{name}”%” 使用标签的方式 AND address LIKE #{pattern2}

Hibernate注入问题

Hibernate 是一个高性能的 ORM 框架，可以自动生成 SQL 语句，通常与 Struts、Spring 一起搭配使用，也就是我们熟知的 SSH 框架。

HQL 是 Hibernate 独有的面向对象的查询语言，接近 SQL。Hibernate引擎会对 HQL 进行解析，翻译成 SQL，再将 SQL 交给数据库执行。

HQL 会出现注入的地方还是在字符串拼接的时候，审计的时候看看 SQL 是不是用加号 + 的就行了。

session.createQuery("from Book where title like '%" + userInput + "%' and published = true")

下面来看看 HQL 能防注入的安全写法。

第一种，使用具名参数 Named parameter：

ListstudentList = session.createQuery("FROM Student s WHERE s.stuId = :stuId") .setParameter("stuId",stuId) .list();

第二种，占位符 Positional parameter：

ListstudentList = session.createQuery("FROM Student s WHERE s.stuId = ?") .setParameter(stuId) .list()