51Testing软件测试论坛

 找回密码
 (注-册)加入51Testing

QQ登录

只需一步,快速开始

微信登录,快人一步

查看: 1241|回复: 0

mybatis是如何防止SQL注入的

[复制链接]
  • TA的每日心情
    无聊
    昨天 09:28
  • 签到天数: 385 天

    连续签到: 4 天

    [LV.9]测试副司令

    发表于 2018-12-27 16:17:18 | 显示全部楼层 |阅读模式
    本帖最后由 测试积点老人 于 2018-12-27 16:19 编辑

    SQL注入是一种很简单的攻击手段,但直到今天仍然十分常见。究其原因不外乎:No patch for stupid。


    为什么这么说,下面就以JAVA为例进行说明:

    假设数据库中存在这样的表:

    table user( id varchar(20) PRIMARY KEY ,

    name varchar(20) ,

    age varchar(20) );


    然后使用JDBC操作表:

    private String getNameByUserId(String userId) {

    Connection conn = getConn;//获得连接

    String sql = "select name from user where id=" + userId;

    PreparedStatement pstmt = conn.prepareStatement(sql);

    ResultSet rs=pstmt.executeUpdate; ......

    }


    上面的代码经常被一些开发人员使用。想象这样的情况,当传入的userId参数为"3;drop table user;"时,执行的sql语句如下:

    select name from user where id=3; drop table user;

    数据库在编译执行之后,删除了user表。瞧,一个简单的SQL注入攻击生效了!之所以这样,是因为上面的代码没有符合编程规范。 当我们按照规范编程时,SQL注入就不存在了。


    这也是避免SQL注入的第一种方式:

    预编译语句,代码如下:

    Connection conn = getConn;//获得连接

    String sql = "select name from user where id= ?";

    PreparedStatement pstmt = conn.prepareStatement(sql);

    pstmt.setString(1, userId);

    ResultSet rs=pstmt.executeUpdate; ......


    为什么上面的代码就不存在SQL注入了呢?因为使用了预编译语句,预编译语句在执行时会把"select name from user where id= ?"语句事先编译好,这样当执行时仅仅需要用传入的参数替换掉?占位符即可。


    而对于第一种不符合规范的情况,程序会先生成sql语句,然后带着用户传入的内容去编译,这恰恰是问题所在。 除了使用预编译语句之外,还有第二种避免SQL注入攻击的方式:存储过程。


    存储过程(Stored Procedure)是一组完成特定功能的SQL语句集,经编译后存储在数据库中,用户通过调用存储过程并给定参数(如果该存储过程带有参数)就可以执行它,也可以避免SQL注入攻击

    Connection conn = getConn;

    stmt = conn.prepareCall("{call name_from_user(?,?)}");

    stmt.setInt(1,2);

    stmt.registerOutParameter(2, Types.VARCHAR);

    stmt.execute;

    String name= stmt.getString(2);


    上面的代码中对应的存储过程如下:

    use user; delimiter // create procedure name_from_user(in user_id int,out user_name varchar(20)) begin select name into user_name from user where id=user_id; end // delimiter ; 当然用户也可以在前端做字符检查,这也是一种避免SQL注入的方式:比如对于上面的userId参数,用户检查到包含分号就提示错误。


    不过,从最根本的原因看,SQL注入攻击之所以存在,是因为app在访问数据库时没有使用最小权限。想来也是,大家好像一直都在使用root账号访问数据库。 那么mybatis是如何避免sql注入攻击的呢?还是以上面的表user为例: 假设mapper文件为:

    SELECT name FROM user where id = #{userId} 对应的java文件为:

    public interface UserMapper{ String getNameByUserId(@Param("userId") String userId); }


    可以看到输入的参数是String类型的userId,当我们传入userId="34;drop table user;"后,打印的语句是这样的:

    select name from user where id = ? 不管输入何种userID,他的sql语句都是这样的。


    这就得益于mybatis在底层实现时使用预编译语句。数据库在执行该语句时,直接使用预编译的语句,然后用传入的userId替换占位符?就去运行了。不存在先替换占位符?再进行编译的过程,因此SQL注入也就没有了生存的余地了。


    那么mybatis是如何做到sql预编译的呢?其实框架底层使用的正是PreparedStatement类。PreparedStaement类不但能够避免SQL注入,因为已经预编译,当N次执行同一条sql语句时,节约了(N-1)次的编译时间,从而能够提高效率。


    如果将上面的语句改成: SELECT name FROM user where id = ${userId} 当我们输入userId="34;drop table user;"后,打印的语句是这样的: select name from user where id = 34;drop table user; 此时,mybatis没有使用预编译语句,它会先进行字符串拼接再执行编译,这个过程正是SQL注入生效的过程。


    因此在编写mybatis的映射语句时,尽量采用“#{xxx}”这样的格式。若不得不使用“${xxx}”这样的参数,要手工地做好过滤工作,来防止sql注入攻击。

    回复

    使用道具 举报

    本版积分规则

    关闭

    站长推荐上一条 /1 下一条

    小黑屋|手机版|Archiver|51Testing软件测试网 ( 沪ICP备05003035号 关于我们

    GMT+8, 2024-3-29 00:07 , Processed in 0.060601 second(s), 23 queries .

    Powered by Discuz! X3.2

    © 2001-2024 Comsenz Inc.

    快速回复 返回顶部 返回列表