Java代码审计-SQL注入

前言

今天学习了java代码中导致的sql注入的相关知识，浅浅的记录一下。

一、SQL注入简介

SQL 注入是因为程序未能正确对用户的输入进行检查，将用户输入以拼接的方式带入 SQL 语句中，影响原 SQL 语句的逻辑，导致了 SQL 注入的产生。

SQL 注入漏洞可能会造成服务器的数据库信息泄露、数据被窃取、网页被篡改，甚至可能会造成网站被挂马、服务器被远程控制、被安装后门等。

二、Java主要执行SQL语句的方式

1.JDBC

JDBC是Java连接数据库的标准API。它提供了一组接口和类，用于与关系型数据库进行交互。通过JDBC，可以连接到各种数据库（如MySQL、Oracle、SQL Server等），执行SQL语句、事务管理和结果集处理等操作。

2.MyBatis

ORM框架，允许将Java对象和关系型数据库之间进行映射，进而实现数据库操作。

Mybatis 是一个持久层框架，它封装数据连接、获取结果集等一系列的繁琐操作，使用者只需关注操作 SQL 语句的编写，通过 xml 或注解的方式就能将数据库中的数据与对象形成映射进行返回。

Mybatis 的学习曲线相对较低，适合对 SQL 有深入理解的开发者。

3.Hibernate

Hibernate是一个开放源代码的对象关系映射框架，它对JDBC进行了非常轻量级的对象封装，它将java对象与数据库表建立映射关系，是一个全自动的orm框架。

Hibernate可以自动生成SQL语句，自动执行，使得Java程序员可以随心所欲的使用对象编程思维来操纵数据库。

Hibernate 的学习曲线较高，需要理解其 ORM 模型和配置。

三、JDBC方式产生的漏洞

1.Statement方式

java.sql.Statement 是 Java JDBC 下执行 SQL 语句的一种原生方式，执行语句时需要通 过拼接来执行。若拼接的语句没有经过过滤，将出现 SQL 注入漏洞。

//采用拼接的方式 
String sql = "select * from user where id = "+req.getParameter("id"); 
 Statement st = con.createStatement(); //创建Statement对象
 ResultSet rs = st.executeQuery(sql); //执行查询

由上述代码可以看到，该方式只是对前端用户输入直接进行sql语句的拼接，然后代入数据库查询，可导致SQL注入漏洞。

2.PreparedStatement方式

PreparedStatement 会预处理 SQL 语句，为原本需要拼接的参数参数保留一个问号（?）作为占位符。

采用预编译的方式，可以有效地防止SQL注入漏洞。

//sql语句如下  使用？代替之前需要拼接的参数
String sql = "select * from user where id = ?"; 
PreparedStatement pstt = con.prepareStatement(sql); //对sql语句进行预编译
pstt.setInt(1,Integer.parseInt(req.getParameter("id"))); //对里面的参数进行设置 可以理解成将id转换为int后放到第一个？的位置
 ResultSet rs = pstt.executeQuery();//执行查询

像上述这样正确使用预编译的操作是比较安全的，可以有效防止SQL注入。

那么，预编译防止SQL注入怎么做的呢？

• 对下面代码，输入" 小明’ ",经过测试发现是对特殊符号加入转义字符。

String sql = "select * from user where name = ?";  // sql语句
PreparedStatement st = conn.prepareStatement(sql);  //预编译
st.setString(1, "小明'"); // 参数赋值 sql注入测试
System.out.println(st.toString()); //输出为：select * from user where name = '小明\''

那么，使用预编译的方法就完全避免注入的影响了嘛？、

• 答案是否定的。

经过测试发现，预编译不会对%进行转移，这正好是SQL语句like查询需要的。

假如代码如下所示，则会遇到SQL注入的风险。

String sql = "select * from user where name like ?";  // 含有参数 
st = conn.prepareStatement(sql);
st.setString(1, "%小明%" + "%"); // 参数赋值
System.out.println(st.toString()); //输出为select * from user where name like '%小明%%'

这样就改变了原本查询的意思。

另外，预编译也不会对_进行转义。

那么，还有个问题，就是不是所有的语句都能够使用预编译来解决的。

• 比如代码中使用order by语句时，这种特殊情况无法使用预编译。order by 子句后面需要加字段名或者字段位置，而预编译后产生的是字符串，不再是字段名，这种情况下只能使用sql语句拼接的办法。
• 所以使用这些特殊语句时，要注意对输入进行过滤。

四、MyBatis方式产生的漏洞

1.两种参数符号造成的SQL注入

MyBatis支持两种参数符号，一种是#，另一种是$。

• 当使用#时，MyBatis底层会使用预编译的机制。
• 使用参数符号$时，MyBatis底层直接用字符串拼接把参数和SQL语句拼接在一起，然后执行。

2.order by、like、in引发注入

• 与第三部分的描述类似，在mybatis中使用order by语句的话，只能使用参数符号$,即使用字符串拼接的方式，如果没有进行严格过滤，则导致注入。
• like in 同理

五、Hibernate方式产生的漏洞

1.简介

• HQL注入:Hibernate中没有对数据进行有效的验证导致恶意数据进入应用程序中造成的。与SQL注入类似。

2.原理

与第三部分、第四部分类似。

参数绑定，这样是安全的

String queryString = "from Item item where item.deion like :searchString”;

List result = session.createQuery(queryString).setString("searchString", searchString).list();

直接拼接是不安全的。

HQL注入利用比较有限。

六、总结

综上所述，主要是考虑代码是否使用了预编译，以及对于一些未使用预编译的特殊语句，是否进行了安全的校验。

参考

• Java注入类漏洞精选技术文章汇总 (qq.com)
• Hibernate与MyBatis的区别_hibernate和mybatis的区别-CSDN博客
• 用java PreparedStatement就不用担心sql注入了吗？ - 杨元 - 博客园 (cnblogs.com)
• https://xz.aliyun.com/t/2343
• 网络安全：Java代码审计实战
• Java代码审计入门篇