<summary><strong>Вивчайте хакінг AWS від нуля до героя з</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* Якщо ви хочете побачити вашу **компанію рекламовану в HackTricks**або**завантажити HackTricks у PDF** Перевірте [**ПЛАНИ ПІДПИСКИ**](https://github.com/sponsors/carlospolop)!
Використовуйте [**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks) для легкої побудови та **автоматизації робочих процесів** за допомогою найбільш **продвинутих** інструментів спільноти у світі.\
> * У **кеш-отруєнні**, атакуючий змушує додаток зберігати деякий шкідливий вміст у кеші, і цей вміст подається з кешу іншим користувачам додатку.
> * У **кеш-обмані**, атакуючий змушує додаток зберігати деякий чутливий вміст, що належить іншому користувачеві, у кеші, а потім атакуючий отримує цей вміст з кешу.
Кеш-отруєння спрямоване на маніпулювання кешем клієнта для примусу клієнтів завантажувати ресурси, які є неочікуваними, частковими або під контролем атакуючого. Розмір впливу залежить від популярності пошкодженої сторінки, оскільки забруднена відповідь подається виключно користувачам, які відвідують сторінку під час періоду забруднення кешу.
1.**Ідентифікація неіндексованих введень**: Це параметри, які, хоча не є обов'язковими для кешування запиту, можуть змінити відповідь, яку повертає сервер. Виявлення цих введень є важливим, оскільки їх можна використовувати для маніпулювання кешем.
2.**Експлуатація неіндексованих введень**: Після ідентифікації неіндексованих введень наступним кроком є виявлення способів зловживання цими параметрами для зміни відповіді сервера таким чином, що це користується атакуючому.
3.**Переконання, що забруднена відповідь зберігається в кеші**: Останнім кроком є переконання, що змінена відповідь зберігається в кеші. Таким чином, будь-який користувач, який отримує доступ до пошкодженої сторінки під час забруднення кешу, отримає забруднену відповідь.
Зазвичай, коли відповідь була **збережена в кеші**, буде **заголовок, що вказує на це**, ви можете перевірити, на які заголовки варто звернути увагу у цьому пості: [**HTTP-заголовки кешування**](../network-services-pentesting/pentesting-web/special-http-headers.md#cache-headers).
Якщо ви вважаєте, що відповідь зберігається в кеші, ви можете спробувати **надсилати запити з поганим заголовком**, на який повинна бути відповідь з **кодом статусу 400**. Потім спробуйте отримати доступ до запиту зазвичай, і якщо **відповідь має код статусу 400**, ви знаєте, що він є вразливим (і ви навіть можете виконати DoS).\
Погано налаштованим заголовком може бути просто `\:` як заголовок.\
_Зауважте, що іноді ці види кодів статусу не кешуються, тому цей тест буде некорисним._
Ви можете використовувати [**Param Miner**](https://portswigger.net/bappstore/17d2949a985c4b7ca092728dba871943) для **брут-форсу параметрів та заголовків**, які можуть **змінювати відповідь сторінки**. Наприклад, сторінка може використовувати заголовок `X-Forwarded-For`, щоб вказати клієнту завантажувати скрипт з цього місця:
З параметром/заголовком, ідентифікованим, перевірте, як він **санітарний** та **де** він **відображається**або впливає на відповідь з заголовка. Чи можна цим скористатися (виконати XSS або завантажити JS-код, керований вами? виконати DoS?...)
Після того, як ви **ідентифікували****сторінку**, яку можна зловживати, який **параметр**/**заголовок** використовувати та **як** цим **зловживати**, вам потрібно отримати кешовану сторінку. Залежно від ресурсу, який ви намагаєтеся отримати в кеші, це може зайняти певний час, можливо, вам доведеться намагатися протягом кількох секунд.\
Заголовок **`X-Cache`** у відповіді може бути дуже корисним, оскільки він може мати значення **`miss`**, коли запит не був закешований, та значення **`hit`**, коли він закешований.\
Заголовок **`Cache-Control`** також цікавий, щоб знати, чи ресурс кешується та коли наступний раз ресурс буде закешовано знову: `Cache-Control: public, max-age=1800`\
Ще один цікавий заголовок - **`Vary`**. Цей заголовок часто використовується для **вказівки додаткових заголовків**, які розглядаються як **частина ключа кешу**, навіть якщо вони зазвичай не мають ключа. Тому, якщо користувач знає `User-Agent` потерпілого, якого він націлює, він може забруднити кеш для користувачів, які використовують цей конкретний `User-Agent`.\
Ще один заголовок, пов'язаний з кешем, - **`Age`**. Він визначає час у секундах, протягом якого об'єкт перебував у проксі-кеші.
При кешуванні запиту будьте **обережні зі заголовками**, які ви використовуєте, оскільки деякі з них можуть бути **використані несподівано** як **ключові**, і**жертва повинна буде використовувати той самий заголовок**. Завжди **перевіряйте** Отруєння Кешу з **різними браузерами**, щоб переконатися, що воно працює.
Куки також можуть відображатися у відповіді сторінки. Якщо ви можете зловживати цим, щоб викликати XSS, наприклад, ви зможете експлуатувати XSS у кількох клієнтів, які завантажують зловісну кеш-відповідь.
### Отруєння кешу з використанням траверсу шляху для крадіжки ключа API <a href="#using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities" id="using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities"></a>
[**У цій статті**](https://nokline.github.io/bugbounty/2024/02/04/ChatGPT-ATO.html) пояснюється, як було можливо вкрасти ключ API OpenAI за допомогою URL-адреси, подібної до `https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123`, оскільки все, що відповідає `/share/*`, буде кешуватися без нормалізації URL-адреси Cloudflare, що було зроблено, коли запит досяг веб-сервера.
### Використання кількох заголовків для експлуатації вразливостей отруєння кешу веб-сайту <a href="#using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities" id="using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities"></a>
Іноді вам доведеться **експлуатувати кілька неідентифікованих введень**, щоб мати змогу зловживати кешем. Наприклад, ви можете знайти **відкритий редірект**, якщо ви встановите `X-Forwarded-Host` на домен, яким ви керуєте, і`X-Forwarded-Scheme` на `http`. **Якщо****сервер****пересилає** всі **HTTP**-запити **на HTTPS** та використовує заголовок `X-Forwarded-Scheme` як домен для перенаправлення. Ви можете контролювати, куди буде спрямована сторінка через перенаправлення.
Якщо ви виявили, що заголовок **`X-Host`** використовується як **ім'я домену для завантаження ресурсу JS**, але заголовок **`Vary`** у відповіді вказує на **`User-Agent`**, то вам потрібно знайти спосіб витягти `User-Agent` жертви та забруднити кеш, використовуючи цей `User-Agent`:
Дізнайтеся тут, як виконати [атаки на кешування шляхом зловживання HTTP Request Smuggling](http-request-smuggling/#using-http-request-smuggling-to-perform-web-cache-poisoning).
[Сканер вразливостей веб-кешування](https://github.com/Hackmanit/Web-Cache-Vulnerability-Scanner) може бути використаний для автоматичного тестування на вразливість кешування веб-сторінок. Він підтримує багато різних технік і має високу настроюваність.
Використовуйте [**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks), щоб легко створювати та **автоматизувати робочі процеси** за допомогою найбільш **продвинутих** інструментів спільноти у світі.\
ATS передав фрагмент у URL без його видалення і створив ключ кешування, використовуючи лише хост, шлях та запит (ігноруючи фрагмент). Таким чином, запит `/#/../?r=javascript:alert(1)` був відправлений на бекенд як `/#/../?r=javascript:alert(1)`, і ключ кешу не містив в собі навантаження, лише хост, шлях та запит.
Відправлення некоректного значення у заголовку content-type спричинило кешовану відповідь 405. Ключ кешу містив куки, тому можливо було атакувати лише неавторизованих користувачів.
GitLab використовує віджети GCP для зберігання статичного контенту. **Віджети GCP** підтримують **заголовок `x-http-method-override`**. Таким чином, було можливо відправити заголовок `x-http-method-override: HEAD`і забруднити кеш, щоб повертав порожнє тіло відповіді. Також це могло підтримувати метод `PURGE`.
У додатках Ruby on Rails часто використовується проміжний шар Rack. Мета коду Rack полягає в тому, щоб взяти значення заголовка **`x-forwarded-scheme`** і встановити його як схему запиту. Коли відправляється заголовок `x-forwarded-scheme: http`, відбувається перенаправлення 301 на ту саму локацію, що потенційно може призвести до відмови в обслуговуванні (DoS) для цього ресурсу. Крім того, додаток може враховувати заголовок `X-forwarded-host`і перенаправляти користувачів на вказаний хост. Ця поведінка може призвести до завантаження файлів JavaScript з сервера зловмисника, що створює ризик для безпеки.
Раніше 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, що відповідають високотрафікуючим інструментам, таким як FFUF або Nuclei, для керування навантаженням сервера. Цей підхід може призвести до вразливостей, таких як кешування та DoS.
[RFC7230](https://datatracker.ietf.mrg/doc/html/rfc7230) визначає припустимі символи у назвах заголовків. Заголовки, що містять символи поза визначеним діапазоном **tchar**, в ідеалі повинні спричиняти відповідь 400 Bad Request. На практиці сервери не завжди дотримуються цього стандарту. Прикладом є Akamai, яка передає заголовки з недійсними символами та кешує будь-яку помилку 400, поки заголовок `cache-control` відсутній. Було виявлено вразливий шаблон, де відправка заголовка з недійсним символом, таким як `\`, призводила до кешованої помилки 400 Bad Request.
Спочатку слід зауважити, що **розширення** такі як `.css`, `.js`, `.png` тощо зазвичай **налаштовані** на **збереження** в **кеші**. Тому, якщо ви звернетесь до `www.example.com/profile.php/nonexistent.js`, кеш, швидше за все, збереже відповідь, оскільки він бачить **розширення**`.js`. Але, якщо **додаток****повторюється** з **чутливим** вмістом користувача, збереженим у_www.example.com/profile.php_, ви можете **вкрасти** цей вміст від інших користувачів.
Інший дуже ясний приклад можна знайти в цьому описі: [https://hackerone.com/reports/593712](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_ файлу).
* [**toxicache**](https://github.com/xhzeem/toxicache): Сканер на Golang для пошуку вразливостей на кешування веб-сторінок у списку URL-адрес та тестування різних технік впровадження.
Використовуйте [**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks), щоб легко створювати та **автоматизувати робочі процеси** за допомогою найбільш **продвинутих** інструментів спільноти у світі.\
<summary><strong>Вивчайте хакінг AWS від нуля до героя з</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* Якщо ви хочете побачити **рекламу вашої компанії на HackTricks**або**завантажити HackTricks у форматі PDF**, перевірте [**ПЛАНИ ПІДПИСКИ**](https://github.com/sponsors/carlospolop)!
* Відкрийте для себе [**Сім'ю PEASS**](https://opensea.io/collection/the-peass-family), нашу колекцію ексклюзивних [**NFT**](https://opensea.io/collection/the-peass-family)
* **Приєднуйтесь до** 💬 [**групи Discord**](https://discord.gg/hRep4RUj7f) або [**групи Telegram**](https://t.me/peass) або**слідкуйте** за нами на **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Поділіться своїми хакерськими трюками, надсилайте PR до** [**HackTricks**](https://github.com/carlospolop/hacktricks) **і** [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) **репозиторіїв на GitHub**.