PHP代码审计学习（4）——SQL漏洞

前言

　　SQL注入原理之前已经研究过了，感兴趣的师傅可以去看一下SQL注入天书，这里不详细介绍了，简单讲一下再代码审计中容易出现的SQL注入类型，只是简单归纳一下书里的知识

SQL注入位置

　　登陆页面、获取HTTP头处理函数、订单处理、查询搜索，用户管理操作页面等，登陆页面大多发生在HTTP头的client-ip和x-forward-for,一般用于记录IP地址，在订单页面因为要和很多页面交互往往很复杂，也常常出现二次注入

代码审计基本注入类型

　　普通注入

　　　　字符型 1' and '1' = '1'  、数字型 1 and 1=1

　　宽字节注入

　　　　PHP连接数据库时候，当设置 set character_set_chient=gbk 时候或当我们看到的变量有时会被addslashes函数过滤，会导致编码注入问题。如果数据库是用GBK编码处理参数的，我们可以在参数中带入%df%27 '或%df '，编码为%df%5c%27，%df%57会被认为是一个中文“運”，这样单引号之前的转义符号“”就被吃调了，变成了“運’”转义失败，mysql在解读时会无视新字节，使得我们的单引号 ' 生效。

　　　　在SQLMAP加脚本参数，或者直接在后边加%df'直接跑

--tamper unmagicquotes --dbs --hex

　　　　设置SET NAMES 'gbk'也一样有漏洞出现,只是不过多干两步

SET
character_set_connection='gbk',
character_set_results='gbk',
character_set_client=gbk

　　

　　　　代码审计的时候查找关键字

　　　　　　SET NAMES

　　　　　　character_set_client=gbk

　　　　　　mysql_set_charset('gbk')

　　二次注入

　　　　传入数据库再取出调用的情况下就可能会造成漏洞，现在web程序经常会使用addslashes()，mysql_real_escape_string()，mysql_escape_string()或开启GPC的方式转义特殊字符。如果某处使用了urldecode或rawurldecode,就有可能出现二次编码注入，比如我们提交?id=1%2527,第一次解码后是?id=1%27，因为%25解码后是%，然后1%27就存入了数据库，再调用解码的时候，1%27就变成了1'，传入的时候没有单引号，调用的时候单引号就出现了引发注入

 　　　　在代码审计中我们就可以搜索urldecode或rawurldecode来查找有没有二次注入的漏洞