注入漏洞一直是危害排名第一的，其中主要指SQl Inject漏洞
1.数字型注入
打开pikachu数字注入单元，我们查询一用brup suite抓包发送到repeater模块分析，发现这是个post提交，我们没法使用url注入
我们直接修改包的参数注入，修改id=1 为 id = 1 or 1=1 返回的包http值为200 页面正常
输入后发现所有的值都已经列出来了。
2.字符型注入（get）
随便输入1，发现由于是get型的，所以参数直接就在url里面了，输入名字试试lucy（前面实验用到过）发现返回了id 和email
我们去猜想他的内部结构 $uname=$_GET['username']
select id,email from 表名 where username = '$uname' 大致应该是这样的 我们可以构造一个闭合去尝试一下 既然猜测到了语句 我们输入111' or 1 = 1#
发现所有的结果都已经爆了出来。
3.搜索型注入
搜索型注入，我们继续猜想逻辑 既然是能通过部分查询就可以想到sql中的like的用法 比如
select id email from 表名 where username like '%$uname%' 这里面的$uname其实就是我们输入的部分，我们继续尝试构造闭合 111%' or 1=1# 其中%'闭合前面的'% #直接将后面的字符注释掉
输入后发现结果已经爆出来了。
4.xx型注入
我们打开xx型注入 发现他的功能和之前字符型的一样，重新输入原来的闭合发现没有爆出结果，我们猜测这应该是一种其他方式的闭合，我们查看源码，发现他的闭合又多了一层括号，我们再次构造闭合
111') or 1=1 # 原理一致，')来闭合前面对应部分 #注释后面的字符
输入后发现所有值已经爆出来了，这里由于我们是练习，所以直接查看了源码，实战的时候就要靠我们的经验与猜测来测试了。
5.insert/update型注入
insert 在数据库的用法一般是 insert into 表名(username,pw,sex,add,number) values('str',111,2,333,4)
updatexml函数 updatexml函数具有查询功能 并且会在xpath处查询 你将语法构造错误 然后它就会将他查询的结果已报错的形式显示出来
concat（ss，dsa，dd）作用是将字符串拼接
既然我们已经知道了插入的语句 我们就可以构造闭合了 xxx' or updatexml(1,concat(0x7e,database()),0) or ' 然后将我们构造的这个payload 输入到插入框中实验
结果我们查询的database（）显示出来了，同理update也是一样的，我们用相同的payload在update中测试
我们先随便注册登录个账号，然后修改信息，将我们的payload输出进去
结果再一次在错误信息中显示出来，当然在我们实战过程里，把database（）换成 我们需要的数据就ok了。