hacktricks/src/pentesting-web/cache-deception/README.md

# Пошкодження кешу та обман кешу

{{#include ../../banners/hacktricks-training.md}}

## Різниця

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

## Пошкодження кешу

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

Виконання атаки на пошкодження кешу включає кілька етапів:

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

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

Зазвичай, коли відповідь була **збережена в кеші**, буде **заголовок, що це вказує**, ви можете перевірити, на які заголовки слід звернути увагу в цьому пості: [**HTTP Cache headers**](../../network-services-pentesting/pentesting-web/special-http-headers.md#cache-headers).

### Виявлення: Коди помилок кешування

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

Ви можете знайти більше варіантів у:

{{#ref}}
cache-poisoning-to-dos.md
{{#endref}}

Однак зверніть увагу, що **іноді такі коди статусу не кешуються**, тому цей тест може бути ненадійним.

### Виявлення: Ідентифікація та оцінка незахищених вхідних даних

Ви можете використовувати [**Param Miner**](https://portswigger.net/bappstore/17d2949a985c4b7ca092728dba871943) для **грубої сили параметрів і заголовків**, які можуть **змінювати відповідь сторінки**. Наприклад, сторінка може використовувати заголовок `X-Forwarded-For`, щоб вказати клієнту завантажити скрипт звідти:
```html
<script type="text/javascript" src="//<X-Forwarded-For_value>/resources/js/tracking.js"></script>
```
### Викликати шкідливу відповідь від серверу

З ідентифікованим параметром/заголовком перевірте, як він **санітується** і **де** він **відображається** або впливає на відповідь з заголовка. Чи можете ви його зловживати (виконати 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:
```html
GET /en?region=uk HTTP/1.1
Host: innocent-website.com
X-Forwarded-Host: a."><script>alert(1)</script>"
```
_Зверніть увагу, що це отруїть запит до `/en?region=uk`, а не до `/en`_

### Отруєння кешу для DoS

{{#ref}}
cache-poisoning-to-dos.md
{{#endref}}

### Отруєння кешу через CDN

У **[цьому звіті](https://nokline.github.io/bugbounty/2024/02/04/ChatGPT-ATO.html)** пояснюється наступний простий сценарій:

- CDN кешуватиме все під `/share/`
- CDN НЕ декодуватиме і не нормалізуватиме `%2F..%2F`, отже, його можна використовувати як **перехід по шляху для доступу до інших чутливих місць, які будуть кешовані**, таких як `https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123`
- Веб-сервер ДЕКОДУЄ і НОРМАЛІЗУЄ `%2F..%2F`, і відповість з `/api/auth/session`, який **містить токен автентифікації**.

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

Куки також можуть бути відображені у відповіді сторінки. Якщо ви зможете зловживати цим, щоб викликати XSS, наприклад, ви зможете експлуатувати XSS у кількох клієнтах, які завантажують шкідливу відповідь кешу.
```html
GET / HTTP/1.1
Host: vulnerable.com
Cookie: session=VftzO7ZtiBj5zNLRAuFpXpSQLjS4lBmU; fehost=asd"%2balert(1)%2b"
```
Зверніть увагу, що якщо вразливе cookie дуже часто використовується користувачами, регулярні запити очищатимуть кеш.

### Генерація розбіжностей з роздільниками, нормалізацією та крапками <a href="#using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities" id="using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities"></a>

Перевірте:

{{#ref}}
cache-poisoning-via-url-discrepancies.md
{{#endref}}

### Отруєння кешу з використанням обходу шляху для викрадення 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, що було зроблено, коли запит досяг веб-сервера.

Це також краще пояснюється в:

{{#ref}}
cache-poisoning-via-url-discrepancies.md
{{#endref}}

### Використання кількох заголовків для експлуатації вразливостей отруєння веб-кешу <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` як ім'я домену для редиректу. Ви можете контролювати, куди вказується сторінка за допомогою редиректу.
```html
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:
```html
GET / HTTP/1.1
Host: vulnerbale.net
User-Agent: THE SPECIAL USER-AGENT OF THE VICTIM
X-Host: attacker.com
```
### Fat Get

Надішліть GET запит з запитом в URL та в тілі. Якщо веб-сервер використовує той, що в тілі, але сервер кешу кешує той, що в URL, будь-хто, хто отримує доступ до цього URL, насправді використовуватиме параметр з тіла. Як вразливість, яку знайшов Джеймс Кеттл на сайті Github:
```
GET /contact/report-abuse?report=albinowax HTTP/1.1
Host: github.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 22

report=innocent-victim
```
There it a portswigger lab about this: [https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-fat-get](https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-fat-get)

### Параметричне приховування

Наприклад, можливо розділити **параметри** на ruby-серверах, використовуючи символ **`;`** замість **`&`**. Це може бути використано для вставлення значень непараметризованих параметрів всередину параметризованих і їх зловживання.

Portswigger lab: [https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-param-cloaking](https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-param-cloaking)

### Використання HTTP Cache Poisoning шляхом зловживання HTTP Request Smuggling

Дізнайтеся тут, як виконати [атаки Cache Poisoning, зловживаючи HTTP Request Smuggling](../http-request-smuggling/index.html#using-http-request-smuggling-to-perform-web-cache-poisoning).

### Автоматизоване тестування для Web Cache Poisoning

[Web Cache Vulnerability Scanner](https://github.com/Hackmanit/Web-Cache-Vulnerability-Scanner) може бути використаний для автоматичного тестування на наявність вразливостей до web cache poisoning. Він підтримує багато різних технік і є високонастроювальним.

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

## Вразливі приклади

### 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)`, і ключ кешу не містив в собі payload, лише хост, шлях і запит.

### GitHub CP-DoS

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

### GitLab + GCP CP-DoS

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

### Rack Middleware (Ruby on Rails)

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

### 403 і Storage Buckets

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)

## Cache Deception

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

Перш за все, зверніть увагу, що **розширення**, такі як `.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_) і не на основі content-type. У прикладі _http://www.example.com/home.php/non-existent.css_ буде мати `text/html` content-type замість `text/css` mime type (який очікується для _.css_ файлу).

Дізнайтеся тут, як виконати [атаки Cache Deceptions, зловживаючи HTTP Request Smuggling](../http-request-smuggling/index.html#using-http-request-smuggling-to-perform-web-cache-deception).

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

- [**toxicache**](https://github.com/xhzeem/toxicache): сканер на Golang для виявлення вразливостей до web cache poisoning у списку 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/)


{{#include ../../banners/hacktricks-training.md}}