sql注入之一次艰难的绕过-三层防护（oracle）
打开：www.xxxx.com/news/detail.jsp?id=2862
我们经过测试知道此处含有sql注入。我们尝试下：
http://www.xxxxxx.com/news/detail.jsp?id=2862%27 加入单引号，然后就报错：
可以看到，字符型注入。但是此处有防火墙。我们测试下 ‘ and 1=1– +
可以看到，直接被防火墙拦截了。而且拦截及其变态。连anxd都拦截。
既然拦截了anxd，我们推测他应该是过滤的后面，比如1=1 那么我们换成1 like 1试试：
换成and 1 like 1会显示系统错误。在这里，相当于连最基础的正确语句都无法执行。可想而知，这个网站至少有两层过滤，一层防火墙，一层代码过滤。 like被过滤，只能硬拼了。直接硬钢waf。另外，如果此处为mysql+php那么绕过也许不会那么难受，但是此处是jsp+oracle。 Oracle语法基本就那么几种，像/*!50000 这种类型的都不可以用，所以给绕过带来了极大的困难。
我们直接钢waf。我们尝试是否有可以替代空格的进行绕过，看看waf是否有所疏漏，经过大量测试，发现/*%23%0a*/可以替换空格，进行绕过。我们尝试下：
And 1=1
And 1=2
看到成功，非常开心。然后当我满怀欣喜准备大杀四方的时候，输入order by 10的时候一脸懵逼：
居然又被防火墙拦截。前面不知道大家是否记得我说过了，此处防火墙最起码有两层过滤，但是经过我测试最终发现，其实有三层过滤。真是令人窒息的防火墙。
这样又增加了很多困难。在此处，因为要进行联合查询，而基本的order by 都会拦截，那么联合查询更难突破，因为要同时突破unon select from这三个无意是判了死刑。
联想到 http://www.smedi.com/news/detail.jsp?id=2862%27 加入单引号，然后就报错：
我们可以采用显错注入。首先，我们来获取数据库名：
然后发现，又被拦截。虽然是意料之中，但是还是想说一句：我勒个擦。
经过测试发现拦截了utl_inaddr.get_host_name函数。众所周知，mysql可以用/*!information_schema*/.SCHEMATA 此语法进行绕过测试。但是oracle是肯定不支持此语法的。不信我们试试：
可以看到，执行失败，语法是错误的。我们不要灰心。
此处，我们思维就需要进行改变，我们不能像这种形式：/*!information_schema*/.SCHEMATA
但是可以这一种。information_schema./*!*/SCHEMATA
然后进行尝试：
成功绕过取得sys库。