Oracle 使用PreparedStatement防止SQL注入
2017-10-31 21:20
686 查看
转自:http://blog.csdn.net/maxracer/article/details/6118036
一条效率差的sql语句,足以毁掉整个应用.
Statement是PreparedStatement的父接口,不进行预编译操作,减少了进行预编译的开销.单次运行PreparedStatement要比Statement要慢一些.
PreparedStatement可以实现Statement的所有功能,但是之所以叫它预编译指令,是因为在创建它的一个对象时可以给定具有一定格式的SQL字符串,然后用它的setXXX方法给指定的SQL语句以填空的方式赋值,具有这样的特性后,它在多次执行一条固定格式的字符串时就很方便,也更效率.不像Statement那样每次执行都要先编译字符串在执行SQL了.
PreparedStatement需要服务器端的支持来提高效率.比如在Oracle上就会有显著效果,而MySQL明确地说明了不支持PreparedStatement.
Oracle中会将所有的SQL语句先编译,叫做"执行计划",放在Oracle内部的一个特定的缓存中,每次遇到相同的SQL,就会先调用缓存中的,如果不预编译,每次都用Statement,那么每次都要编译,在缓冲中会有很多重复的"执行计划"影响数据库的性能.还有一点就是在使用setObject()的时候,记得一定要使用带targetSqlType参数的方法,来提高效率.
SQL注入攻击是利用设计上的漏洞,在目标服务器上运行SQL语句进行攻击,动态生成SQL语句时没有对用户输入的数据进行验证是SQL注入攻击得逞的主要原因.
对于JDBC而言,SQL注入攻击只对Statement有效,对PreparedStatement是无效的,这是因为PreparedStatement不允许在插入时改变查询的逻辑结构.绕过验证,但这种手段只对Statement有效,对PreparedStatement无效.
如果有一条SQL语句: "select * from 表 where 用户名 = '用户名'"
Statement的SQL语句是这样写的: "select * from 表 where 用户名 = '"+ 变量值 +"'"
PreparedStatement的SQL语句是这样写的: "select * from 表 where 用户名 = ?" 然后对应?赋值
这样我们就发现输入 "aa' or '1' = '1"
Statement是将这个和SQL语句做字符串连接到一起执行
PreparedStatement是将 "aa' or '1' = '1" 作为一个字符串赋值给?,做为"用户名"字段的对应值,显然这样SQL注入无从谈起了.
实现机制不同,注入只对SQL语句的准备(编译)过程有破坏作用,而PreparedStatement已经准备好了,执行阶段只是把输入串作为数据处理,不再需要对SQL语句进行解析,准备,因此也就避免了SQL注入问题.
一条效率差的sql语句,足以毁掉整个应用.
Statement是PreparedStatement的父接口,不进行预编译操作,减少了进行预编译的开销.单次运行PreparedStatement要比Statement要慢一些.
PreparedStatement可以实现Statement的所有功能,但是之所以叫它预编译指令,是因为在创建它的一个对象时可以给定具有一定格式的SQL字符串,然后用它的setXXX方法给指定的SQL语句以填空的方式赋值,具有这样的特性后,它在多次执行一条固定格式的字符串时就很方便,也更效率.不像Statement那样每次执行都要先编译字符串在执行SQL了.
PreparedStatement需要服务器端的支持来提高效率.比如在Oracle上就会有显著效果,而MySQL明确地说明了不支持PreparedStatement.
Oracle中会将所有的SQL语句先编译,叫做"执行计划",放在Oracle内部的一个特定的缓存中,每次遇到相同的SQL,就会先调用缓存中的,如果不预编译,每次都用Statement,那么每次都要编译,在缓冲中会有很多重复的"执行计划"影响数据库的性能.还有一点就是在使用setObject()的时候,记得一定要使用带targetSqlType参数的方法,来提高效率.
SQL注入攻击是利用设计上的漏洞,在目标服务器上运行SQL语句进行攻击,动态生成SQL语句时没有对用户输入的数据进行验证是SQL注入攻击得逞的主要原因.
对于JDBC而言,SQL注入攻击只对Statement有效,对PreparedStatement是无效的,这是因为PreparedStatement不允许在插入时改变查询的逻辑结构.绕过验证,但这种手段只对Statement有效,对PreparedStatement无效.
如果有一条SQL语句: "select * from 表 where 用户名 = '用户名'"
Statement的SQL语句是这样写的: "select * from 表 where 用户名 = '"+ 变量值 +"'"
PreparedStatement的SQL语句是这样写的: "select * from 表 where 用户名 = ?" 然后对应?赋值
这样我们就发现输入 "aa' or '1' = '1"
Statement是将这个和SQL语句做字符串连接到一起执行
PreparedStatement是将 "aa' or '1' = '1" 作为一个字符串赋值给?,做为"用户名"字段的对应值,显然这样SQL注入无从谈起了.
实现机制不同,注入只对SQL语句的准备(编译)过程有破坏作用,而PreparedStatement已经准备好了,执行阶段只是把输入串作为数据处理,不再需要对SQL语句进行解析,准备,因此也就避免了SQL注入问题.
相关文章推荐
- Oracle 使用PreparedStatement防止SQL注入
- Oracle 使用PreparedStatement防止SQL注入
- php 使用PDO,防止sql注入 简单说明
- 使用PreparedStatement防止SQL注入
- 关于利用oracle自带功能防止SQL注入的方法
- SQL注入的防止--使用preparedStatement
- JDBC:使用PreparedStatement防止SQL注入
- 使用参数化查询防止SQL注入漏洞
- 牛腩新闻发布系统笔记5:防止SQL注入以及实体类的使用
- Mysql使用SQL的安全问题,Mysql防止SQL注入
- HQL或SQL使用?带来的好处:减少SQL解析时间、降低内存开销、防止SQL注入
- 使用参数化查询防止SQL注入漏洞
- ASP.NET MVC 5使用Filter过滤Action参数防止sql注入,让你代码安全简洁
- 使用参数化查询防止SQL注入漏洞
- 9.4.1 使用参数来防止SQL注入
- 使用ADO.NET的参数集合来有效防止SQL注入漏洞 推荐
- 使用参数化查询防止SQL注入漏洞
- 使用参数化查询防止SQL注入漏洞
- 使用参数化查询防止SQL注入漏洞
- SQL中,like的SQL注入防止,使用预编译SQL(?)的写法