【创宇小课堂】SQL注入代码审计

admin 2021年10月11日09:00:50评论76 views字数 4437阅读14分47秒阅读模式

作者:W3yQr




前 言


在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 中会有两种情况:


//order by不能使用预编译原理 String sql = " SELECT passwd FROM test_table1 WHERE username = ? "; ps.setString(1, username)会自动给值加上引号。比如假设username=“ls”,那么拼凑成的语句会是String sql = " SELECT passwd FROM test_table1 WHERE username = 'ls' "; 再看order by,order by后一般是接字段名,而字段名是不能带引号的,比如 order by username;如果带上引号成了order by 'username',那username就是一个字符串不是字段名了,这就产生了语法错误。


  1. 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 具体如下:


<resultMap id="ArticleCateResult" type="ArticleCate"> <id column="id" jdbcType="INTEGER" property="id" /> <result column="fid" jdbcType="INTEGER" property="fid" /> <result column="name" jdbcType="VARCHAR" property="name" /> <result column="status" jdbcType="INTEGER" property="status" /> <result column="sort" jdbcType="INTEGER" property="sort" /> </resultMap>


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




MyBatis注入问题


${} (不安全的写法)

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


#{}**(安全的写法)**


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

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


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


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


看下面这个写法:

<select id="selectStudentByFuzzyQuery" resultMap="studentMap"> SELECT * FROM student WHERE student.stu_name LIKE '%#{stuName}%' </select>


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


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


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


<select id="selectStudentByFuzzyQuery" resultMap="studentMap"> SELECT * FROM student WHERE student.stu_name LIKE CONCAT('%',#{stuName},'%') </select>


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


把’%#{name}%’改为”%”#{name}”%” 使用标签的方式 <bind name="pattern1" value="'%' + _parameter.name + '%'" /> <if test="address != null and address != ''"> AND address LIKE #{pattern2}





MybatisPlus


mybatisplus无需写maper.xml文件,只需要继承BaseMaper就可以实现CURD操作

https://www.jianshu.com/p/ceb1df475021 https://segmentfault.com/a/1190000025189693 https://www.hxstrive.com/subject/mybatis_plus.htm?id=292 https://baomidou.com/guide/quick-start.html#%E5%BC%80%E5%A7%8B%E4%BD%BF%E7%94%A8





Hibernate注入问题


Hibernate简介

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


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


Hibernate注入问题

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


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


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


第一种,使用具名参数 Named parameter:

List<Student> studentList = session.createQuery("FROM Student s WHERE s.stuId = :stuId") .setParameter("stuId",stuId) .list();


第二种,占位符 Positional parameter:

List<Student> studentList = session.createQuery("FROM Student s WHERE s.stuId = ?") .setParameter(stuId) .list()

hibernate查询注入问题

https://www.sec-in.com/article/144


【创宇小课堂】SQL注入代码审计

【创宇小课堂】SQL注入代码审计

原文始发于微信公众号(安全宇宙):【创宇小课堂】SQL注入代码审计

  • 左青龙
  • 微信扫一扫
  • weinxin
  • 右白虎
  • 微信扫一扫
  • weinxin
admin
  • 本文由 发表于 2021年10月11日09:00:50
  • 转载请保留本文链接(CN-SEC中文网:感谢原作者辛苦付出):
                   【创宇小课堂】SQL注入代码审计https://cn-sec.com/archives/577379.html

发表评论

匿名网友 填写信息