Понимание внедрения CRLF: уязвимость веб-приложения и меры по ее устранению

Главная » Кибербезопасность » Безопасность приложений » Понимание внедрения CRLF: уязвимость веб-приложения и меры по ее устранению

Внедрение CRLF (возврата каретки) — это уязвимость веб-приложения, которая возникает, когда злоумышленник может ввести вредоносные символы CRLF в ответ HTTP. Эта уязвимость может привести к различным проблемам безопасности, таким как внедрение HTTP-заголовка, разделение HTTP-ответа, фиксация сеанса, межсайтовый скриптинг (XSS) и отравление кеша.

Чтобы понять внедрение CRLF, давайте разберем этот термин:

Возврат каретки (CR):Это управляющий символ (код ASCII 13), который указывает курсору вернуться в начало текущей строки.

Перевод строки (LF):Это управляющий символ (код ASCII 10), который указывает курсору перейти на следующую строку.

В контексте HTTP CRLF относится к последовательности символов CR и LF («\r\n»). Эти символы используются для разделения строк в протоколе HTTP.

Уязвимость внедрения CRLF возникает, когда контролируемые пользователем данные (входные данные) не очищаются или не проверяются должным образом перед использованием при построении HTTP-ответа. Злоумышленники используют эту уязвимость, вводя символы CRLF во ввод пользователя с целью манипулирования ответом HTTP.

Внедрение CRLF может использоваться как часть цепочки уязвимостей для использования различных проблем безопасности. Вот несколько распространенных уязвимостей цепочки, которые можно использовать вместе с внедрением CRLF:

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

Пример:

Давайте рассмотрим другой пример, где сегмент кода считывает адрес электронной почты пользователя из HTTP-запроса и устанавливает его в качестве заголовка cookie в ответе HTTP:

В этом примере приложение берет адрес электронной почты, указанный в запросе, и устанавливает его в качестве файла cookie с именем «user_email» в ответе HTTP.

Предположим, в запросе указан адрес электронной почты «[email protected]». HTTP-ответ, включающий этот файл cookie, может выглядеть следующим образом:

Этот ответ сохраняет заданную форму, поскольку входные данные («[email protected]») представляют собой действительный адрес электронной почты без вредоносных символов.

Теперь давайте рассмотрим, что произойдет, если злоумышленник отправит вредоносный адрес электронной почты, содержащий символы CRLF:

Значение параметра «email» — «john.doe%40example.com%0d%0aSet-Cookie%3A+admin%3Dtrue%0d%0a». Когда приложение обрабатывает этот ввод и устанавливает файл cookie, ответом HTTP можно манипулировать следующим образом:

В этом случае злоумышленник ввел символы CRLF («%0d%0a») в параметр электронной почты, что привело к вставке дополнительного заголовка «Set-Cookie» в ответ. Злоумышленник фактически установил другой файл cookie с именем «admin» и значением «true». Это может быть использовано для повышения привилегий или других атак, связанных с безопасностью.

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

Пример:

Давайте создадим полезную нагрузку для эскалации CRLF в межсайтовый скриптинг (XSS):

Выполняя VAPT (оценку уязвимостей и тестирование на проникновение) в веб-приложении, я обнаружил потенциальную уязвимость CRLF (перевод строки с возвратом каретки). Пожалуйста, найдите объяснение обнаружения и использования уязвимости CRLF с подтверждением концепции:

При добавлении комментария все ненужные заголовки и контент попадают под комментарий. Используется комментарий HTML, поскольку ответ имеет заголовок Content-Type:text/html.