SQL注入其实很简单，别一不留神就被利用了

SQL注入这个词相信大家应该都不陌生，而且每年都会有这样子的事情发生，下面我先带大家回忆11年两期起比较经典的案例事件：

1、SONY索尼事件
2011年4月，著名的匿名者组织Anonymous注入SONY一个网站，一星期后才被发现7千万的用户个人信息，其中包括姓名、地址、E-mail、出生日期、用户名、密码以及购买记录的数据信息，随后的一些其他服务器也被相继攻破

2、CSDN数据泄露门
2011年底，国内各大网站被爆出“密码泄露门”，最先公布的是著名技术网站CSDN600万账户和密码泄露事件，网站由于存在SQL注入漏洞被利用并下载用户数据库，同时令人不解的是，网站对用户的信息储存竟然是明文

什么是sql注入

SQL注入指的是发生在Web应用对后台数据库查询语句处理存在的安全漏洞，简单的说，就是在输入字符串中嵌入SQL指令，在设计程序中忽略了对特殊字符串的检查，这些嵌入的指令便会被误认为正常的SQL指令，在数据库中执行，因此可以对后台数据库进行查看等工作，甚至破快后台数据库造成严重后果。
目前SQL注入大致分为普通注入和盲注

• 普通注入：根据后台数据库提示有价值的错误信息进行注入
• 盲注：有经验的管理员在给出错误页面时，没有提供详细的错误信息。测试者需要运用脚本通过仅有的判断信息(比如时间差)对表中的每一个字段进行探测，从而实现注入的技术。
  (盲注的难度较大，但注入测试中经常会遇到)

SQL注入普遍的思路

• 发现SQL注入位置
• 判断后台数据库类型
• 确定XP_CMDSHELL可执行情况
• 发现WEB虚拟目录
• 上传ASP脚本
• 得到管理员权限

SQL注入技术

• 强制产生错误
• 采用非主流通道技术
• 使用特殊的字符
• 使用条件语句
• 利用存储过程
• 避开输入过滤技术
• 推断技术

普通注入示例

以著名的IBM公司所提供的SQL注入测试平台

我们在这个网站上发现了一个登录的页面，现在我们在表单中的Username中输入“admin'”，Password中输入一样的字段

点击‘Login’登录按钮后，我们得到了一个报错的页面，根据提示“Syntax error (missing operator) in query expression 'username = 'admin'' AND password = 'admin'''.”我们可以猜测到大概的SQL语句应该是“select * from [users] where username=? and password=?”

我们返回登录页面在Username和Password中输入“admin' or '1”然后再点击登录，我们就能意外的进入到登录页面之后了

是不是还是一脸懵，现在我们来解释一下为什么会这样，之所以能够登陆成功，是因为SQL的语句变成一下的语句：
select * from [users] where username= 'admin' or '1' and password='admin' or '1'
根据SQL中逻辑运算的优先级，or低于and，最后的or ‘1’永远成立，所以该条件表达式结果为True，此语句同等于下面的这条语句
select * from [users]

SQLmap工具注入示例

这个页面通过了一次提交之后，我们得到了几个信息，一个是提交的地址，还有就是cookie值，我们通过这几个信息使用sqlmap工具项检测一下有没有sql的注入点

从检测的结果中，我们看到了包含错误的SQL注入点，以及UNION查询注入点，此外，还进一步的探测到了数据库的版本是MySQL5.0的，Web应用平台是PHP5.3.2/Apache2.2.14

使用SQLmap的“--dbs”选项，就可以根据所识别的不同数据库管理平台类型来探测包含的数据库名称，除了发现MySQL默认的系统数据库information_schema之外，我们还发现了Web应用的数据库dvwa

使用“-D dvwa --tables”选项指定了数据库，然后获得了此数据库下的所有表，竟然表我们都能看到了，接下来我们来看看表里得到内容吧

加上“-D dvwa --tables -T users --columns --dump”选项前面的-D选项指定数据库，后面-T指定表，最后我们看到了表中的内容，从中我们看到了一个admin的账户，将password放到在线解密MD5的网站上，我们的到密码就是admin，拿着这个账号密码，轻松的进入到后台中

SQL注入如何防范

通过一开始的两起案件和后面我所示范的简单注入，相信大家应该知道SQL的注入该有多危险了吧，下面给大家普及几点防范SQL注入的方法：

输入验证

检查用户输入的合法性，尽量的限制用户输入特殊的符号，确信输入的内容只包含合法的数据。数据检查应当在客户端和服务器端都执行之所以要执行服务器端验证，是为了弥补客户端验证机制脆弱的安全性。

错误消息处理

防范SQL注入，还要避免出现一些详细的错误消息，因为可以利用这些消息。要使用一种标准的输入确认机制来验证所有的输入数据的长度、类型、语句、企业规则等。

加密处理

在一开始的CDNS例子中没有加密的数据就直接被利用了，但是加密了就不一定会解密成功，尽量不要用一些常见的加密算法，就算用也要使用32位以上的加密算法，将用户登录名称、密码等数据加密保存。加密用户输入的数据，然后再将它与数据库中保存的数据比较，这相当于对用户输入的数据进行了“消毒”处理，用户输入的数据不再对数据库有任何特殊的意义，从而也就防止了注入SQL命令。

存储过程来执行所有的查询

SQL参数的传递方式将防止利用单引号和连字符实施注入。此外，它还使得数据库权限可以限制到只允许特定的存储过程执行，所有的用户输入必须遵从被调用的存储过程的安全上下文，这样就很难再发生注入式了。