进入靶场，靶场提示 Please input the ID as parameter with numeric value 要我们输入一个数字型的 ID 作为参数进行查询，那我们就按它的意思传入 id 看看网页返回的结果：
如上，靶场返回了一段字符 You are in。似乎它是认可我们的操作了，但我们并没有从中获取什么有用的信息。
接下来，笔者又尝试给它传递了一个异常的值（字符串类型）：
如上，靶场依旧返回了 You are in。我们明明传递的是不符合要求的值，结果它还是返回正常的结果，这个本身就有问题。
为了摸清楚靶场的底线，笔者这里又进行了一系列的测试：
测试 Payload 1: ?id=1 结果: You are in
测试 Payload 2: ?id=3-2 结果: You are in
测试 Payload 3: ?id=1 a 结果: You are in
测试 Payload 4: ?id=1a' 结果: You are in
测试 Payload 5: ?id=1a" 结果: You are in
测试 Payload 6: ?id=b'")( 结果: You are in
可以看到，这关就像是一个无底洞，你给它啥它都会回应你 You are in，你根本摸不透它。
此时，我们需要转变一下测试思路：You are in 是不是就是它的一个障眼法呢，其实它已经背着我们偷偷执行了 SQL 语句，但是由于一直都返回同样的结果，导致我们无法发现呢。
面对上面这种情况，我们就可以采用时间盲注的手段，来看看它有没有偷偷背着我们干坏事了：
知识拓展：如何查看浏览器响应包加载速度
打开浏览器，鼠标右击页面并选择 "检查"，打开 "开发者工具"：
定位到 "网络（NetWork）" 菜单，并刷新当前页面，即可看到网页响应包的加载速度：
测试 Payload 1: ?id=1 and sleep(5) --+ 结果: 24 ms 响应，失败
测试 Payload 2: ?id=1' and sleep(5) --+ 结果: 9 ms 响应，失败
测试 Payload 3: ?id=1" and sleep(5) --+ 结果: 5.02 s 响应，成功
从上面的回显可以看出，它果然背着我们偷偷的执行了 SQL 语句，不过小动作还是被聪明的我们发现啦。
通过上面测试的 Payload，我们已经可以确定了，目标的 GET 型请求参数 id 处存在 SQL 注入漏洞，且注入模板如下：
sql复制代码
注入模板: ?id=1" and sleep(if(攻击语句,5,0)) --+"
推测目标后端模板: select * from users where id="1" and sleep(if(攻击语句,5,0)) --+""
笔者备注: if(攻击语句,5,0) 这么写的原因是，如果攻击成功则页面延时 5 秒返回，否则无延时返回（你失败的推测肯定比你正确的多，这么写可以加快点速度）。
