pikachu靶场--SQL inject--数字型(post)/字符型(get)/搜索型/xx型注入【4.1】~【4.4】

2023-11-04

一：概述

在owasp发布的top10排行榜里，注入漏洞一直是危害排名第一的漏洞，其中注入漏洞里面首当其冲的就是数据库注入漏洞。
一个严重的SQL注入漏洞，可能会直接导致一家公司破产！
SQL注入漏洞主要形成的原因是在数据交互中，前端的数据传入到后台处理时，没有做严格的判断，导致其传入的“数据”拼接到SQL语句中后，被当作SQL语句的一部分执行。从而导致数据库受损（被脱裤、被删除、甚至整个服务器权限沦陷）。

在构建代码时，一般会从如下几个方面的策略来防止SQL注入漏洞：
1.对传进SQL语句里面的变量进行过滤，不允许危险字符传入；
2.使用参数化（Parameterized Query 或 Parameterized Statement）；
3.还有就是,目前有很多ORM框架会自动使用参数化解决注入问题,但其也提供了"拼接"的方式,所以使用时需要慎重!

正常输入：当我们输入查询参数时，后台的运行代码一般为select email from email where……这类的

非法输入（攻击者的输入）1 or 1=1，如果没有对输入的参数进行安全检验，或者有相关的安全措施的话，就会导致攻击者输入的一整段被完整地拼接到SQL语句中，变成了 select email from users where id=1 or 1=1,这是一个可以被正常执行的SQL语句，但是执行效果与select email from users where id=1是截然不同的，它会遍历所有。

SQL inject漏洞攻击流程

二：数字型注入（post）

首先，打开我们的mysql数据库，use pikachu，然后对表“member”做查询，可以看到当参数为“1”和“1 or 1=1”时，所查询到的结果时大不相同的。

当参数为“1 or 1=1”而非“1”时，我们将会看到所有人的相关信息，造成信息泄露，这便是SQL inject漏洞。

用bp演示如下：

将抓到的包发送到“repeater”模块，当id=1时，查询结果为：

当id=1 or 1= 1时，查询结果为：

三：字符型注入（get）

当我们输入字符的时候，正常情况下，后台会给输入的字符＋单引号，把他作为一个整个的字符串来处理，所以我们如果输入的是kobe or 1 = 1，传到后台的时候，or 1 = 1就不会起作用了，因此我们要构造闭合，输入kobe’ or 1 = 1#(#用--替换也可以，都是有着注释的意思，把后面的单引号注释掉)，可以看到，它也能实现遍历。

四：搜索型注入（以搜索k为例）

其内部的代码应该为：select uid,email from [表名] where username like ’%k%’ （k为我们到时候输入进去的东西）

因此我们可以继续构造闭合，诸如xxx%’ or 1 = 1# 对这个漏洞进行攻击，窃取信息。

五：xx型注入

传参，传进去为=('ct') ct为传进去的内容，同上构造合理的闭合: xx') or 1=1# 即可。

总之不管是什么类型，都是要对SQL中的各种类型的输入进行闭合测试，构造好合法SQL，欺骗后台执行。在实际的渗透测试过程中，需要我们去不断的尝试，判断，比如它是单引号闭合还是双引号闭合，判断输入的内容是否参与了后台逻辑运算，如 or 1= 1或是 or 1= 2，如果参与了，那么这个网站肯定是存在SQL inject漏洞的，还有其他好多好多，在网上自行查找。

此外，不管是get方式还是post方式，都可能出现SQL inject 漏洞，本质是一样的。

本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)