解决SQL注入漏洞的另类思路

关于网络安全，有一句话是这么说的：任何接收到的参数都有可能是不安全！

SQL注入漏洞，作为网络安全中比较常见的一种漏洞，一旦发生安全事件，轻则导致网站被篡改，重则导致整台服务器被拿下。

与一般程序员只拿SQL语句进行增删改查不同的是，一旦黑客找到可以执行SQL语句的注入点，那么他一定会测试执行最高权限的语句；毕竟用SQL语句来提权去控制整台服务器也不是没有可能，因为SQL语言真的很强大。

纵观所有的SQL注入漏洞，大多是因为对接收到的参数过滤不严格造成的；目前来看，SQL注入漏洞的解决方案也是多种多样，比如：代码端过滤、购买WAF、使用一些中间件等；不过对于我们普通程序员来说，后两种都不太现实，毕竟WAF费用不菲，服务器操作权限有时候也不一定能拿到。所以我们今天主要说一说使用代码端过滤的方法来解决SQL注入漏洞。

代码端过滤，通常的解决方案是把一些关键词（譬如：SELECT、DELETE、CREATE、ALTER、DROP、TRUNCATE等）进行过滤和拦截，来保证接收参数的安全。而事实上，网络安全是一个动态变化的过程，谁都无法保证下一秒会不会出什么新的漏洞，需要屏蔽什么新的关键词。但对于程序员来说，自己写的代码需要接收什么类型的参数，应该再清楚不过了，所以我们只需要限定仅允许接收我们指定类型的参数即可。

PHP示例代码（只允许接收数字、字母、数字+字母和字符串“abc”）：

<a href="?g=1&gg=aa&ggg=333&gggg=abc">测试一下[通过]</a><br /><a href="?g=1&gg=aa&ggg=333&gggg=abc-d">测试一下[不通过]</a><br />
<?php
$safe_str = "^[0-9]+$|^[A-Za-z0-9]+$|^abc$";

$get_n = count($_GET);
$safe_n = 0;
foreach($_GET as $key=>$value) {
  echo preg_match("/".$safe_str."/is",$value);
  echo '-',$value;
  echo '<br />';
  $safe_n = preg_match("/".$safe_str."/is",$value) + $safe_n;
}
if($safe_n !== $get_n){
  die('参数不合法！');
}
?>

Post、Cookie、Pathinfo等写法同理。