pikachu SQL Injection

SQL Injection攻击流程

1.找到注入点,可以用web漏洞扫描工具自动找或者自己输入payload进行查找

2.通过注入点输入payload爆出信息,比如版本操作系统,表列字段的值

3.获取操作系统权限,通过数据库执行shell上传木马。

数字型注入post

因为是post,所以不会在URL中传参,我们可以抓包看一下

 发送到repeater模块进行修改测试

尝试 1 or 1 = 1  状态是200,说明是正确的

这里将所有的信息都爆了出来

 

确定有几列

payload:1 order by 3  正常回显,说明就这两列

 确定回显字段:

payload: 0 union select 1,2  都可回显

 剩下的操作和sqlilabs中的基本就一致了,爆库爆表爆字段爆字段值(虽然直接1 or 1=1

就已经把所有信息爆出来了,不过还是想操作一下~)

字符型注入get

随便输一个1,因为是get请求所以传参就在url里了

 观察源码发现闭合为单引号闭合

 payload:kobe' or 1 = 1 # 即可得到所有信息

搜索型注入

在数据库中 搜索语句一般为:

select * from number where username like '%str%'

字符串会被  '%%'包裹

 观察源码,同样name参数从前端传过来也没有进行处理,用'%%'包裹

所以只需要考虑闭合即可,下面给几个例子

1. like '%str%' or 1 = 1 #%'     

2. like '%%%%'

xx型注入

唯一不同的就是闭合变成了('')

所以注意闭合多加的括号即可

('xx') or 1 = 1 #')

 insert/update注入

后面几个小模块基本是基于报错的注入,一般是前端没有屏蔽报错信息

一般常用的3个函数:

1.updatexml():在MySQL中对XML文档数据进行查询和修改的XPATH函数。

2.extractvalue():在MySQL中对XML文档数据进行查询的XPATH函数。

3.floor():MySQL中用来取整的函数。

如果XPathstring这里是一个表达式会先把表达式执行之后将结果通过报错回显出来

inert注入:前端输入的数据会通过后台insert数据进去

insert语句一般为:

insert into 表名(username,pw,sex) values('str',111,2,333,4)

我们主要是在str这里构造闭合,红色部分为payload。

insert into 表名(username,pw,sex) values('  1' or updatexml(1,concat(0x7e,database()),0)   or '  ',111,2,333,4)

可以获取数据库

接下来update部分和insert部分是差不多的,我们先注册好一个账号进去登录

还是在有字符型注入漏洞的地方,输入我们上面的payload

delete注入

 先删除一个留言抓包看一哈,应该是用id进行为关键字进行删除

 将这个包发送到repeater 改包放包。

payload:id= 1 or updatexml(1, concat(0x7e,(select (concat_ws('-',username,password)) from pikachu.users limit 0,1)  ),1)

因为这个包是已经前端url处理过的,所以我们的payload也要进行url编码

这样后台才可以解析执行我们的payload

 获得账号密码

 

Http Header注入

指的是一种场景,开发人员为了验证客户端头部信息,或者通过头部获取客户端信息,

比如useragent、accept字段。会对客户端头部信息进行获取并使用SQL进行处理,

如果没有做安全处理会导致SQL注入的漏洞。

先登录这个模块,这里后台应该是已经获取了我们的头部信息

 我们抓包发送到repeater模块看一下

 在ua这里将内容清除 只输入单引号,发现报错,说明是获取了我们的头部的值了

 所以数据库那里会有一个insert操作,我们输入上面insert构造的payload进行尝试:

firefpx' or updatexml(1,concat(0x7e,database()),0)   or '

 同理在cookie那里输入同样的payload也是可以执行的

布尔盲注

在sqli-labs已经用过很多了,所以下面就给个例子,如果不会的可以看sqli-labs中

我写的关于盲注的部分,还算是比较详细。

payload:

kobe' and ascii(substr(database(),1,1))>113 #

可以看到报错了,因为p是112 所以<113 肯定会报错的,而报错注入就是根据输入

的payload的逻辑正确还是错误进行猜测,但是前提需要前端页面可以返回报错信息。

 

payload:

kobe' and ascii(substr(database(),1,1))=112 #

 

延时注入

布尔盲注是基于页面回显的正确还是错误

延时注入是根据页面是否执行sleep() 还是迅速回显来判断正误

这个我在sqli-labs中也是有写到,可以翻看我延时注入的blog

payload:(如果sleep5秒就是正确,否则直接返回页面)

kobe' and if((substr(database(),1,1))='p',sleep(5),null)#

SQL Injection注入漏洞防范

一般通过两个维度来防范

1.代码层面:

  ①对输入进行严格的过滤和转义

  ②使用预处理和参数化(Parameterized)

2.网络层面:

  ①通过WAF设备启用防SQL Injection注入策略

  ②云端防护(360,阿里云盾)

转义+过滤:mysqli_real_escape_string()转义过滤单双引号等

       str_replace("%","",$_POST['username']),把post里面的数据含有的%替换为空

预处理:使用PDO的prepare预处理(预处理+参数化)

    平常SQL注入的时候是直接将payload和参数进行拼接,而prepare

    先不传参数,先做预处理,比如下面的?就是一个参数化的占位符

    当传参的时候都会把我们输入的语句当作一个整体去处理,而不像

    我们之前那样可以进行闭合拼接。PDO默认情况会有两次交互,先

    将带有占位符的参数华语句传给后台,之后再传语句。这样基本杜绝

    了SQL注入的漏洞

网络防护:WAF

  甲方通过部署WAF,如果攻击者注入payload也会先通过WAF,WAF会识别出

  不安全的请求然后阻拦掉这次请求。不仅是本地WAF,还有一些云WAF,还可    

  以进行DDOS(流量)清晰,SDN加速等。

    

原文地址:https://www.cnblogs.com/Zh1z3ven/p/12607751.html