[国外案例分享]Oracle的神jin注入

既然回归，就应该腹泻式更新，上一篇推文意想不到地赚了3块钱广告费，知足常乐！网络安全，未来可期~

依旧是国外的项目，这次的项目是已经打入后台，然后在一个products参数发现注入，这个注入的利用方式较为罕见，写个小作文给师傅们唠嗑唠嗑，分享属于我的 快乐 悲伤。

1.登录后台之后，发现漏洞接口，products参数单引号直接报错，平平无奇的开局。

2.原以为滔天富贵这么容易降临，于是继续插入'or'1'='1，没想到居然还报错。

我继续插入单个数字1为什么一个数字参数也会报错?

这对于注入级别还在萌新阶段的我来说，不得不对这个报错提出了质疑，难道是自定义的报错信息？

3.经过反复折腾，我放弃了这个点，实在太不像注入了。

4.然后我去挖别的项目，终于有一天，我挖不到洞，就回头看，越看越气，这怎么可能不是注入呢？

5.作为一个合格的菜鸡，我今天一定要把它搞清楚！于是我不断尝试，在系统的其他接口orderby注入，那个orderby也是历经九九八十一难才注出数据(这里就不展开吹牛了)，经orderby注入出数据库的类型为Oracle。这下子思路就出来了，手工构造逃逸点，最终构造出poc:''||'666'||''

6.那么问题来了，这个无回显，怎么注出数据呢？我尝试过用dbms_pipe.receive_message('RDS', 10)，当然也尝试过dnslog，但都没有拿到预期的执行结果。经过查询许多资料，我发现可以执行大量数据查询操作实现时间盲注的效果，

献上poc：

''||(select+decode(substr('C',1,1),'C',(select+count(*)+from+all_objects),0)+from+dual)||''poc释疑：当decode的条件成立时：执行select+count(*)+from+all_objects我们先执行10次条件成立的请求。

再执行10次条件不成立的请求。

执行结果比对如下：

通过分析可以看到一个明显的规律，当条件成立时，响应完成的时间最小不低于700，而条件不成立时，最小的响应时间经常处于100以下。接下来的注出数据，应该不需要我继续写下去了吧？有疑问的师傅可以后台滴滴，一起交流交流。

1.耐心。2.专注。3.愣头青精神。

公众号更新不易，不仅存在法律风险，也难免被人收割成果。用爱发电，走得并不远，总之，且看且珍惜，我要上山去剪沙糖桔了~

原文始发于微信公众号（森柒柒）：[国外案例分享]Oracle的神jin注入