Sqli-labs之Less-34

                                                   Less-34

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

这一关是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

看来问题出在post提交上，上burpsuite，来看问题出在哪：

发现多了个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

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

修改之后：

或者这样，结果都是一样的：

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

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

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

0x02. 编码转换注入

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

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

直接复制进 Burp：

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

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

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

0x03. POST盲注 

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

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

 

补充：（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 以区分。