SQL注入
SQL注入是一种常见的Web安全漏洞，虽然数据库经过了长年的发展已经有了较为完备的防注入能力，但由于开发人员的疏忽大意而产生SQL注入的情况依然常见。
什么是SQL注入本文不多做说明，简单说就是利用客户端的输入参数来影响后台对SQL语句的组装。
比如常见的用户登录界面，需要用户输入用户名username和密码password，客户端将这两个字段传到后台后，后台组装SQL语句来判断用户输入的用户名和密码是否匹配来判断是否允许用户登录（这里暂不考虑对密码的加密），比如组装SQL语句如下：
SELECT uid,username FROM user_table WHERE username='cloudox' AND password='123456';
如果此时一个假用户在用户名输入框输入“cloudox' AND 1=1-- ”，在密码框随意输入字符串“111”，那么此时后台组装SQL就变成了：
SELECT uid,username FROM user_table WHERE username='cloudox' AND 1=1-- ' AND password='111';
由于在Mysql中，连续两个减号“--”表示忽略后续的语句内容，因此上述查询语句到“1=1”就结束了，因为“1=1”是永远成立的，所以这条语句不需要判断密码是否正确，就能够通过登录验证，拿到用户信息。
再比如我将用户名输入为“cloudox';SHOW TABLES-- ”，此时组装SQL变为：
SELECT uid,username FROM user_table WHERE username='cloudox';SHOW TABLES-- ;
那我不但免密登录了，还能得到后台数据库的具体各表名（当然这是在后台傻傻把所有数据回传的理想情况）。
想详细了解的可以参考这篇文章：https://www.jianshu.com/p/078df7a35671，有很详细的说明以及众多示例。
防范手段
1、参数检查
对于用户输入传入的参数，做严格的检查。该检查既包括类型检查，也包括参数的范围检查。
比如如果要求是数值型参数，那就要判断数值是否为数值型，如果不是那就拒绝。
对于一些参数格式或者范围固定的参数，可以做严格的检验，比如邮箱格式、手机号格式、年龄范围等。如果不是期望让用户有足够的放飞自由度，那就可以做严格的检查来排除SQL注入的可能。
2、特殊字符转义
不是所有业务场景都有严格的参数格式或范围要求，那此时总不能不允许用户将一些特殊的字符作为参数传输，比如你不能禁止用户将“1=1”作为用户名。
如果接收的参数类型为字符型，此时就要考虑对一些特殊字符做转义处理：单引号、双引号、反斜杠、回车换行等，将这些字符转义后，可以使其不被当成SQL语句的一部分，而只是纯粹的参数处理，比如上面示例中要做到避开密码识别，就需要在传入的用户名中包含单引号来结束对用户名参数的识别。此时如果能将该单引号转义不当做单引号处理，那么整体会被当做参数，从而就避免了注入。
Mysql本身提供了一个mysql_real_escape_string()函数来对特殊字符做转义。一般的Mysql库函数应该都提供基于它的上层函数来处理你的字符型参数，建议好好利用。但要注意只对参数本身做转义，而不要整个语句一起转义了。
3、预编译实现参数化查询
使用特殊字符转义可以有效避免大多数注入情况，但并不是全部，总会存在一些特殊的情况照顾不到。预编译（Prepared Statement）就是一个更加完善且一劳永逸的方法。
使用预编译实际上是把SQL语句的组装分为了两部分，原本的除参数外的结构部分会事先编译好，传入的参数只能当做参数来处理，不会被当做语句的一部分来对待。这就从根源上避免了SQL注入。
比如上面例子中，username字段不管怎么输入，就算是“cloudox' AND 1=1-- ”，也一定被当成参数来处理，不会影响到查询语句的结构，即不会注释掉后续部分，整个输入内容会被当做整体的用户名来处理。
目前大部分语言都提供了预编译的支持，比如Java的PreparedStatement()、PHP的prepare()和bind_param()、Python的支持等。C++本身没有提供预编译函数，但Mysql库有提供：Using Prepared Statements。
使用预编译是目前最佳的防注入方式了。
4、DB账户权限隔离
在防范的同时，也要做最坏的准备，万一那个地方真的有漏洞被注入了，尽量细粒度化DB账户的权限，各业务的账号只能接触各业务库表，根据业务场景做读写分离等。都能在已经发生注入的情况下尽量减少损失。
此外，最好准备一套漏洞扫描策略，对业务接口做漏洞扫描，确保万无一失。
查看作者首页