SQL 注入有病，安全专家有何良方？（sql server数据库教程）

SQL 注入有病，安全专家有何良方？（sql server数据库教程）

SQL 注入攻击现状

香港某航空公司 SQL 注入（涉及156万乘客信息/268万机票信息/八千多员工信息）中石化车 e 族 APP 存在 SQL 注入漏洞之一（可跨9个库）海尔旗下日日顺商城 SQL 注入可导致300万会员信息泄漏邯郸市工信办漏洞危及大量个人信息以及金额等数据，百万用户数据泄露中国电信翼支付某系统漏洞泄露400万用户信息、支付交易明细信息（超市购物/加油站加油）以及充值等数据

SQL 注入漏洞大面积的存在：当今系统越来越复杂，发布节奏越来越快，遗漏代码非常多。很多公司对安全不够重视，带病上线是非常常见的事情。关系型数据库是现在最流行的存储方式，大多数有价值的信息都存在数据库里。这对黑客的诱惑力太大了。攻击方式并不难找，网络有大量的 SQL 注入攻击的方法和手段。黑客很容易找到攻击的方式。

SQL 注入的原理

SQL 注入：就是通过把 SQL 命令插入到 Web 表单提交或输入域名或页面请求的查询字符串里，最终达到欺骗服务器执行恶意的 SQL 命令。

具体来说，它是利用现有应用程序，将（恶意）的 SQL 命令注入到后台数据库引擎执行的能力，它可以通过在 Web 表单输入（恶意）SQL 语句得到一个存在安全漏洞的网站的数据库信息，而不按照设计者的意图执行 SQL 语句。

首先让我们了解下什么时候可能发生 SQL 注入：

假设我们在浏览器中输入 URL: sample.com，由于它只是对页面的简单请求无需对数据库进行动态请求，所以它不存在 SQL 注入，当我们输入 sample.com?testid=23 时，我们在 URL 中传递了变量 testid，并且提供值为23，由于它是对数据库进行动态查询的请求（其中 ?testid＝23 表示数据库查询变量），所以我们可以在该 URL 中嵌入了恶意 SQL 语句。

具体的例子和详细的原理就不在这里赘述了，有兴趣的同学可以去谷歌或者百度搜索，上面会有大量的例子和攻击方式。

最主要的保护方式有以下几点：

使用 Prepared Statements（参数查询）来代替 Statements — 这要求所有数据库开发人员在开发 SQL 查询语句时将代码和数据分开，先定义查询语句的结构，将数据通过参数的方式出入，这样输入的参数将不会当作 SQL 命令来执行，基本上能避免 SQL 注入的攻击。使用存储过程来操作数据库 — 所有的存储过程都存放在数据库里面，应用程序调用存储过程来查询数据。转义用户输入的所有特殊字符 – 永远不要信任用户的输入，要对用户的输入进行校验，可以通过正则表达式，或限制长度，对单引号和双"-"进行转换等。这些在一定程度可以缓解SQL注入。

还有些辅助的方法：

以最低权限的数据库连接，为每个应用使用单独的权限与有限的数据库连接。不要把机密信息明文存放，加密或者 hash 掉密码和敏感的信息。应用的异常信息应该给出尽可能少的提示，最好使用自定义的错误信息对原始错误信息进行包装，把异常信息存放在独立的表中。

代码量巨大，完全修复这些漏洞要花费巨大的人力和时间，在大多数公司基本不可能实现。扫描工具漏洞更新比较滞后，很多漏洞都不能得到及时更新。即使完全修复，上线后也会有新的漏洞产生。一般项目都会大量使用第三方 API 和框架，这些外部程序的漏洞是不可修改的，即使提供商承诺修改也需要比较长得时间。