Особенности Safari в client-side атаках

Что делает браузер, чтобы открыть страницу? Для начала, он отправляет запрос DNS серверу, чтобы узнать, с каким IP ему иметь дело.  Как известно, DNS-сервер может отвечать на произвольный запрос, если такая настройка (wildcard) присутствует.

Например, воспользовавшись утилитой dig попробуй отправить такой запрос:

dig "x^x`<\">'\!x=x.yandex.ru" A

DNS сервер вернет IP адрес.

Но что будет, если перенаправить пользователя на такой домен в браузере? Будет ли браузер вообще пытаться открыть такой URL? Конечно нет! Браузер перед отправкой запроса проверяет,  является ли строка доменным именем!

Только если это не Safari…

Особое свойство Safari — он посылает DNS запрос, даже если у доменного имени присутствуют спецсимволы. Правда и CURL не имеет механизма проверки подлинности домена, но этой утилите можно простить. Подобное поведение порождает целый класс client-side уязвимостей, о которых мы сейчас и поговорим.
Чтобы убедиться, наличие такой суперсилы можно проверить на домене hsts.pro. Safari будет пытаться открывать ресурс, если помимо букв и цифр содержатся следующие спецсимволы:

Вот попробуй —
http://!"$&'()*+,-;<=>^_`{|}~.hsts.pro
(разумеется, только для Safari и если DNS сервер, который ты используешь дает ответ, например 8.8.8.8 отвечает корректно).

Более того, туда можно записать и непечатаемые символы:
%01-%08, %0b-%0c, %0e-1f, %7f.

Если на страницу попадает текущий домен, к примеру, с помощью $_SERVER[‘HTTP_HOST’], то можно попробовать провести внедрение произвольного javascript сценария. Разумеется, уязвимое веб-приложение должно отвечать на такой поддомен. Из других минусов — как выяснилось при тестах, некоторые DNS сервера не позволяют отправлять символы “(“ и “)”. Если не пускает скобки, используем фичу js — шаблонные строки. Чтобы вызвать функцию, например, alert() — достаточно использовать вместо скобок символ бэктика — alert``.
А такие символы как “/”, символ пробела или табуляции и вовсе не могут быть частью доменного имени. Однако, так как мы имеем доступ и к управляющим символам, пробел может заменить символ смены страницы — %0c. Символ перевода курсора на новую страницу, в нашем случае, будет равнозначным с пробелом.

Таким образом, ссылка вида
http://a">'><img%0csrc%0conerror=alert``>a.hsts.pro
будет корректно воспринята браузером и в качестве домена, и в качестве тега при попадании в html, а значит, если не будет мешать XSS Auditor — функция alert выполнится.

Дальше — проще, если понадобится указать “/” внутри атрибута — можно использовать, например, его мнемоник — /

Другой, очевидный вариант использования, это инъекция в Cookie. Если в домене будет содержаться знак «;» — это даст возможность отрезать часть заголовка и внедрить свою логику, если заголовок создания cookie также зависит от заголовка HOST. Использование подобного когда во многих проектах — норма:

Даже если XSS отсутствует и ты видишь, что приходит заголовок Set-Cookie с атрибутом domain, попробуй изменить домен таким образом, чтобы выполнить инъекцию.
Более того, (как уже показывал Black2Fan) — Safari имеет еще одну забавную фичу — перечисление нескольких Cookie в одном заголовке Set-Cookie через запятую. Поэтому, используя специально сформированную ссылку можно устанавливать произвольные Cookie в браузер жертвы, закрыв предыдущую печеньку символом “;”, а через запятую перечислить куки, которые ты хочешь установить.

Всем известно, что браузеры преобразуют спецсимволы в их URLEncode представления, поэтому даже если содержимое Referer попадает на страницу, перенаправить пользователя с страницы
site/<script>alert()</script>.html
и выполнить XSS не получится, так как до веб-приложения этот заголовок дойдет как
Referer: http://site/%3Cscript%3Ealert()%3C%2Fscript%3E.html
На сайте я оставил r.php с параметром u, который можно использовать для перенаправлений. Попробуй перейти сюда:
http://hsts.pro/r.php?u=//hsts.pro/referer.php&xss=<script>alert()</script>

Но все меняется, если жертва использует Safari. Ведь все спецсимволы, которые содержатся в доменном имени будут проходить функцию URLDecode, и придут в заголовке на уязвимую страницу в подходящем для нас виде.

А чтобы убедиться, что все работает — вот тебе ссылка:
http://a<img%0csrc=x%0conerror=alert``>.hsts.pro/r.php?u=//hsts.pro/referer.php

А как поведет себя веб-сервер, получив в качестве заголовка Origin спецсимволы, которых в принципе в домене быть не может (ну мы-то знаем)?
Как уже выяснил один из охотников на ошибки, символ бэктика (%60), мог обойти проверку заголовка Origin и смог выполнить XHR запрос в обход логики работы веб-приложения на одном из серверов Yahoo — вжух.

Поэтому, кто знает, как поведет себя тот или иной сайт, если в заголовке Origin будут присутствовать посторонние символы. Рекомендую в первую очередь проверить:
victim.com&.evil.domain
victim.com`.evil.domain
victim.com%01.evil.domain

Забавно, что Safari все больше и больше превращается в Internet Explorer. До этого Host Header XSS и обход URLEncode были только в нем, но теперь вектор атаки расширился на пользователей MacOS. Если ты придумал, как еще использовать подобное поведение браузера — обязательно напиши об этом в комментариях.

Обязательно попробуй подобные атаки на BugBounty, авось 😉