Sqli-labs之Less-34

                                                   Less-34

基于错误_POST_单引号_字符型_addslashes()_宽字节注入

Sqli-labs之Less-34_第1张图片

这一关是POST型的注入,同样的将post传递过来的内容进行了转义处理,过滤了单引号、反斜杠。有之前的例子我们可以看到%df可以将转义的反斜杠给吃掉。而GET型的方式我们是以url形式提交的,因此数据会通过urlencode,如何将方法用在POST型的注入当中呢?

一个参考:Unicode令人混淆的概念,编码这种东西应该要系统地学习。

0x01. 宽字节注入

宽字节注入和 GET 中并无差别,原理在 Less 32 中已详细介绍,使用%bb%27%bb%5c%5c%27代替'均可,在这里同样可以平级越权:

uname=%bb' or 1 limit 1,1#&passwd=1

通过修改偏移limit可以平级越权得到其他账号的回显信息。
这里的符号也可以换成 URL 编码:#=%23'=%27(空格)=%20=+等。

已经绕过了addslashes()的过滤,确定了单引号闭合且无其他过滤,剩下的同 POST 最基本注入,可见 Less 11。

还要注意一点的是在火狐浏览器插件中,使用该方法没有成功:

uname=%bb' or 1 limit 1,1#&passwd=1

Sqli-labs之Less-34_第2张图片

看来问题出在post提交上,上burpsuite,来看问题出在哪:

Sqli-labs之Less-34_第3张图片

Sqli-labs之Less-34_第4张图片

发现多了个25,可我们没有输入这个啊?原来%经过url编码为%25,又生了一次变异,所以无法成功

application/x-www-form-urlencoded      摘自:四种常见的 POST 提交数据方式

这应该是最常见的 POST 提交数据的方式了。浏览器的原生 form 表单,如果不设置 enctype 属性,那么最终就会以 application/x-www-form-urlencoded 方式提交数据。请求类似于下面这样(无关的请求头在本文中都省略掉了):

POST http://www.example.com HTTP/1.1
Content-Type: application/x-www-form-urlencoded;charset=utf-8
title=test&sub%5B%5D=1&sub%5B%5D=2&sub%5B%5D=3

首先,Content-Type 被指定为 application/x-www-form-urlencoded;其次,提交的数据按照 key1=val1&key2=val2 的方式进行编码,key 和 val 都进行了 URL 转码。大部分服务端语言都对这种方式有很好的支持。例如 PHP 中_POST[‘sub’] 可以得到 sub 数组。 很多时候,我们用 Ajax 提交数据时,也是使用这种方式。例如 JQuery 和 QWrap 的 Ajax,Content-Type 默认值都是「application/x-www-form-urlencoded;charset=utf-8」。

到了这里我们应该很清晰的了解到get与post提交数据的不同,get型直接以url形式提交,也就是说遇到%bb,%27这种直接当做url编码后处理,而post型却不是这样,他会把你提交的%bb,%27当做正常数据,然后进行url编码,于是就变成了%25bb,%2527

Sqli-labs之Less-34_第5张图片

所以说啊,有时候火狐插件还是不如“神器”。

修改之后:

Sqli-labs之Less-34_第6张图片

或者这样,结果都是一样的:

Sqli-labs之Less-34_第7张图片

所以接下来union注入,暴数据库,表啥的完全没问题:

Sqli-labs之Less-34_第8张图片

剩下的自行尝试,还要说一点的是源码中

而使用union要保持前后select查询的字段数一致,select username,password from users中username,password是两个字段,所以我们使用union后一个select就得是两个字段。

0x02. 编码转换注入

《注入天书》中,介绍了将 UTF-8 的'转换为 UTF-16 的�'实现注入的方法。这个字符我也不知道是什么。

在Unicode和UTF编码转换网站上的转换结果:

Sqli-labs之Less-34_第9张图片

直接复制进 Burp:

注意:这里的or 1or 1=1的简化写法,只要是永真条件均可,同样的还有or trueor 2>1等。

或者以万能密码的方式来通关

uname=�' or 1=1#&passwd=1

Sqli-labs之Less-34_第10张图片

0x03. POST盲注 

本关有正确回显和错误回显,且除了addslashes()无任何过滤,无论是 Bool 还是 Time 盲注都可以做到,参考前面的 POST 盲注Less-15。

如果使用布尔盲注遇到 '单引号时,可以使用 substr() 和ascii()函数处理下,下面简单演示一下,证明盲注是可行的。

Sqli-labs之Less-34_第11张图片

 

补充:(Unicode详解

Unicode 是容纳世界所有文字符号的国际标准编码,使用四个字节为每个字符编码。

Unicode的实现方式不同于编码方式。一个字符的Unicode编码是确定的。但是在实际传输过程中,由于不同系统平台的设计不一定一致,以及出于节省空间的目的,对Unicode编码的实现方式有所不同。

Unicode的实现方式称为Unicode转换格式(Unicode Transformation Format,简称为UTF)。

UTF 是英文 Unicode Transformation Format 的缩写,意为把 Unicode 字符转换为某种格式。UTF 系列编码方案(UTF-8、UTF-16、UTF-32)均是由 Unicode 编码方案衍变而来,以适应不同的数据存储或传递,它们都可以完全表示 Unicode 标准中的所有字符。目前,这些衍变方案中 UTF-8 被广泛使用,而 UTF-16 和 UTF-32 则很少被使用。

UTF-8 使用一至四个字节为每个字符编码,其中大部分汉字采用三个字节编码,少量不常用汉字采用四个字节编码。因为 UTF-8 是可变长度的编码方式,相对于 Unicode 编码可以减少存储占用的空间,所以被广泛使用。

UTF-16 使用二或四个字节为每个字符编码,其中大部分汉字采用两个字节编码,少量不常用汉字采用四个字节编码。UTF-16 编码有大尾序和小尾序之别,即 UTF-16BE 和 UTF-16LE,在编码前会放置一个 U+FEFF 或 U+FFFE(UTF-16BE 以 FEFF 代表,UTF-16LE 以 FFFE 代表),其中 U+FEFF 字符在 Unicode 中代表的意义是 ZERO WIDTH NO-BREAK SPACE,顾名思义,它是个没有宽度也没有断字的空白。

UTF-32 使用四个字节为每个字符编码,使得 UTF-32 占用空间通常会是其它编码的二到四倍。UTF-32 与 UTF-16 一样有大尾序和小尾序之别,编码前会放置 U+0000FEFF 或 U+FFFE0000 以区分。

你可能感兴趣的:(Sqli-labs之Less-34)