本文共 1000 字,大约阅读时间需要 3 分钟。
SQL注入的例子:
防止SQL注入一般从两个方面下手,一个是数据库方面,一个是代码方面。
MyBatis使用#{}就可以防止SQL注入,具体怎么做可以看。这是因为使用#{}语法时,MyBatis会自动生成PreparedStatement,使用参数绑定(?)的方式来设置值。这也就是利用数据库提供的SQL语句的预编译、查询参数绑定功能,在SQL语句中放置占位符?,然后将带有占位符的SQL语句传给数据库编译,执行的时候才将用户输入的数据作为执行参数传给编译好的SQL语句。这么一来就使得SQL语句不再需要拼接,用户输入的数据也不可能被编译,不会越权变成代码。
补充:所谓的预编译,就是把SQL语句放到数据库中进行编译,并存储在PreparedStatement对象中,以后需要使用相同的SQL语句(参数值可能不同),可以直接使用该对象,高效地多次执行。
另外,PreparedStatement无法防止模糊查询引起的服务器资源消耗,比如在传入的参数中加上%,导致用户可能查到不应该查到的信息。如 所示。不过,一般对没必要进行模糊查询的地方严格禁止模糊查询,对需要模糊查询的地方则在代码中固定加上%号,这样当用户传进来%号时就可以使SQL语句无法执行。
当使用${}时,MyBatis会直接注入原始字符串,相当于拼接字符串(运行时才编译SQL语句),因此会导致SQL注入。对于这种情形,我们往往需要自行过滤输入。通常采用的方法有:1)在XML配置文件中使用 if 标签进行判断;2)在业务代码中限制相关字符串的值
SQL注入并不是SQL语言的问题,也不可能在数据库内部实现中解决。SQL注入产生的原因,和XSS或其他攻击方法类似,都是因为未经检查或未经充分检查的用户输入数据,意外变成代码被执行所造成的。也就是说,SQL注入就是用户输入的数据,在拼接SQL语句的过程中,超越了数据本身,变成了SQL语句查询逻辑的一部分,然后被拼接出来的SQL语句被数据库执行,产生了预期之外的动作。
可以认为,没有运行时编译,就没有SQL注入,反之亦然。我们通常需要尽量减少拼接SQL语句的操作,使用#{}来定义占位符从而避免拼接字符串。而当需要采用${}等运行时编译功能时,往往需要采用一些条件过滤的方式来防止SQL注入。
参考:
转载地址:http://kbnii.baihongyu.com/