Crlf-Инъекции И Разделение Http-Ответов

Здравствуйте, хабровчане! В ожидании начала занятий в следующей группе профессионального курса «Безопасность веб-приложений» , мы подготовили для вас еще один полезный перевод.






CRLF-инъекции и разделение HTTP-ответов



Что такое КРЛФ?

Когда браузер отправляет запрос на веб-сервер, он отправляет ответ, содержащий заголовки ответа HTTP и само содержимое сайта, то есть тело ответа.

Заголовки HTTP и ответ HTML (содержимое сайта) разделяются определенной комбинацией специальных символов, а именно возвратом каретки и переводом строки.

Это сокращенно CRLF. Веб-сервер использует CRLF, чтобы понять, где начинается новый HTTP-заголовок и заканчивается старый.

CRLF также может сообщить веб-приложению или пользователю, что в файле или блоке текста начинается новая строка.

Символы CRLF представляют собой стандартное сообщение HTTP/1.1, поэтому они используются веб-серверами любого типа, включая Апач , Microsoft IIS и другие.



CRLF-инъекции и разделение HTTP-ответов



Что такое инъекция CRLF?

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

Таким образом, последовательности CRLF сами по себе не являются вредоносными символами, но могут быть использованы злоумышленниками для разделения HTTP-ответов (HTTP Response Splitting).



Внедрение CRLF в веб-приложения

Для веб-приложений внедрение CRLF может иметь серьезные последствия, в зависимости от того, как приложение обрабатывает данные.

Последствия могут варьироваться от раскрытия конфиденциальной информации до выполнения вредоносного кода, что напрямую влияет на уровень безопасности веб-приложения.

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



Пример внедрения CRLF в логи

Представьте себе файл журнала в админ-панели с шаблоном выходного потока.

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 — символы CR и LF в URL-кодировке.

Таким образом, после того как злоумышленник вставит эти символы и приложение их выведет, логи будут выглядеть так: 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, будет обработана сервером как один параметр.

После этого появится еще один & с параметром ограниченное действие , который будет воспринят сервером как еще один параметр.

По сути, это будет тот же запрос, что и:

/index.phpЭpage=home&restrictedaction=edit



Разделение HTTP-ответа



Описание

Поскольку заголовок и тело ответа HTTP разделены символами CRLF, злоумышленник может попытаться внедрить их.

CRLFCRLF сообщит браузеру, что заголовок заканчивается и начинается тело.

Это означает, что теперь он может записывать данные в тело ответа, где находится HTML-код. Это может привести к уязвимости межсайтового скриптинга.



Пример разделения HTTP-ответа, приводящего к XSS

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

X-Your-Name: Bob

Значение заголовка устанавливается с помощью параметра GET «имя».

Если кодировка URL-адреса отсутствует и значение просто содержится в заголовке, злоумышленник может вставить указанную выше комбинацию CRLFCRLF, чтобы сообщить браузеру о необходимости запуска тела запроса.

Таким образом, он может вставлять данные, например полезную нагрузку XSS:

Эname=Bob%0d%0a%0d%0a<script>alert(document.domain)</script>

Вышеуказанное отобразит окно предупреждения в контексте атакованного домена.



Внедрение HTTP-заголовка



Описание

Используя внедрение CRLF, злоумышленник также может вставлять заголовки HTTP, которые можно использовать для обхода механизмов безопасности, таких как XSS-фильтр браузера или политика одного и того же происхождения.

Таким образом, злоумышленник может получить конфиденциальную информацию, такую как токены CSRF. Он даже может устанавливать файлы cookie, которые можно использовать, зарегистрировав жертву в учетной записи злоумышленника или воспользовавшись уязвимостью.

межсайтовый скриптинг (XSS) .



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

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



Последствия инъекции CRLF

Последствия внедрения CRLF различаются и могут включать в себя все последствия XSS и раскрытия конфиденциальной информации.

Таким образом, можно отключить некоторые ограничения безопасности, такие как XSS-фильтры и политику одинакового происхождения, в браузерах жертвы, что делает их уязвимыми для вредоносных атак.



Как предотвратить внедрение заголовков CRLF/HTTP в веб-приложениях

Лучший метод предотвращения — не использовать пользовательский ввод непосредственно в заголовке ответа.

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



Таблица классификации уязвимостей и их серьезности



CRLF-инъекции и разделение HTTP-ответов




Подробнее о курсе «Безопасность веб-приложений»


Теги: #информационная безопасность #разработка веб-сайтов #безопасность веб-приложений #otus #веб-безопасность #CRLF-инъекции #Разделение HTTP-ответов #CRLF/HTTP-инъекции
Вместе с данным постом часто просматривают:

Автор Статьи


Зарегистрирован: 2019-12-10 15:07:06
Баллов опыта: 0
Всего постов на сайте: 0
Всего комментарий на сайте: 0
Dima Manisha

Dima Manisha

Эксперт Wmlog. Профессиональный веб-мастер, SEO-специалист, дизайнер, маркетолог и интернет-предприниматель.