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 id="getNameByUserId" resultType="String"> SELECT name FROM user where id = #{userId} </select>
对应的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 id="getNameByUserId" resultType="String"> SELECT name FROM user where id = ${userId} </select>
当我们输入userId="34;drop table user;"后,打印的语句是这样的:
select name from user where id = 34;drop table user;
此时,mybatis没有使用预编译语句,它会先进行字符串拼接再执行编译,这个过程正是SQL注入生效的过程。
因此在编写mybatis的映射语句时,尽量采用“#{xxx}”这样的格式。若不得不使用“${xxx}”这样的参数,要手工地做好过滤工作,来防止sql注入攻击。
总结
以上所述是小编给大家介绍的mybatis防止SQL注入的方法实例详解,希望对大家有所帮助,如果大家有任何疑问请给我留言,小编会及时回复大家的。在此也非常感谢大家对小牛知识库网站的支持!
本文向大家介绍Mybatis防止sql注入的实例,包括了Mybatis防止sql注入的实例的使用技巧和注意事项,需要的朋友参考一下 sql注入大家都不陌生,是一种常见的攻击方式,攻击者在界面的表单信息或url上输入一些奇怪的sql片段,例如“or ‘1'='1'”这样的语句,有可能入侵参数校验不足的应用程序。所以在我们的应用中需要做一些工作,来防备这样的攻击方式。在一些安全性很高的应用中,比如银行
本文向大家介绍php防止sql注入的方法详解,包括了php防止sql注入的方法详解的使用技巧和注意事项,需要的朋友参考一下 一、什么是SQL注入式攻击? 所谓SQL注入式攻击,就是攻击者把SQL命令插入到Web表单的输入域或页面请求的查询字符串,欺骗服务器执行恶意的SQL命令。在某些表单中,用户输入的内容直接用来构造(或者影响)动态SQL命令,或作为存储过程的输入参数,这类表单特别容易受到SQ
我在mybatis查询中使用“$”表示法: order参数可以是类似于“id desc”的东西,我需要担心这里的sql注入吗?我们知道mybatis使用,如果mybatis针对“select”语句调用,或者jdbc驱动程序实现不允许在一次调用中使用多个语句,那么sql注入是不可能的,对吗? 这是否足以检查参数有sql分隔符?
本文向大家介绍PHP中防止SQL注入方法详解,包括了PHP中防止SQL注入方法详解的使用技巧和注意事项,需要的朋友参考一下 问题描述: 如果用户输入的数据在未经处理的情况下插入到一条SQL查询语句,那么应用将很可能遭受到SQL注入攻击,正如下面的例子: 因为用户的输入可能是这样的: 那么SQL查询将变成如下: 应该采取哪些有效的方法来防止SQL注入? 最佳回答(来自Theo):
在中是否存在防止SQL注入的好方法? 我将此方法用于。实际上,我在查询中使用用户给出的字符串参数。 有什么想法吗?
本文向大家介绍Pyhton中防止SQL注入的方法,包括了Pyhton中防止SQL注入的方法的使用技巧和注意事项,需要的朋友参考一下 注意,上面的SQL字符串与后面的tuple之间的分隔符是逗号,平时拼写SQL用的是%。 如果按照以下写法,是容易产生SQL注入的: 这个和PHP里的PDO是类似的,原理同MySQL Prepared Statements。 Python Using the Pytho