挖洞经验 | 记一次有关参数指定型XSS的故事

各位信息安全大神们，大家好！我准备在这篇文章中跟大家分享一些我在最近一次挖洞过程中的发现，并与安全社区一同分享我的挖洞经验。

写在前面的话

在这篇文章中，我准备跟大家讨论一个我在Bugcrowd私人项目中发现的反射性XSS漏洞，几乎该网站下的任何一个页面都存在这种XSS漏洞，但是之前却没有被任何人发现。在本文中，我们暂且将该网站视作private-bounty.com。

挖洞过程

当我在对这个Web应用进行了一次简单的观察与分析之后，我发现了一个结点，其URL地址格式如下所示；

接下来，我对源码进行了分析并尝试定位“view”参数反映在Web页面的什么位置。原来，整个URL地址都存在于一段Javascript代码中（Script标签），但是其中的“view”参数以及相应的值却不在里面。

我查看到的反射值为：

其中的foo、bar和baz的值同样会反射在页面之中，但这些值都经过了适当的编码处理，因此我无法对这些值进行解析。

接下来，我又尝试在路径地址中添加单引号，但它同样会被Web应用进行编码处理。由于这个网站会对用户的输入数据进行恰当的编码处理，因此我们无法在这里找到可用的XSS漏洞，于是我便继续寻找其他的结点。

我在该网站的每一个结点都发现了 “utm_content=foo&utm_medium=bar&utm_source=baz”这种模式，而且都没有其他参数被反射到页面中。因此，我打算自己在该地址后面添加一个参数，看看我所添加的自定义参数是否会被反射到页面上。但不幸的是，我并没有成功。

接下来，我又尝试添加了一个参数：utm_foobarbaz=xxxxx

添加后的地址格式如下所示：

但这一次我竟然成功了，这个值成功地被反射在了页面上，原来这个Web应用只会将以“utm”开头的参数反射到页面之中。

所以我又进行了一次尝试，尝试使用这个参数值来实现XSS攻击，但这个参数值还是会被Web应用编码。

接下来我所做的最后一次尝试就是在参数名本身中注入一个Payload来触发XSS漏洞：

BOOM!!!!!!!这一次我终于成功了！这一次，这个以“utm”开头的参数名并没有被编码，并且成功反射到了页面之中。

想必大家也知道接下来的结果了，我们成功触发了一次警告弹窗。

总结

我们可以从这一次挖洞经历中学到的是，我们有的时候可以尝试在参数名本身中注入Payload，或者对参数名进行fuzzing操作。本文所介绍的情况相对来说是比较特殊的，因为这个Web应用并不会对特殊关键字（“utm”）进行编码，因此我们从参数名入手实现了一次XSS攻击。