SQL注入的四种防御方法总结
前言
最近了解到安全公司的面试中都问到了很多关于SQL注入的一些原理和注入类型的问题,甚至是SQL注入的防御方法。SQL注入真的算是web漏洞中的元老了,著名且危害性极大。下面这里就简单的分享一下我总结的四种SQL注入防御手段,加深理解,方便下次遇到这种问题时可以直接拿来使用。(主要是怕面试中脑壳打铁,这种情况太常见了)
SQL注入占我们渗透学习中极大地一部分,拥有这很重要的地位。随着防御手段的不段深入,市面上存在SQL注入的网站的确少之又少了,但不能说是没有。在我看来,学习SQL注入的目的并不只是学习针对这种方法,而是一类方法,包括他的思想,思路和奇淫技巧,简单点说就是举一反三。学到现在发现好像越向后面学其他漏洞,方法思路都大体一致,比如字符串拼接,构造闭合语句,函数替代等等。
好了,说了这么多,现在我们步入正题吧!
我们简单理解SQL注入就是在人为可以构造参数的地方加入一些非法敏感语句,绕过后端的处理,并带入到数据库中执行,然后返回敏感数据的过程。
限制数据类型
在传入参数的地方限制参数的类型,比如整型 Integer,随后加入函数判断,如is_numeric($_GET[‘id’]) 只有当get到的id为数字或者数字字符时才能执行下一步,限制了字字符自然就限制了注入,毕竟构造参数怎么可能不传入字符。但这种方法存在一定的限制,只能在特定的页面才能使用,一般大部分都是要求我们传入的字符串,但可以很大程度限制整型注入的情况。(针对此函数也是有一定绕过手段,比如转为十六进制)
正则表达式匹配传入参数
相信对于正则表达式大家都不陌生了,几乎在过滤比较严格的地方都有正则表达式。(后面我也会写一篇关于使用正则表达式的文章,包括基础的使用和绕过)。这里简单解读一下这段正则表达式:
$id=$_POST['id'];
if (preg_match('/and|select|insert|insert|update|[A-Za-z]|/d+:/i', $id)) {
die('stop hacking!');
} else {
echo 'good';
}
preg_match() 函数匹配传入的id值,
/ 作为正则的起始标识符
| 代表或
[A-Za-z] 表示匹配参数中是否存在大小写的26个字符
/d 匹配是否存在数字
+匹配一次或多次
/i 不区分大小写
像下面这句:
?id=1’ union select 1,2# 因为匹配到union select,输出 stop hacking!
正则表达式也具有一定危险性,在SQL注入绕过waf中谈到过,正则表达式匹配非常消耗性能,因此攻击时可以构造大量的正常语句‘骗’过服务器,当后台对数据的处理达到最大限制时就会放弃匹配后面我们构造的非法语句,从而略过这个数据包。
函数过滤转义
在php中最基本的就是自带的magic_quotes_gpc函数,用于处理 ’ " 符号加上/ 防止转义, 比如:
?id=1' and 1=1# ===> ?id=1/' and 1=1#
另外还有addslashes(),也具有相同的效果。
像前面提到的**preg_match()**函数结合正则表达式或者黑名单也具有预防效果。
小tips:默认情况下,PHP 指令 magic_quotes_gpc 为 on,对所有的 GET、POST 和 COOKIE 数据自动运行 addslashes()。不要对已经被 magic_quotes_gpc 转义过的字符串使用 addslashes(),因为这样会导致双层转义。遇到这种情况时可以使用函数 get_magic_quotes_gpc() 进行检测。
mysql_escape_string($string):用反斜杠转义字符串中的特殊字符,用于mysql_query()查询。
mysql_real_escape_string() 函数转义 SQL 语句中使用的字符串中的特殊字符。
转义的符号包括 \x00 \n \r \ ’ " \x1a
预编译语句
预编译语句对现在的程序员来说基本都会去设计使用的方法,保障数据库的安全。一般来说,防御SQL注入的最佳方式就是使用预编译语句,绑定变量。
String query="select password from users where username='?' ";
下面讲一下什么叫预编译:使用预编译相当于是将数据于代码分离的方式,把传入的参数绑定为一个变量,用?表示,攻击者无法改变SQL的结构,在这个例子中,即使攻击者插入类似 admin’ or 1=1# 的字符串,如果不做处理直接带入查询,那么query则变成了
query="select password from users where username='admin' or 1=1 ";
闭合了后面的引号,从而执行了恶意代码。而预编译则是将传入的 admin’ or 1=1# 当做纯字符串的形式作为username执行,避免了上面说到的SQL语句中的拼接闭合查询语句等过程,可以理解为字符串与sql语句的关系区分开,username此时作为字符串不会被当做之前的SQL语句被带入数据库执行,避免了类似sql语句拼接、闭合等非法操作。就相当于拿着这个字符串去数据库中找有没有这个东西一样。并且使用预编译的SQL语句,SQL语句的语义不会发生改变。
下面给个php绑定变量的事例:
$query="INSERT INTO myCity (Name,CountryCode,District) VALUES (?,?,?)";
$stmt=$mysqli->prepare($query);
$stmt->bind_param("sss",$val1,$val2,$val3);
$val1="Stuttgart";
$val2="DEU";
$val3="Baden";
//execute the statement
$stmt->execute();
以上谈到的四种方法都是一些基本方法,具体怎么实现防御还要看怎么去设计。说到预编译语句是最佳方式,并不是说只是使用这一种方法就能够防止SQL注入,而实际上预编译也存在注入绕过的问题,并且也不是所有的地方都能够使用预编译语句。最佳的方式应该是多种方法结合,使用预编译的同时还要加上其他函数过滤,正则匹配等,更多的还有根据实际情况自定义函数确保安全。
总结
到此这篇关于SQL注入的四种防御方法总结的文章就介绍到这了,更多相关SQL注入防御方法内容请搜索我们以前的文章或继续浏览下面的相关文章希望大家以后多多支持我们!
免责声明:
① 本站未注明“稿件来源”的信息均来自网络整理。其文字、图片和音视频稿件的所属权归原作者所有。本站收集整理出于非商业性的教育和科研之目的,并不意味着本站赞同其观点或证实其内容的真实性。仅作为临时的测试数据,供内部测试之用。本站并未授权任何人以任何方式主动获取本站任何信息。
② 本站未注明“稿件来源”的临时测试数据将在测试完成后最终做删除处理。有问题或投稿请发送至: 邮箱/279061341@qq.com QQ/279061341