安全的攻与防一直永不过时的话题~
     正如你渗透的某个网站，也许某一刻因为各种技术条件限制，你无法很好对其进行渗透，但是随着自己的成长以及研究。总会有些意想不到的小惊喜在等着你。
     在渗透一个网站的时候，发现了一个数字型的注入点，正准备利用的时候。Duang,安全狗弹出来了。

 
     那天手上的任务不算太多，就打算手动测试一下，思考怎么去绕过安全狗 
     那么下面来讲述我的故事吧！ 
     (1)寻找到一个疑似数字型的注入点 
     访问网站之后，我对带id参数的url进行手工测试。发现有一个url的id参数有问题。 
     首先是正常的url,返回的页面如下图。 

 
     之后我简单的遍历一下id这个参数，当id=1的时候。页面长这个样子。 

 
     然后我开始验证是否可能存在注入点，一般对于这种数字型的参数。我们通过原id数值加减乘除另外一个数值，然后对比运算后的结果的页面与对应id页面是否一样。简单来说，要是id=37-36这个页面和id=1页面长的一样，我们可以猜测这里可能存在一个注入点。 
     然后将id参数变换成id=37-36，如下图。可以发现这个页面完全和id=1一模一样。 

         
    (2)然后我使用order by [数字]来确定当前select语句的列数的时候，数据库报错了。如下图。 

 
     由上图我们可以看见，原来后台的sql语句已经带有order by，那我们--+(在url中+表示空格)注释它好了。可以看到页面又和id=37的一样了。 

 
     之后和常规一样，我们使用union select 1来获取数据。但是现实狠狠的给我们一个耳光，网站有安全狗。如下图 

 
     之后，开始测试了，想一想用%0a（对应着换行符）。不过好像并没有什么卵用。如下图 

 
 
     那我们试试空字符%00，这个在很多场合有神奇功能的字符。好像有用耶，网站返回报错信息，如下图。 

 
我们可以看到37和union之间没有空格。我们加上一个空格看看。如下图，后台还是报错了，报错信息和之前一样，这说明%00这个符号在sql查询语句会有问题，那我们怎么办呢？ 

 
我们将%00放在什么位置，对于sql语句是没有影响呢？我想机智的你会想到mysql的多行注释，我们只需要将%00放在/**/之间，mysql将会对%00视而不见。那我们来看看实际的结果。 

 
     从上图可以看到，返回的错误信息不一样了。熟悉sql语句的同学会知道，这是在告诉我们我们union前面的两个select 语句不一样，这时候我们仔细观察一下，这里select 的列数变成了三列，和我们第一次测试的不一样。如下图，下面是我们第一次union的测试，可以看到这里只有一列。也就是说这个id参数用在了两次不同的查询，意味着我们无法通过union select在获取数据了。 

 
     现在我们来理清一下思绪: 
     第一次select语句为: SELECT count(id) as c FROM `hdm0550293_db`.`m16_news` WHERE cid=37/**/union select 1,2,3-- LIMIT 1
     第二次select语句为: SELECT `id`,`title`,`pic` FROM `hdm0550293_db`.`m16_news` WHERE isdisplay=1 AND cid=37/**/union select 1-- ORDER BY sort desc,id desc LIMIT 0,9     
     (3)既然union无法利用，那我们现在可以利用的技术为报错型注入与布尔盲注。 
     [1]我们测试updatexml(1,concat(0x7e,user()),0) 

 
     [2]我们测试extractvalue(1,concat(0x7e,user())) 

     [3]我们测试or (select count(*) from information_schema.tables group by concat(user(),floor(rand(0)*2)))，如下图。:-O，我的天呀，我们想要的数据出来了。 

 
     获取当前数据库，or (select count(*) from information_schema.tables group by concat(database(),floor(rand(0)*2))) 

 
     但是在获取数据表名的时候，狗狗还是检测到这种。 
     (select count(*) from information_schema.tables group by concat((select table_name from information_schema.tables where table_schema=database() limit 0,1),floor(rand(0)*2)))--+ 

 
     但是，我们起码已经一步步的绕过来，我们突破了它的几个防御点。所以为自己点个赞。 
     [2]当然我们也可以使用盲注技术来获取数据，可是一些常见的列表名还是会被封禁。下面是我在写盲注脚本跑出的库名。 
 

     (4)后来自己在本地环境安装了最新的apache版的安全狗。 

     我们来测试测试，新版本是否可以使用%00。 
     [1]首先，我们先看一下我们发现问题的站点。使用/*%00*/and 1=1可以正常返回页面 

     而看一下我本地环境，最新版的安全狗。这样是无法通过的。 

     很可惜，这个%00符号，最新版的安全狗是检测的，但是为什么目标站点没反应呢？ 
     可以看到安全狗有个选项，在线更新防护规则。 安全狗对于新出来的注入是通过规则来匹配的，而很多网站以为装了安全狗就安然无恙了。殊不知缺乏管理，对安全的不作为，导致了他们即使有了waf，也会导致自己网站遭受黑客的攻击。 
 

     (5)写在最后，网站是需要维护和管理的。时刻注意着系统和软件的更新，不要想着有什么银弹。自己的不作为，什么安全软件也无法帮助你。以前楼主看到安全狗也是很郁闷的，但是经过这一次分析，发现人的不作为往往给我们留下了机会。所以遇到安全狗，就去尝试绕过，也许你遇到的那个就是不作为的管理员。

转自：https://bbs.51cto.com/thread-1176681-1.html