【web安全】- sql注入的实战与防范

编	写:袁	亮
时	间:2014-10-24
说	明:sql注入的实战与防范

一、对m端知识目录下的程序进行注入:
	1、结果:通过sqlmap将整个baike的数据库down下来了
	2、代码有以下问题:
		2.1 程序设置了报错开启输出
		2.2 参数没有做过滤,大部分都是整型,intval下其实就可以解决
		2.3 搜索功能的搜索值也没有做任何处理
		2.4 妈妈经的后台,sadmin/sub下的所有程序都没有验证登陆
		2.5 妈妈经后台的处理程序,对任何外部数据都没有处理,后台要是沦陷,轻易可以住人做任何事情
	3、处理结果:
		已经反馈给戴维杨,做相应的升级
二、英皇下载漏洞以及sql住人漏洞的利用:
	1、结果:根据乌云上爆出的漏洞,将英皇那台服务器上的代码基本上都down下来了
		根据其中的sql住人利用,使用sqlmap将其库拖成功
	2、学到的东西:
		2.1 sqlmap在住人rewrite的网址时,对rewrite网址中参数部分加一个*号即可正常住人,否则rewrite过的页面是住人不起来的
		2.2 报错绝对要关掉
		2.3 猜测程序目录等的时候,可以通过读/etc/passwd文件,知道服务器上有哪些账号,根据账号读取相应的/home/账号名/.bash_history 来读取历史操作
		2.4 结合页面url,来猜测其中的一个文件,只要找对了一个文件名,就可以根据引用关系顺藤摸瓜,将其绝大多数代码搞定
三、openlogin服务器端安全升级:
	1、上周对openlogin的客户端进行了安全升级,但是服务端很是很脆,上去看了下,拖库太轻松了,所以将其安全方面升级了下。
	2、具体实现:
		2.1 mysql_error不允许输出
		2.2 openpassword加密,现在是直接输出的数据库中的md5值
		password记录到cookie中的值为md5("实际密码").','.生成时候的时间戳.','.md5(时间戳+随机字符串)
		使用cookie中的密码时候,必须保证前后两个都是32位的md5值,中间的时间戳不超过1星期,后面的MD5验证串正确
		当用户的cookie被劫持的话,还是有可能被绕过
		2.3 用户输入的用户名只能是4位小写字母加0到16位小写字母加数字
		2.4 密码必须超过6位,必须有两种字符(大写字母、小写字母、数字、特殊字符)
		2.5 密码不带入sql中进行查询,只根据账号取出来的密码进行字符串匹配是否相等,从而防止sql注入
		2.6 所有的cookie不允许js读取
		2.7 openlogindomain也做同样的升级处理
		2.8 该目录下的其他数据库连接文件,全部引用ci123_safe.php文件,防止一般攻击(40多个文件,改的好蛋疼...)
四、防范要点:
	1、对所有的外部数据都要过滤,判断($_GET,$_POST,$_COOKIE,$_SERVER等),不要使用一些奇奇怪怪的数据接收方式,比如$_REQUEST,$GLOBALS['HTTP_RAW_POST_DATA']之类的,这个后面要审核代码就是个悲剧,容易漏掉
	2、清楚的知道数据是什么格式,多少长度的,做相应的判断
	3、90%以上的参数都是整型,直接intval处理
	4、字符串型的,如果是特地格式的数据,直接用正则来判断:
		4.1 手机号、ip地址、用户名、QQ号、邮编、邮箱、日期等等
		4.2 这些的正则网上随便找找就一大堆,不要说不知道怎么写
	5、富文本编辑器的的情况下,可以采用360的过滤,因为这些很难验证,我们可以采用他们做的这个来验证
	6、千万不要开报错!!!页面里不能输出
	7、数据库权限开通:master:增删改查,slave:select权限即可
五、攻击小技巧
	1、利用搜索引擎找到有漏洞的页面:site:***.com inurl:?id=之类的
	2、通过在参数后面加单引号或者and 1=1 ,and 1=2 来判断是否可注入
	3、善于利用工具来做,然后看下工具生成的攻击log来学习

发表评论