不久前,我的同事Fredrik提到Safari允许域名中包含特殊字符。 他在Detectify Crowdsource Slack
中分享了这个情况。这也引起了我的兴趣,所以我觉得对此进行相关研究。
我们需要注意,除了OS X之外,Safari还存在于iOS上,所以这也导致Safari成为最受欢迎的浏览器之一。
在阅读了博客文章(之后已被翻译成英文)后,我去了HackerOne
和Bugcrowd
,拿到了一些获得赏金的程序并将所有域名都放到了一个文本文件中。 在我手动完成这些操作后,由于没有保存上一次列表,所以可能丢失了一些内容。
之后我编写了一个Python函数来循环遍历域,并使用asdf.[domain]
的记录保存这些域。 可以假设这些域支持通配符,而我最终得到了大约80个域名。
def wildcard(d):
if subprocess.Popen(["dig", "asdf."+d, "+short"], stdout=subprocess.PIPE).communicate()[0]:
return True
仔细查看该列表,我们发现明显大多数只是将*.[domain]
重定向到[domain]
或www.[domain]
,所以让我们再次使用Python来帮助我们缩小这个列表。
requests.packages.urllib3.disable_warnings()
def check(d):
try:
r = requests.get("http://asdf." + d, verify=False)
if re.match("^http(s)*:\/\/(www.)*"+d, r.url):
return False
except:
print "Error: " + d
return True
此时我们得到了不到50个不同的域名,然而这些域名很少能够手动完成的。
其中许多页面会重定向到默认页面(例如,paypal-forward.com总是重定向到paypal.com),而如果用户在请求中放置了不规范的字符则
会响应服务器错误。其中一些实际上是HTML编码的URL。根据我们上面的内容,我找到了三个不同的网站作为分析。
First unnamed service
这可能是域名中特殊字符直接引起的XSS。
与公司获得自己的[company].slack.com
类似,使用此服务可获得自己的子域名。 注销时转到域意味着会显示登录表单,包括子域。 如下所示:
<form action="https://subdomain.chatservice.com" method="post">
<input id="user" autofocus>
<input id="pass">
</form>
第一个出现问题是我们不能简单地插入脚本标记进行注入攻击。 虽然Safari允许部分特殊字符的输入,但有些字符是不允许的。 除了使域无效的字符(例如/)之外,我们很快也发现域也会对某些字符进行自行删除操作。
我开始阅读form-tag
所支持的部分并尝试注入所有参数。
"onfocusin="alert(1)"d="
(onfocusin与onfocus不同,并且在输入框被监控的形式下工作正常)。
现在我们只让XSS测试人员绕过。 由于此payload仅适用于Safari,如果我们不能绕过XSS的检查模块,它就变得毫无价值。 幸运的是,我们需要做的就是记住该服务删除了哪些字符,并相应地更改我们的payload。
"onfo%0ccusin="alert(1)"d="
Shopify
Shopify是下一个列表中的目标。 他们在* .shopify .com
和* .myshopify.com
上都有一个通配符,两者都定位到同一个页面。 看一下源代码和Safari主机的内容,我们需要清楚将要做的事情。
我们必须从欺骗正则表达式的检查开始以便理解我们在* .shopify.com
中未知的内容。 我们只需在域名中添加句点即可轻松完成,例如hehehe.shopify.com./
。
然后我们通过 jQuery’s ().html
添加主机名。 起初我想注入类似于<svg•onload=alert(1)>
的payload,但事实证明服务器在我试图使用非空格字符时拒绝进行回复(例如%0c)。
使用().html
函数,我最终得到了以下解决方案:
http://as<script>eval(location.hash.substring(1));df<!--.sectest42.shopify.com./#alert(document.domain)
但是这个漏洞并没有赏金奖励,因为在shopify.com和myshopify.com的子域上执行脚本不会导致额外的安全风险。Shopify
允许客户将文件上传到cdn.shopify.com
,并在myshopify.com
的子域上托管任意内容。
话虽如此,但他们也非常好地处理了报告,并鼓励我能够在他们处理完问题后公开披露其平台上的漏洞。总体而言,这是一种愉快的漏洞发掘体验,我们现在已经介绍了如何通过经典操作反射XSS和使用JavaScript来实现XSS。
Asian based webstore
当在子域中使用特殊字符时,我们遇到了一个经典的错误,这也就反映了系统容易受到XSS的攻击。
但是,我并没有比HTML注入花费更长时间。所有payload都将通过安全审核人员的审核,这对于仅限Safari的漏洞来说是没有意义的。
(我实际上写了另一个脚本来尝试从%00到%FF的所有字符,以确认没有字符被服务器端过滤掉,这是与第一个记录方法类似的另一种方法)
A Christmas story of errors, beers and passwords
在进行这些操作时,我偶然发现Safari中的证书错误页面也容易受到攻击。而通配符同样可以触发此错误,与x.slack.com
和x.y.slack.com
相比,其中证书用于* .example.com
但Web服务器支持*.*.example.com
。
由于我们能够将所有请求均重定向到有缺陷的证书上,所以另一种触发错误的方法是令网站视MITM为受害者。最常见的简便的小规模方法就是令攻击者和受害者使用相同的无线网络。
起初这看起来像一个UXSS攻击,但事实证明Safari修改了源代码。
我对这个漏洞进行了尝试,但是没有发现其他更新的利用,之后我们便向Apple(CVE-2018-4133)报告了它。
Safari所支持的密码管理器数量超出了我的测试范围,因此我采用了与以前相同的方法来测试Bug Bounty
或Responsible Disclosure
的密码管理器以便获得更短的列表。
其中的一个较为受欢迎的密码管理器支持自动填充操作,并且可以利用选项卡API检查位置信息。
这意味着我可以窃取任何触发Safari错误的网站的密码。是否能将我们上述内容在iOS上重现取决于系统如何处理扩展。所以它也提醒了我们,这些自动填充功能确实应该被禁用。
本文为2018年十大网络黑客技术提名文章,欢迎读者来阅
本文为翻译文章,原稿为:https://labs.detectify.com/2018/04/04/host-headers-safari/