SQL Inject 漏洞-注入点类型-数字类型判断
我们切换到pikachu的平台上面来，选择数字型注入，我们先看一下，他有什么功能
他应该是用post方式提交的，因为他没有在url里面传参
测试sql注入的时候，我们一定要去想象，这个功能提交到后台，后台是怎么操作的，我们可以在我们的大脑里面去想象一下，后台到底是怎么操作的
正常来说，用户的数据是存在数据库里面的，当我们提交1到后端的时候，后端应该是从数据库里面去做查询
所以它后端逻辑是这样的
select 字段1,字段2 from 表名 where id=1
并不知道字段的名称是什么，我们用字段1来代替，然后我们看到前端有两个字段返回，一个是名称，一个是邮箱，我们暂且认为是字段1和字段2，表名，我们也不知道，暂且用表名，id等于多少，其实是我们传进去的，我们自己预测了一下，后端应该是这样运行的
然后，我们可以在BP里面抓一个包，做一下对应的测试，思路理一下，这个1是我们传进去的，因为下来选项传进去的是1
$id=$_post['id']
后端应该是这样做数据接受，它会去接受我们post请求里面的变量id，然后赋值给一个变量，
select 字段1,字段2 from 表名 where id=$id
那我们预测，所有前端的输入，都会拼接到这个地方的话，那我们换成1 or 1=1，然后，我们通过这个返回，看一下，后台这一整段，会不会按照这个逻辑去执行
select 字段1,字段2 from 表名 where id=1 or 1=1;
数字型注入判断：http://192.168.1.4/pikachu/vul/sqli/sqli_id.php post: id=1
正常提交：1
猜测SQL：select 字段名 from 表名 where id =1;
页面回显：id为1的查询结果
#演示：pikachu—SQL-Inject-数字型注入#
对应的操作效果，我们在数据库里面操作演示一下
show databases;
use pikachu;
show tables;
看一下表的字段，
desc member;
这个表里面，有这么多字段，我们把刚刚的操作，在这里面，执行一下，
select username,email from member where id=1;
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-0pSGYqXC-1651303221783)(5-2从一个数字型注入认识sql注入漏洞.assets/4.png)]
这是个正常的操作，得出来的是一行记录，
select username,email from member where id=1 or 1=1;
因为1=1这个条件永远为真，or 1=1就会把这个数据库里面，所有的数据，都给遍历出来，我们可以来执行一下
全部显示出来
我们回到对应的项目，查询id=1，抓包，放到repeater里面去，然后做重放的测试，根据刚刚的逻辑，我们可以在这个地方输入payload，or 1=1
我们可以看到它返回的是200，
我们直接看上面的页面，全部显示出来了，这样就说明id这个地方是存在sql注入的，并且它是个数字型注入，然后我们可以拼接sql注入进去，然后让数据库执行它，得到我们预期的结果，这就是简单的sql数字型注入的演示
我们看一下，后端的代码
首先它这个地方接受前端的请求，然后获取到id，这里它没有做任何处理，直接就把这个id赋值给变量，然后就把它拼接到sql里面去了
$query="select username,email from member where id=$id";
这个注入点是数字型，因为数字型是不需要单引号、双引号的
$result=execute($link, $query);
然后用数据库相关的函数去连接数据库，执行这条sql语句，这样导致$id这部分，是可以被控制的，并且是可以通过拼接来构造合法sql，来造成数据库信息泄露的，这其实就是sql注入的原理