SQL注入场景与防范

一、SQL注入场景：SQL注入攻击是未将代码与数据进行严格的隔离，导致在读取用户数据的时候，错误的吧数据作为代码的一部分执行，从而导致一些安全问题。

1. 通过url地址：

    当用户发送GET请求：         http://www.xxx.com/news.jsp?id=1     这是一个新闻详情页面，会显示出新闻的title和content，程序内部会接收这个id参数传递给SQL语句，SQL如下：         SELECT title,content FROM news WHERE id = 1     这是SQL的原义,也是程序员想要得到的结果,但是如果用户改变了id的内容，修改成如下：         http://www.jd.com/news.jsp?id=1 and 1=2 UNION SELECT userna-me, password FROM admin     此时内部程序执行的SQL语句为：         SELECT title,content FROM news WHERE id = 1 and 1=2 UNION SELECT username, password FROM admin

    这条SQL的原义就会被改变，导致将管理员数据表中的用户名显示在页面title位置，密码显示在页面content位置，攻击成功。

2. sql注入攻击     妈的，太tm血腥了，，，，。

    转载地址：  http://www.exehack.net/4352.html 

二、SQL注入的防范

1.过滤用户输入的参数中的特殊字符，从而降低被SQL注入的风险。

        例如：update table set listone1 = “# -- !#(@ "where 这样的内容，由于业务代码未对危险字符串 “# --" 进行转义，导致where后边的信息被注释；

2.禁止通过字符串拼接的SQL语句，严格使用参数绑定传入的SQL参数。

3.合理使用数据库访问框架提供的防范注入机制。

    例如：SQL的执行均采用‘预处理’；

 （1）？形式：

    preparedStatement()—— —— 预编译，可防止SQL注入；

（2）Mybatis框架下的SQL注入

    ①（ like 模糊查询）：

按照新闻标题对新闻进行模糊查询，可将SQL查询语句设计如下：

        select * from news where tile like concat(‘%’,#{title}, ‘%’)，采用预编译机制，避免了SQL语句拼接的问题，从根源上防止了SQL注入漏洞的产生。

    ② in 参数之后的注入修复

在对新闻进行同条件多值查询的时候，可使用Mybatis自带循环指令解决SQL语句动态拼接的问题： select * from news where id in

#{item}

    ③order by 注入修复（# → $）

预编译机制只能处理查询参数，其他地方还需要研发人员根据具体情况来解决。如前面提到的排序情景： Select * from news where title =‘京东’ order by #{time} asc，这里time不是查询参数，无法使用预编译机制，只能这样拼接：Select * from news where title =‘京东’ order by ${time} asc 。

针对这种情况研发人员可以在java层面做映射来进行解决。如当存在发布时间time和点击量click两种排序选择时，我们可以限制用户只能输入1和2。当用户输入1时，我们在代码层面将其映射为time，当用户输入2时，将其映射为click。而当用户输入1和2之外的其他内容时，我们可以将其转换为默认排序选择time(或者click)。