web开发中防止SQL注入

一、SQL注入简介

SQL注入是比较常见的网络攻击方式之一，它不是利用操作系统的BUG来实现攻击，而是针对程序员编写时的疏忽，通过SQL语句，实现无账号登录，甚至篡改数据库。

二、SQL注入攻击的总体思路

1.寻找到SQL注入的位置
2.判断服务器类型和后台数据库类型
3.针对不同的服务器和数据库特点进行SQL注入攻击

三、SQL注入攻击实例

比如在一个登录界面，要求输入用户名和密码：
可以这样输入实现免帐号登录：
用户名： or 1 = 1 –
密 码：
点登陆,如若没有做特殊处理,那么这个非法用户就很得意的登陆进去了.(当然现在的有些语言的数据库API已经处理了这些问题)
这是为什么呢? 下面我们分析一下：
从理论上说，后台认证程序中会有如下的SQL语句：

String sql = "select * from user_table where username=
' "+userName+" ' and password=' "+password+" '";

当输入了上面的用户名和密码，上面的SQL语句变成：
SELECT * FROM user_table WHERE username=
'’or 1 = 1 -- and password='’

分析SQL语句：
条件后面username=”or 1=1 用户名等于 ” 或1=1 那么这个条件一定会成功；

然后后面加两个-，这意味着注释，它将后面的语句注释，让他们不起作用，这样语句永远都能正确执行，用户轻易骗过系统，获取合法身份。
这还是比较温柔的，如果是执行
SELECT * FROM user_table WHERE
username='' ;DROP DATABASE (DB Name) --' and password=''
其后果可想而知…

四、如何防御SQL注入

注意：但凡有SQL注入漏洞的程序，都是因为程序要接受来自客户端用户输入的变量或URL传递的参数，并且这个变量或参数是组成SQL语句的一部分，
对于用户输入的内容或传递的参数，我们应该要时刻保持警惕，这是安全领域里的「外部数据不可信任」的原则，纵观Web安全领域的各种攻击方式，
大多数都是因为开发者违反了这个原则而导致的，所以自然能想到的，就是从变量的检测、过滤、验证下手，确保变量是开发者所预想的。

1、检查变量数据类型和格式

如果你的SQL语句是类似where id={$id}这种形式，数据库里所有的id都是数字，那么就应该在SQL被执行前，检查确保变量id是int类型；如果是接受邮箱，那就应该检查并严格确保变量一定是邮箱的格式，其他的类型比如日期、时间等也是一个道理。总结起来：只要是有固定格式的变量，在SQL语句执行前，应该严格按照固定格式去检查，确保变量是我们预想的格式，这样很大程度上可以避免SQL注入攻击。
比如，我们前面接受username参数例子中，我们的产品设计应该是在用户注册的一开始，就有一个用户名的规则，比如5-20个字符，只能由大小写字母、数字以及一些安全的符号组成，不包含特殊字符。此时我们应该有一个check_username的函数来进行统一的检查。不过，仍然有很多例外情况并不能应用到这一准则，比如文章发布系统，评论系统等必须要允许用户提交任意字符串的场景，这就需要采用过滤等其他方案了。

2、过滤特殊符号

对于无法确定固定格式的变量，一定要进行特殊符号过滤或转义处理。

3、绑定变量，使用预编译语句

MySQL的mysqli驱动提供了预编译语句的支持，不同的程序语言，都分别有使用预编译语句的方法

实际上，绑定变量使用预编译语句是预防SQL注入的最佳方式，使用预编译的SQL语句语义不会发生改变，在SQL语句中，变量用问号?表示，黑客即使本事再大，也无法改变SQL语句的结构。

MySQL预处理是怎么防止的呢？
其实是因为SQL语句在程序运行前已经进行了预编译，在程序运行时第一次操作数据库之前，SQL语句已经被数据库分析，编译和优化，对应的执行计划也会缓存下来并允许数据库已参数化的形式进行查询，当运行时动态地把参数传给PreprareStatement时，即使参数里有敏感字符如 or '1=1’也数据库会作为一个参数一个字段的属性值来处理而不会作为一个SQL指令，如此，就起到了SQL注入的作用了！

具体实例，例如这条SQL：

SELECT * From table_name WHERE name=’’ and password=’’ and corporate=’’ or 1=1-’

开启预编译执行SQL的时候，则不会这么处理。会当成一个属性值。什么意思。随便你怎么加，都是一个值。也就是说，如果中间有产生歧义的，都将被处理掉，最后执行相当于是这样：

SELECT * From table_name WHERE name=’’ and password=’’ and corporate="'or 1=1–"

这个大家应该看的懂吧，输入的一串，都被揉在一起，作一个参数，而不是SQL。

小结：

1.使用预编译绑定变量的SQL语句

2.严格加密处理用户的机密信息，登录名、密码等数据加密保存
3.不要随意开启生产环境中的错误显示，避免暴露数据库信息
4.使用正则表达式过滤传入的参数
5.字符串过滤
6.检查是否包函非法字符

7.不要使用动态拼装sql，可以直接使用存储过程进行数据查询存取

总的来说，防范一般的SQL注入只要在代码规范上下点功夫就能预防。