The Good, The Bad and The Ugly of Safari in Client-Side Attacks

我以前发表过一篇关于使用Safari来危害计算机文件系统的文章。不幸的是,我们现在发现了Safari的更多问题。在这篇文章中,我们将介绍一下XSS漏洞攻击以及由于“非常规”Safari浏览器行为导致的cookie折中的可能性。

普通浏览器和他们的DNS请求.

浏览器做什么来打开网页?首先,它向服务器发送一个DNS请求来请求正确的IP地址。一个众所周知的事实是,DNS服务器可以响应任意请求,只要通配符在其设置中被允许。
为了说明这种行为,让我们尝试使用dig实用程序发送以下请求:

dig “x^x`<\”>’\!x=x.sampledomain.com” A

以下是DNS服务器发回的内容:

到目前为止这么好,但是如果在浏览器重定向中使用这样的域名将会发生什么?浏览器会尝试处理这个响应并打开这样的URL吗?希望它不会。大多数浏览器在尝试打开网页之前,验证URL字符串以验证它代表域名。

大多数浏览器,但不是Safari ...

怎么样Safari?

即使建议的请求包含特殊字符,Safari也是“特殊的”,因为它发送DNS请求。说实话,我们注意到在CURL中输入验证的类似缺失,但作为服务实用程序,CURL的要求更为宽松。然而,在Safari中,这种验证的缺失是我们将要进一步讨论的一整类客户端漏洞的根源。

对于这个Safari的“超能力”,我们可以检查它对hsts.pro域的行为。即使除常规数字和字母之外,Safari也会尝试打开资源,字符串将包含各种特殊字符。
让我们试试这个:

HTTP://“$&'()* +, - ; <=> ^ _`{|}〜.hsts.pro

正确的提示,Safari发送请求的权利。

它甚至与不可打印的特殊字符一起工作:

%01-%08,%0b-%0c,%0e-1f,%7f。

不好:XSS通过主机头

如果一个页面(正确)与当前的域名一起工作,例如使用$_SERVER[‘HTTP_HOST’],那么使用这个Safari行为就可以启动一个任意的javascript。

一个限制是易受攻击的Web应用程序应该响应对这样的子域的请求。这里的另一个限制是一些DNS服务器( ) 在请求中不允许使用圆括号。如果不允许使用括号,可以使用另一个标准的js特性 - 模板字符串。为了调用一个函数,例如alert(),使用撇号符号代替括号可能就足够了,即alert

诸如斜线/,空格或制表符之类的符号根本不能包含在域名中。但是,通过访问控制字符,我们可以用换页符号来代替空格。现在我们的分页符号和空格符号将是等效的。 %0c
因此下面的输入字符串

HTTP://一个“>”> <IMG%0csrc%0conerror = alert``> a.hsts.pro

将被浏览器解释为有效的域url,而当通过html处理时,它将看起来像一个标签,alert()函数将被执行,只要XSS Auditor不会干扰。
以此类推,如果要/在字符串中使用,可以很容易地用a来代替/

The Ugly: Cookie Injection

另一个危险的攻击媒介是Cookie注射。
如果域url包含一个分号 ; - 这使得在自定义逻辑中使用这个字符串的一部分的可能性,只要创建一个cookie的头也依赖于HOST头。后者在许多项目中相当普遍。
即使在没有XSS的情况下,如果头部包含带有路径属性的Set-Cookie,也应该可以修改请求,使得注入仍然是可能的。

Safari的另外一个不寻常的功能(就像之前由Michele Spagnuolo演示的那样)是能够在一个头文件中提供以逗号分隔的几个Cookie的列表。

此功能可以形成一个请求字符串,以便将任意Cookie安装到受害者的浏览器中。要做到这一点,原来的Cookie需要后面 ;跟着一个逗号分隔的Cookies列表。

更糟糕的是:XSS通过Referer

大家都知道,浏览器将特殊字符转换成URLEncode版本。因此,即使Referrer字符串的内容碰到一个页面,下面的内容也不适用于浏览器重定向和跨站点脚本:

site/<script>alert()</script>.html

相反,应用程序将看到以下转换的字符串:
推荐人: http://site/%3Cscript%3Ealert()%3C%2Fscript%3E.html
就为了说明的目的,我已经把重定向PHP脚本r.php与u网站上的参数。尝试使用以下请求字符串:

http://hsts.pro/r.php?u=//hsts.pro/referer.php&xss=<script>alert()</script>

一切都很好,直到有人开始使用Safari。使用Safari,请求字符串中可能存在的所有特殊字符将由URLDecode函数解释,并以可执行形式结束于易受攻击的Web应用程序。
要验证所有这些工作,请尝试以下网址:

http://a<img%0csrc=x%0conerror=alert``>.hsts.pro/r.php?u=//hsts.pro/referer.php

还有什么?

那么,如果Web服务器获得专用字符(不应该出现在域名中)作为Origin请求的一部分,会发生什么?
事实证明,没有什么好事发生。正如另一个bug hunters(http://www.sxcurity.pro/2017/11/27/tricky-CORS/)
所表明的那样,像backquote(%60)这样简单的东西可以规避Origin头部的验证,并在正常的应用逻辑之外完全执行XHR请求。
知道这一点,在Origin头文件中提供特殊字符或额外符号时,预测特定网站的行为方式实际上是不可能的。至少验证以下内容可能是有意义的:

  • victim.com&.evil.domain
  • victim.com`.evil.domain
  • victim.com%01.evil.domain

最后

奇怪的是,Safari越来越像微软IE。直到最近,Internet Explorer才是主机头XSS和URLEncode绕过漏洞的唯一浏览器。现在,Safari使Windows和MacOS用户都面临同样的机会问题。
我们很乐意在评论中听到读者的意见,特别是如果您想出一个新的方式来利用这个好奇的Safari行为。
在各种Bug奖励计划中尝试使用这些类型的攻击是一个好主意。幸运的是,它可以照亮Safari的相关风险,也许会揭示其他产品的类似漏洞。此外,如果它适合你 - 这是免费的钱!


转载请注明出处:https://www.freearoot.com/index.php/the-good-the-bad-and-the-ugly-of-safari-in-client-side-attacks.html

文章来源:https://medium.com/@wallarm/the-good-the-bad-and-the-ugly-of-safari-in-client-side-attacks-56d0cb61275a

Tags: