From 8cb735e79d25132354b99bdd5a6380a34b4e9bdf Mon Sep 17 00:00:00 2001 From: Translator Date: Wed, 20 Aug 2025 19:28:38 +0000 Subject: [PATCH] Translated ['src/pentesting-web/http-request-smuggling/README.md'] to uk --- .../http-request-smuggling/README.md | 94 +++++++++---------- 1 file changed, 47 insertions(+), 47 deletions(-) diff --git a/src/pentesting-web/http-request-smuggling/README.md b/src/pentesting-web/http-request-smuggling/README.md index 718215296..7f018debc 100644 --- a/src/pentesting-web/http-request-smuggling/README.md +++ b/src/pentesting-web/http-request-smuggling/README.md @@ -5,12 +5,12 @@ ## Що таке -Ця вразливість виникає, коли **десинхронізація** між **фронтальними проксі** та **бекенд** сервером дозволяє **зловмиснику** **надіслати** HTTP **запит**, який буде **інтерпретований** як **один запит** фронтальними проксі (балансування навантаження/реверс-проксі) і **як 2 запити** бекенд сервером.\ +Ця вразливість виникає, коли **десинхронізація** між **фронтальними проксі** та **бекенд** сервером дозволяє **зловмиснику** **надіслати** HTTP **запит**, який буде **інтерпретований** як **один запит** фронтальними проксі (балансування навантаження/реверсний проксі) і **як 2 запити** бекенд сервером.\ Це дозволяє користувачу **модифікувати наступний запит, який надходить до бекенд сервера після його**. ### Теорія -[**RFC Специфікація (2161)**](https://tools.ietf.org/html/rfc2616) +[**RFC Specification (2161)**](https://tools.ietf.org/html/rfc2616) > Якщо повідомлення отримано з обома заголовками Transfer-Encoding та Content-Length, останній ПОВИНЕН бути проігнорований. @@ -25,8 +25,8 @@ ### Реальність -**Фронтальне** (балансування навантаження / Реверс-проксі) **обробляє** _**content-length**_ або _**transfer-encoding**_ заголовок, а **бекенд** сервер **обробляє інший**, викликаючи **десинхронізацію** між 2 системами.\ -Це може бути дуже критично, оскільки **зловмисник зможе надіслати один запит** до реверс-проксі, який буде **інтерпретований** бекенд сервером **як 2 різні запити**. **Небезпека** цієї техніки полягає в тому, що **бекенд** сервер **інтерпретує** **2-й запит, що інжектується**, як якщо б він **надійшов від наступного клієнта**, а **реальний запит** цього клієнта буде **частиною** **інжектованого запиту**. +**Фронтальне** (балансування навантаження / Реверсний проксі) **обробляє** _**content-length**_ або _**transfer-encoding**_ заголовок, а **бекенд** сервер **обробляє інший**, викликаючи **десинхронізацію** між 2 системами.\ +Це може бути дуже критично, оскільки **зловмисник зможе надіслати один запит** до реверсного проксі, який буде **інтерпретований** бекенд сервером **як 2 різні запити**. **Небезпека** цієї техніки полягає в тому, що **бекенд** сервер **інтерпретує** **2-й запит, що інжектується**, як якщо б він **надійшов від наступного клієнта**, а **реальний запит** цього клієнта буде **частиною** **інжектованого запиту**. ### Особливості @@ -39,9 +39,9 @@ ## Основні приклади > [!TIP] -> При спробі експлуатувати це з Burp Suite **вимкніть `Update Content-Length` та `Normalize HTTP/1 line endings`** в повторювачі, оскільки деякі гаджети зловживають новими рядками, поверненнями каретки та неправильно сформованими content-length. +> При спробі експлуатувати це за допомогою Burp Suite **відключіть `Update Content-Length` та `Normalize HTTP/1 line endings`** в повторювачі, оскільки деякі гаджети зловживають новими рядками, поверненнями каретки та неправильно сформованими content-length. -Атаки HTTP request smuggling створюються шляхом надсилання неоднозначних запитів, які експлуатують розбіжності в тому, як фронтальні та бекенд сервери інтерпретують заголовки `Content-Length` (CL) та `Transfer-Encoding` (TE). Ці атаки можуть проявлятися в різних формах, головним чином як **CL.TE**, **TE.CL** та **TE.TE**. Кожен тип представляє унікальну комбінацію того, як фронтальні та бекенд сервери пріоритизують ці заголовки. Вразливості виникають через те, що сервери обробляють один і той же запит по-різному, що призводить до несподіваних і потенційно шкідливих наслідків. +Атаки на HTTP request smuggling створюються шляхом надсилання неоднозначних запитів, які експлуатують розбіжності в тому, як фронтальні та бекенд сервери інтерпретують заголовки `Content-Length` (CL) та `Transfer-Encoding` (TE). Ці атаки можуть проявлятися в різних формах, головним чином як **CL.TE**, **TE.CL** та **TE.TE**. Кожен тип представляє унікальну комбінацію того, як фронтальні та бекенд сервери пріоритетизують ці заголовки. Вразливості виникають через те, що сервери обробляють один і той же запит по-різному, що призводить до несподіваних і потенційно шкідливих наслідків. ### Основні приклади типів вразливостей @@ -110,7 +110,7 @@ x= - Зловмисник надсилає запит з обфускованими заголовками `Transfer-Encoding`. - В залежності від того, який сервер (фронтальний або бекенд) не розпізнає обфускацію, може бути експлуатована вразливість CL.TE або TE.CL. -- Непроцесована частина запиту, як видно з одного з серверів, стає частиною наступного запиту, що призводить до смуглінгу. +- Непроцесована частина запиту, як видно з одного з серверів, стає частиною наступного запиту, що призводить до smuggling. - **Приклад:** ``` @@ -133,7 +133,7 @@ Transfer-Encoding #### **Сценарій CL.CL (Content-Length використовується як фронтальним, так і бекендом)** - Обидва сервери обробляють запит виключно на основі заголовка `Content-Length`. -- Цей сценарій зазвичай не призводить до смуглінгу, оскільки є узгодженість у тому, як обидва сервери інтерпретують довжину запиту. +- Цей сценарій зазвичай не призводить до smuggling, оскільки є узгодженість у тому, як обидва сервери інтерпретують довжину запиту. - **Приклад:** ``` @@ -148,7 +148,7 @@ Normal Request #### **Сценарій CL.0** - Відноситься до сценаріїв, де заголовок `Content-Length` присутній і має значення, відмінне від нуля, що вказує на те, що тіло запиту має вміст. Бекенд ігнорує заголовок `Content-Length` (який обробляється як 0), але фронтальний його парсить. -- Це важливо для розуміння та створення атак смуглінгу, оскільки це впливає на те, як сервери визначають кінець запиту. +- Це важливо для розуміння та створення атак smuggling, оскільки це впливає на те, як сервери визначають кінець запиту. - **Приклад:** ``` @@ -163,7 +163,7 @@ Non-Empty Body #### Сценарій TE.0 - Як попередній, але з використанням TE -- Техніка [повідомлена тут](https://www.bugcrowd.com/blog/unveiling-te-0-http-request-smuggling-discovering-a-critical-vulnerability-in-thousands-of-google-cloud-websites/) +- Техніка [reported here](https://www.bugcrowd.com/blog/unveiling-te-0-http-request-smuggling-discovering-a-critical-vulnerability-in-thousands-of-google-cloud-websites/) - **Приклад**: ``` OPTIONS / HTTP/1.1 @@ -190,7 +190,7 @@ EMPTY_LINE_HERE #### Примус через заголовки hop-by-hop -Зловживаючи заголовками hop-by-hop, ви можете вказати проксі **видалити заголовок Content-Length або Transfer-Encoding, щоб зловживання HTTP-запитом стало можливим**. +Зловживаючи заголовками hop-by-hop, ви можете вказати проксі **видалити заголовок Content-Length або Transfer-Encoding, щоб зловживання HTTP-запитом було можливим**. ``` Connection: Content-Length ``` @@ -260,9 +260,9 @@ X - **Використання автоматизованих інструментів:** - Інструменти, такі як розширення 'HTTP Request Smuggler' Burp Suite, можуть автоматично перевіряти ці вразливості, надсилаючи різні форми неоднозначних запитів і аналізуючи відповіді. - **Тести на варіацію Content-Length:** -- Надсилайте запити з різними значеннями `Content-Length`, які не відповідають фактичній довжині вмісту, і спостерігайте, як сервер обробляє такі невідповідності. +- Надішліть запити з різними значеннями `Content-Length`, які не відповідають фактичній довжині вмісту, і спостерігайте, як сервер обробляє такі невідповідності. - **Тести на варіацію Transfer-Encoding:** -- Надсилайте запити з обфусцированими або неправильно сформованими заголовками `Transfer-Encoding` і спостерігайте, як по-різному реагують сервери на передньому та задньому плані на такі маніпуляції. +- Надішліть запити з обфусцированими або неправильно сформованими заголовками `Transfer-Encoding` і спостерігайте, як по-різному сервери на передньому та задньому плані реагують на такі маніпуляції. ### Тестування вразливостей HTTP Request Smuggling @@ -274,17 +274,17 @@ X - **Відокремлені мережеві з'єднання:** "Атакуючі" та "нормальні" запити повинні надсилатися через окремі мережеві з'єднання. Використання одного й того ж з'єднання для обох не підтверджує наявність вразливості. - **Послідовні URL та параметри:** Намагайтеся використовувати однакові URL та імена параметрів для обох запитів. Сучасні додатки часто маршрутизують запити до конкретних серверів на задньому плані на основі URL та параметрів. Відповідність цим підвищує ймовірність того, що обидва запити обробляються одним і тим же сервером, що є передумовою для успішної атаки. -- **Таймінг та умови гонки:** "Нормальний" запит, призначений для виявлення втручання з "атакуючого" запиту, змагається з іншими одночасними запитами додатка. Тому надсилайте "нормальний" запит відразу після "атакуючого" запиту. Завантажені додатки можуть вимагати кількох спроб для остаточного підтвердження вразливості. -- **Виклики балансування навантаження:** Сервери на передньому плані, які виконують функцію балансування навантаження, можуть розподіляти запити між різними системами на задньому плані. Якщо "атакуючі" та "нормальні" запити потрапляють на різні системи, атака не вдасться. Цей аспект балансування навантаження може вимагати кількох спроб для підтвердження вразливості. -- **Непередбачений вплив на користувачів:** Якщо ваша атака ненавмисно впливає на запит іншого користувача (не "нормальний" запит, який ви надіслали для виявлення), це вказує на те, що ваша атака вплинула на іншого користувача додатка. Постійне тестування може порушити роботу інших користувачів, що вимагає обережного підходу. +- **Таймінг та умови гонки:** "Нормальний" запит, призначений для виявлення втручання з боку "атакуючого" запиту, змагається з іншими одночасними запитами додатка. Тому надсилайте "нормальний" запит відразу після "атакуючого" запиту. Завантажені додатки можуть вимагати кількох спроб для остаточного підтвердження вразливості. +- **Виклики балансування навантаження:** Сервери на передньому плані, які виконують функції балансування навантаження, можуть розподіляти запити між різними системами на задньому плані. Якщо "атакуючі" та "нормальні" запити потрапляють на різні системи, атака не вдасться. Цей аспект балансування навантаження може вимагати кількох спроб для підтвердження вразливості. +- **Непередбачуваний вплив на користувачів:** Якщо ваша атака ненавмисно впливає на запит іншого користувача (не "нормальний" запит, який ви надіслали для виявлення), це вказує на те, що ваша атака вплинула на іншого користувача додатка. Постійне тестування може порушити роботу інших користувачів, що вимагає обережного підходу. ## Розрізнення артефактів HTTP/1.1 pipelining та справжнього request smuggling -Повторне використання з'єднань (keep-alive) та pipelining можуть легко створювати ілюзії "smuggling" в тестових інструментах, які надсилають кілька запитів на одному сокеті. Навчіться відокремлювати безпечні артефакти на стороні клієнта від справжнього десинхронізації на стороні сервера. +Повторне використання з'єднання (keep-alive) та pipelining можуть легко створювати ілюзії "smuggling" в тестових інструментах, які надсилають кілька запитів на одному сокеті. Навчіться відокремлювати безпечні артефакти на стороні клієнта від реального десинхронізації на стороні сервера. ### Чому pipelining створює класичні хибнопозитивні результати -HTTP/1.1 повторно використовує одне TCP/TLS з'єднання та об'єднує запити та відповіді в одному потоці. У pipelining клієнт надсилає кілька запитів один за одним і покладається на відповіді в порядку надходження. Загальним хибнопозитивним результатом є повторна відправка неправильно сформованого навантаження CL.0 двічі на одному з'єднанні: +HTTP/1.1 повторно використовує одне TCP/TLS з'єднання та конкатенує запити та відповіді в одному потоці. У pipelining клієнт надсилає кілька запитів один за одним і покладається на відповіді в порядку. Загальним хибнопозитивним результатом є повторна відправка неправильно сформованого навантаження CL.0 двічі на одному з'єднанні: ``` POST / HTTP/1.1 Host: hackxor.net @@ -341,22 +341,22 @@ Impact: жодного. Ви просто десинхронізували св - Шукайте відмінності між першим і наступними запитами на одному TCP-з'єднанні (маршрутизація/перевірка першого запиту). - Burp "HTTP Request Smuggler" включає пробу стану з'єднання, яка автоматизує це. 5. Візуалізуйте з'єднання -- Використовуйте розширення Burp "HTTP Hacker", щоб безпосередньо перевіряти конкатенацію та фреймування повідомлень під час експериментів з повторним використанням та частковими запитами. +- Використовуйте розширення Burp "HTTP Hacker" для безпосереднього огляду конкатенації та фреймування повідомлень під час експериментів з повторним використанням та частковими запитами. ### Десинхронізація запитів, заблокованих за з'єднанням (вимагає повторного використання) Деякі фронтенди повторно використовують з'єднання з бекендом лише тоді, коли клієнт повторно використовує своє. Реальна контрабанда існує, але залежить від повторного використання на стороні клієнта. Щоб відрізнити та довести вплив: - Доведіть помилку на стороні сервера - Використовуйте перевірку вкладених відповідей HTTP/2, або -- Використовуйте часткові запити, щоб показати, що ФЕ повторно використовує з'єднання з бекендом лише тоді, коли клієнт це робить. +- Використовуйте часткові запити, щоб показати, що ФЕ повторно використовує з'єднання з бекендом лише тоді, коли це робить клієнт. - Показуйте реальний вплив, навіть якщо пряма зловживання сокетом між користувачами заблокована: - Отруєння кешу: отруюйте спільні кеші через десинхронізацію, щоб відповіді впливали на інших користувачів. -- Внутрішнє розкриття заголовків: відображайте заголовки, інжектовані ФЕ (наприклад, заголовки автентифікації/достовірності) та переходьте до обходу автентифікації. +- Розкриття внутрішніх заголовків: відображайте заголовки, інжектовані ФЕ (наприклад, заголовки автентифікації/достовірності), і переходьте до обходу автентифікації. - Обхід контролю ФЕ: контрабандно пропускайте обмежені шляхи/методи повз фронтенд. - Зловживання заголовком хоста: комбінуйте з особливостями маршрутизації хоста, щоб перейти до внутрішніх віртуальних хостів. - Робочий процес оператора -- Відтворіть з контрольованим повторним використанням (Turbo Intruder `requestsPerConnection=2`, або група вкладок Burp Repeater → "Відправити групу послідовно (одне з'єднання)"). -- Потім з'єднайте з примітивами отруєння кешу/розкриття заголовків/обходу контролю та продемонструйте вплив між користувачами або авторизацією. +- Відтворіть з контрольованим повторним використанням (Turbo Intruder `requestsPerConnection=2`, або вкладка Burp Repeater → "Відправити групу послідовно (одне з'єднання)"). +- Потім з'єднайте з примітивами отруєння кешу/витоку заголовків/обходу контролю та продемонструйте вплив між користувачами або авторизацією. > Дивіться також атаки на стан з'єднання, які тісно пов'язані, але технічно не є контрабандою: > @@ -366,12 +366,12 @@ Impact: жодного. Ви просто десинхронізували св ### Обмеження десинхронізації на стороні клієнта -Якщо ви націлені на десинхронізацію, що викликана браузером/на стороні клієнта, зловмисний запит повинен бути відправлений браузером з крос-доменом. Трюки з обфускацією заголовків не спрацюють. Зосередьтеся на примітивах, доступних через навігацію/отримання, а потім переходьте до отруєння кешу, розкриття заголовків або обходу контролю фронтенду, де компоненти нижнього рівня відображають або кешують відповіді. +Якщо ви націлені на десинхронізацію, що викликана браузером/на стороні клієнта, зловмисний запит повинен бути відправлений браузером з крос-доменом. Трюки з обфускацією заголовків не спрацюють. Зосередьтеся на примітивах, доступних через навігацію/отримання, а потім переходьте до отруєння кешу, розкриття заголовків або обходу контролю фронтенда, де компоненти нижнього рівня відображають або кешують відповіді. -Для фону та кінцевих робочих процесів: +Для фону та робочих процесів від початку до кінця: {{#ref}} --browser-http-request-smuggling.md +browser-http-request-smuggling.md {{#endref}} ### Інструменти для допомоги у прийнятті рішень @@ -382,15 +382,15 @@ Impact: жодного. Ви просто десинхронізували св - Burp HTTP Request Smuggler: включає пробу стану з'єднання для виявлення маршрутизації/перевірки першого запиту. > [!NOTE] -> Вважайте ефекти лише з повторним використанням незначними, якщо ви не можете довести десинхронізацію на стороні сервера та прикріпити конкретний вплив (артефакт отруєного кешу, розкритий внутрішній заголовок, що дозволяє обхід привілеїв, обхід контролю ФЕ тощо). +> Вважайте ефекти лише з повторним використанням незначними, якщо ви не можете довести десинхронізацію на стороні сервера та прикріпити конкретний вплив (артефакт отруєного кешу, витік внутрішнього заголовка, що дозволяє обійти привілеї, обхід контролю ФЕ тощо). ## Зловживання HTTP Request Smuggling -### Обхід безпеки фронтенду через HTTP Request Smuggling +### Обхід безпеки фронтенда через HTTP Request Smuggling -Іноді фронтенд-проксі впроваджують заходи безпеки, ретельно перевіряючи вхідні запити. Однак ці заходи можуть бути обійдені шляхом експлуатації HTTP Request Smuggling, що дозволяє несанкціонований доступ до обмежених кінцевих точок. Наприклад, доступ до `/admin` може бути заборонений зовні, при цьому фронтенд-проксі активно блокує такі спроби. Проте цей проксі може не перевіряти вбудовані запити в межах контрабандного HTTP-запиту, залишаючи лазівку для обходу цих обмежень. +Іноді проксі-сервери фронтенда застосовують заходи безпеки, ретельно перевіряючи вхідні запити. Однак ці заходи можуть бути обійдені шляхом експлуатації HTTP Request Smuggling, що дозволяє несанкціонований доступ до обмежених кінцевих точок. Наприклад, доступ до `/admin` може бути заборонений зовні, при цьому проксі-фронтенда активно блокує такі спроби. Проте цей проксі може не перевіряти вбудовані запити в межах контрабандного HTTP-запиту, залишаючи лазівку для обходу цих обмежень. -Розгляньте наступні приклади, які ілюструють, як HTTP Request Smuggling може бути використано для обходу контролю безпеки фронтенду, зокрема націлюючись на шлях `/admin`, який зазвичай охороняється фронтенд-проксі: +Розгляньте наступні приклади, які ілюструють, як HTTP Request Smuggling може бути використано для обходу контролю безпеки фронтенда, зокрема націлюючись на шлях `/admin`, який зазвичай охороняється проксі-фронтенда: **CL.TE Приклад** ``` @@ -460,7 +460,7 @@ search= ### Capturing other users' requests -Цілком можливо захопити запити наступного користувача, додавши конкретний запит як значення параметра під час операції POST. Ось як це можна здійснити: +Можливо захопити запити наступного користувача, додавши конкретний запит як значення параметра під час операції POST. Ось як це можна здійснити: Додавши наступний запит як значення параметра, ви можете зберегти запит наступного клієнта: ``` @@ -518,24 +518,24 @@ A= ``` Цей payload структурований для експлуатації вразливості шляхом: -1. Ініціювання `POST` запиту, що виглядає типовим, з заголовком `Transfer-Encoding: chunked`, щоб вказати на початок контрабанди. +1. Ініціювання `POST` запиту, що виглядає типовим, з заголовком `Transfer-Encoding: chunked`, щоб вказати на початок смугування. 2. Наступним є `0`, що позначає кінець тіла повідомлення з частинами. -3. Потім вводиться контрабандний `GET` запит, де заголовок `User-Agent` інжектується зі скриптом, ``, що викликає XSS, коли сервер обробляє цей наступний запит. +3. Потім вводиться смугований `GET` запит, де заголовок `User-Agent` інжектується зі скриптом, ``, що викликає XSS, коли сервер обробляє цей наступний запит. -Маніпулюючи `User-Agent` через контрабанду, payload обходить звичайні обмеження запитів, таким чином експлуатуючи вразливість Reflected XSS нестандартним, але ефективним способом. +Маніпулюючи `User-Agent` через смугування, 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** дієслова та **не** відповідає з **заголовками**, лише тілом. -У [**цьому описі**](https://mizu.re/post/twisty-python) це було зловжито з контрабандою запиту та **вразливим кінцевим пунктом, який відповість з вхідними даними користувача** для контрабанди запиту з HTTP/0.9. Параметр, який буде відображено у відповіді, містив **підроблену HTTP/1.1 відповідь (з заголовками та тілом)**, тому відповідь міститиме дійсний виконуваний JS код з `Content-Type` `text/html`. +У [**цьому описі**](https://mizu.re/post/twisty-python) це було зловжито з допомогою смугування запитів та **вразливого кінцевого пункту, який відповість з вхідними даними користувача** для смугування запиту з HTTP/0.9. Параметр, який буде відображено у відповіді, містив **підроблену HTTP/1.1 відповідь (з заголовками та тілом)**, тому відповідь міститиме дійсний виконуваний JS код з `Content-Type` `text/html`. ### Експлуатація перенаправлень на сайті з допомогою HTTP Request Smuggling -Застосунки часто перенаправляють з одного URL на інший, використовуючи ім'я хоста з заголовка `Host` у URL перенаправлення. Це поширено серед веб-серверів, таких як Apache та IIS. Наприклад, запит на папку без слешу в кінці призводить до перенаправлення, щоб включити слеш: +Застосунки часто перенаправляють з одного URL на інший, використовуючи ім'я хоста з заголовка `Host` у URL перенаправлення. Це поширено серед веб-серверів, таких як Apache та IIS. Наприклад, запит на папку без заключного слешу призводить до перенаправлення, щоб включити слеш: ``` GET /home HTTP/1.1 Host: normal-website.com @@ -599,20 +599,20 @@ Content-Length: 10 x=1 ``` -Зверніть увагу на вбудований запит, що націлений на `/post/next?postId=3`. Цей запит буде перенаправлено на `/post?postId=4`, використовуючи **значення заголовка Host** для визначення домену. Змінивши **заголовок Host**, зловмисник може перенаправити запит на свій домен (**внутрішнє перенаправлення на відкритий редирект**). +Зверніть увагу на вбудований запит, що націлений на `/post/next?postId=3`. Цей запит буде перенаправлений на `/post?postId=4`, використовуючи **значення заголовка Host** для визначення домену. Змінивши **заголовок Host**, зловмисник може перенаправити запит на свій домен (**внутрішнє перенаправлення на відкритий редирект**). Після успішного **отруєння сокета** слід ініціювати **GET запит** на `/static/include.js`. Цей запит буде забруднений попереднім запитом **внутрішнього перенаправлення на відкритий редирект** і отримає вміст скрипта, контрольованого зловмисником. -В подальшому будь-який запит на `/static/include.js` буде подавати кешований вміст скрипта зловмисника, ефективно запускаючи широкий XSS-атаку. +В подальшому будь-який запит на `/static/include.js` буде обслуговувати кешований вміст скрипта зловмисника, ефективно запускаючи широкий XSS-атаку. ### Використання HTTP request smuggling для виконання обману веб-кешу > **У чому різниця між отруєнням веб-кешу та обманом веб-кешу?** > -> - У **отруєнні веб-кешу** зловмисник змушує додаток зберігати деякий шкідливий вміст у кеші, і цей вміст подається з кешу іншим користувачам додатка. +> - У **отруєнні веб-кешу** зловмисник змушує додаток зберігати деякий шкідливий вміст у кеші, і цей вміст обслуговується з кешу іншим користувачам додатка. > - У **обмані веб-кешу** зловмисник змушує додаток зберігати деякий чутливий вміст, що належить іншому користувачу, у кеші, а потім зловмисник отримує цей вміст з кешу. -Зловмисник створює підроблений запит, який отримує чутливий вміст, специфічний для користувача. Розгляньте наступний приклад: +Зловмисник створює контрабандний запит, який отримує чутливий вміст, специфічний для користувача. Розгляньте наступний приклад: ```markdown `POST / HTTP/1.1`\ `Host: vulnerable-website.com`\ @@ -627,7 +627,7 @@ x=1 ### Зловживання TRACE через HTTP Request Smuggling -[**У цьому пості**](https://portswigger.net/research/trace-desync-attack) пропонується, що якщо сервер має метод TRACE увімкненим, його можна зловживати за допомогою HTTP Request Smuggling. Це пов'язано з тим, що цей метод відображатиме будь-який заголовок, надісланий на сервер, як частину тіла відповіді. Наприклад: +[**У цьому пості**](https://portswigger.net/research/trace-desync-attack) пропонується, що якщо сервер має метод TRACE увімкненим, це може бути можливим зловживання з HTTP Request Smuggling. Це пов'язано з тим, що цей метод відображатиме будь-який заголовок, надісланий на сервер, як частину тіла відповіді. Наприклад: ``` TRACE / HTTP/1.1 Host: example.com @@ -673,7 +673,7 @@ Content-Length: 44\r\n \r\n ``` -Згенерує ці ці responses (зверніть увагу, що відповідь HEAD має Content-Length, що робить відповідь TRACE частиною тіла HEAD, і як тільки закінчується Content-Length HEAD, дійсна HTTP відповідь проникає): +Згенерує ці ці responses (зверніть увагу, як HEAD response має Content-Length, що робить TRACE response частиною тіла HEAD, і як тільки закінчується Content-Length HEAD, дійсний HTTP response проникає): ``` HTTP/1.1 200 OK Content-Type: text/html @@ -704,13 +704,13 @@ Content-Length: 50 ### Інші техніки HTTP Request Smuggling -- HTTP Request Smuggling у браузері (Клієнтська сторона) +- HTTP Request Smuggling в браузері (Клієнтська сторона) {{#ref}} browser-http-request-smuggling.md {{#endref}} -- Request Smuggling у зниженні версії HTTP/2 +- Request Smuggling в HTTP/2 Downgrades {{#ref}} request-smuggling-in-http-2-downgrades.md @@ -812,7 +812,7 @@ 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, корисним для виявлення дивних розбіжностей у запитах на контрабанду. +- [https://github.com/bahruzjabiyev/t-reqs-http-fuzzer](https://github.com/bahruzjabiyev/t-reqs-http-fuzzer): Цей інструмент є граматично-орієнтованим HTTP Fuzzer, корисним для виявлення дивних розбіжностей у смугуванні запитів. ## Посилання @@ -825,7 +825,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 фреймування від контрабанди запитів – [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 від смугування запитів – [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/) - Атаки Desync, що використовують браузер – [https://portswigger.net/research/browser-powered-desync-attacks](https://portswigger.net/research/browser-powered-desync-attacks) - PortSwigger Academy – десинхронізація на стороні клієнта – [https://portswigger.net/web-security/request-smuggling/browser/client-side-desync](https://portswigger.net/web-security/request-smuggling/browser/client-side-desync)