Что нового

Article CRLF Injection & HTTP Response Splitting

Vander 0

Vander

Команда форума
10.11.2019
491
1 128
Всем привет, в этой статье поговорим об очередных атаках на web-приложения под названием CRLF Injection и HTTP Response Splitting.

crlf-http-header.jpg

Когда браузер отправляет запрос на веб-сервер, веб-сервер отвечает ответом, содержащим как заголовки ответа HTTP, так и фактическое содержимое веб-сайта, то есть тело ответа. Заголовки HTTP и ответ HTML (содержимое веб-сайта) разделены определенной комбинацией специальных символов, а именно возврата каретки и перевода строки. Для краткости они также известны как CRLF.
  • Перевод строки, или разрыв строки - продолжение печати текста с новой строки, то есть с левого края на строку ниже, или уже на следующей странице.
Веб-сервер использует CRLF, чтобы понять, когда начинается новый заголовок HTTP и заканчивается другой. CRLF также может сообщить веб-приложению или пользователю, что в файле или текстовом блоке начинается новая строка. Символы CRLF представляют собой стандартное сообщение HTTP / 1.1, поэтому оно используется любым типом веб-сервера, включая Apache, Microsoft IIS и все остальные.

Что такое уязвимость CRLF - Injection?

При атаке с использованием CRLF-инъекции злоумышленник вставляет символы возврата каретки и перевода строки в пользовательский ввод, чтобы обмануть сервер, веб-приложение или пользователя, заставляя думать, что один объект завершен, а другой запущен. Таким образом, последовательности CRLF не являются вредоносными символами, однако они могут использоваться для злонамеренных действий, для разделения HTTP-ответа и т.д.

CRLF - Injection в web-приложениях

В веб-приложениях внедрение CRLF может иметь серьезные последствия в зависимости от того, что приложение делает с отдельными элементами. Воздействие может варьироваться от раскрытия информации до выполнения кода, что напрямую влияет на безопасность веб-приложений. Фактически, атака с использованием CRLF-инъекции может иметь очень серьезные последствия для веб-приложения, даже если она никогда не входила в список OWASP Top 10. Например, так можно управлять файлами журнала в панели администратора, как описано в приведенном ниже примере.

Пример CRLF - Injection в файл журнала

Представьте себе файл журнала в панели администратора с шаблоном выходного потока IP - Time - Visited Path (IP - Время - Посещенный путь), как показано ниже:

Код:
123.123.123.123 - 08:15 - /index.php?page=home
Если злоумышленник может ввести символы 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 (IP - Время - Посещенный путь)

Код:
123.123.123.123 - 08:15 - /index.php?page=home&
127.0.0.1 - 08:15 - /index.php?page=home&restrictedaction=edit
Следовательно, используя уязвимость внедрения CRLF, злоумышленник может подделать записи в файле журнала, чтобы скрыть свои вредоносные действия. Злоумышленник буквально перехватывает страницу и изменяет ответ. Например, представьте сценарий, в котором злоумышленник имеет пароль администратора и выполняет параметр ограниченного действия, который может использоваться только администратором.

Проблема в том, что если администратор заметит, что неизвестный IP-адрес использовал параметр ограниченного действия, он поймет, что что-то не так. Однако, поскольку теперь похоже, что команда была отправлена локальным хостом (и, следовательно, вероятно, кем-то, у кого есть доступ к серверу, например, администратором), это не выглядит подозрительно.

Вся часть запроса, начинающаяся с %0d%0a, будет обработана сервером как один параметр. После этого идет еще один & с параметром limitedaction, который будет анализироваться сервером как другой параметр. Фактически это будет тот же запрос, что и:

Код:
/index.php?page=home&restrictedaction=edit
HTTP Response Splitting

1600630648132.png

Поскольку заголовок HTTP-ответа и его тело разделены символами CRLF, злоумышленник может попытаться ввести их. Комбинация CRLFCRLF сообщит браузеру, что заголовок заканчивается и начинается тело. Это означает, что теперь он может записывать данные в тело ответа, где хранится HTML-код. Это может привести к уязвимости Cross-site Scripting - XSS.

Пример HTTP Response Splitting, ведущего к XSS

Представьте себе приложение, которое устанавливает собственный заголовок, например:

Код:
X-Your-Name: Bob
Значение заголовка устанавливается с помощью параметра получения с именем «name». Если кодировка URL-адреса отсутствует и значение напрямую отражается внутри заголовка, злоумышленник может вставить вышеупомянутую комбинацию CRLFCRLF, чтобы сообщить браузеру, что начинается тело запроса. Таким образом, он может вставлять такие данные, как полезная нагрузка XSS, например:

Код:
?name=Bob%0d%0a%0d%0a<script>alert(document.domain)</script>
Вышеуказанное отобразит окно предупреждения в контексте атакованного домена.

HTTP Header Injection

A-Header-Injection-Attack.png

Используя CRLF-инъекцию, злоумышленник также может вставлять заголовки HTTP, которые могут использоваться для взлома механизмов безопасности, таких как фильтр XSS браузера или политика того же происхождения. Это позволяет злоумышленнику получить конфиденциальную информацию, такую как токены CSRF. Он также может установить файлы cookie, которые могут быть использованы путем регистрации жертвы в учетной записи злоумышленника или путем использования в противном случае неработоспособных уязвимостей межсайтового скриптинга (XSS).

Пример внедрения заголовка HTTP для извлечения конфиденциальных данных

Если злоумышленник может внедрить заголовки HTTP, которые активируют CORS (совместное использование ресурсов между источниками), он может использовать javascript для доступа к ресурсам, которые в противном случае защищены SOP (Same Origin Policy), которая предотвращает доступ сайтов из разных источников друг к другу.

Импакт уязвимостей, связанных с инъекцией CRLF

Влияние внедрения CRLF различается и также включает все воздействия межсайтового скриптинга на раскрытие информации. Он также может деактивировать определенные ограничения безопасности, такие как фильтры XSS и Same Origin Policy, в браузерах жертвы, делая их уязвимыми для злонамеренных атак.
  • Правило ограничения домена (Same Origin Policy, в переводе с англ. — «Принцип одинакового источника») — это важная концепция безопасности для некоторых языков программирования на стороне клиента, таких как JavaScript. Политика разрешает сценариям, находящимся на страницах одного сайта, доступ к методам и свойствам друг друга без ограничений, но предотвращает доступ к большинству методов и свойств для страниц на разных сайтах. Одинаковые источники — это источники, у которых совпадают три признака:
    1. домен;
    2. порт;
    3. протокол.
Как предотвратить инъекции заголовков CRLF / HTTP в веб-приложениях?

Лучшая методика предотвращения - не использовать вводимые пользователем данные непосредственно внутри заголовков ответов. Если это невозможно, вы всегда должны использовать функцию для кодирования специальных символов CRLF. Еще одна хорошая практика обеспечения безопасности веб-приложений - обновить язык программирования до версии, которая не позволяет вставлять CR и LF внутри функций, устанавливающих заголовки HTTP.

Классификация уязвимостей и рейтинг опасности уязвимостей описанных в этой статье

1600632189801.png


Спасибо за внимание, материал подготовлен специально для protey.net
 
Верх Низ