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

by bo0om, Wallarm Research

I’ve previously published an article about using Safari to compromise a computer file system. Unfortunately, there are more issues with Safari as we are now finding out. In this post, we will take a look at the possibility of a XSS exploit and a cookie compromise stemming from “unusual” Safari behavior.

Normal browsers and their DNS requests.

What does a browser do to open a web page? First, it sends a DNS request to the server to request the right IP address. It’s a well known fact that a DNS server can respond to an arbitrary request, as long as wildcards are allowed in its settings.

To illustrate this behavior, let’s try to use dig utility to send the following request:

dig “x^x’x`x=x>x<x.reddit.org” A @8.8.8.8

Here is what the DNS server sends back

So far so good, but what will happen if such a domain is used in a browser redirect? Will the browser try to process this response and open such a URL? Hopefully, it would not. Most browsers, before trying to open a webpage, validate the URL string to verify it represents a domain name.

Most browsers, but not Safari…

What about Safari?

Safari is “special” in that it send the DNS request even when the suggested request contains special characters. Truth be told, we noticed a similar lack of input validation in CURL, but as a service utility, CURL’s requirements are more lax. In Safari, though, this lack of validation is a root of a whole class of client-side vulnerabilities that we are going to discuss further on.

To very this Safari’s “super-ability” we can check its behavior against hsts.pro domain. Safari will try to open the resource even when in addition to regular digits and letters, the string would contain all kinds of special characters.

Let’s try this:

http://!"$&'()*+,-;<=>^_`{|}~.hsts.pro

Right on cue, Safari sends the request right on.

It even works with unprintable special characters:

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

The Bad: XSS via Host header

If a page is (properly) working with the current domain, for example using $_SERVER[‘HTTP_HOST’], then using this Safari behavior it is possible to launch an arbitrary javascript.

One limitation is that a vulnerable web application should respond to a request to such a subdomain. The other limitation here is that some of DNS servers do not allow parentheses symbols ( ) in the requests. If parentheses are not allowed, one can use another standard js feature — template strings. To invoke a function, for example, alert(), it may be sufficient to use instead of the parentheses an apostrophe symbol, i.e. alert``

Symbols such as slash /, space or tab can not be included into a domain name at all. However, having access to the control characters, we can replace the space with a pagebreak symbol — %0c. Now our pagebreak symbol and our space symbol will be equivalent.

Thus the following input string

http://a">'><img%0csrc%0conerror=alert``>a.hsts.pro

will be interpreted by a browser as a valid domain url, while, when handled by html, it will look like a tag and the alert() function will be executed, provided XSS Auditor doesn’t interfere.

By analogy, if one wants to use / in the string, it can be easily be substituted with a &sol;

The Ugly: Cookie Injection

Another dangerous attack vector is a Cookie injection.

If the domain url contains a semicolon ; — this enables the possibility of using a part of this string in custom logic, provided that the header creating a cookie also depends on the HOST header. The later is fairly common in many projects.

Even in the absence of XSS, if there the header contains Set-Cookie with path attribute, it should be possible to modify the request in such a way that an injection is still possible.

One more unusual feature of Safari (as was previously demonstrated by Michele Spagnuolo) — is its ability to provide comma separated list of several Cookies in a single header.

This feature makes it possible to form a request string to install arbitrary Cookies into the victim’s browser. To do this the original Cookie needs to be followed by ;followed by a comma separated list of Cookies one wants to inject.

More bad: XSS via Referer

Everybody knows that browsers convert special characters into their URLEncode versions. Thus, even if the content of the Referrer string hits a page, the following would not work for a browser redirect and cross-site scripting:

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

Instead, the application will see the following converted string:

Referrer: http://site/%3Cscript%3Ealert()%3C%2Fscript%3E.html

Just for the purposes of an illustration, I’ve put a redirection php script r.php with a u parameter on the site. Try the following request string to use it:

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

All is well here, that is until somebody starts using Safari. With Safari all the special characters that may be present in the request string will be interpreted by the URLDecode function and will end up at the vulnerable web application in an executable form.

To verify how all this works, try the following url: http://a<img%0csrc=x%0conerror=alert``>.hsts.pro/r.php?u=//hsts.pro/referer.php

What else?

So, what’s going to happen to the web server if it gets specialized characters (that should never be present in the domain name) as a part of the Origin request?

Turns out, nothing good happens. As was demonstrated by another bug hunters (https://www.sxcurity.pro/tricky-CORS/), something as simple as a backquote (%60), can circumvent the validation of the Origin header and execute XHR request completely outside the normal application logic.

Knowing this, it is virtually impossible to predict how a specific web site will behave when presented with special characters or extra symbols in the Origin header. It probably makes sense to at least verify the following:

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

Lastly

Curiously, Safari is starting to resemble Microsoft IE more and more. Until recently, Internet Explorer was the only browser that were vulnerable to Host Header XSS and URLEncode bypass. Now Safari makes this an equal opportunity problem for both Windows and MacOS users.

We have notified Apple of these issues in Safari behavior three weeks ago, but haven’t heard back yet. I will update this post if and when I have a response.

Would love to hear from our readers in the comments — especially if you came up with a new way to exploit this curious Safari behavior.

It would be a good idea to try using these types of attacks in various Bug Bounty programs. With luck it may shine the light on the risks associated with Safari and, perhaps, reveal similar vulnerabilities in other products. Besides, if it does work for you — it’s free money!