Новости

[Перевод] CRLF-инъекции и HTTP Response Splitting

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


Что такое CRLF?

Когда браузер отправляет запрос веб-серверу, тот отправляет ответ, который содержит заголовки HTTP-ответа и сам контент сайта, то есть тело ответа. HTTP-заголовки и HTML-ответ (содержимое сайта) разделяются определенной комбинацией специальных символов, а именно возвратом каретки (carriage return) и подачей строки (line feed). Сокращается это как CRLF.

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

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

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

CRLF-инъекция в веб-приложениях

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

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

IP — Время – Путь

123.123.123.123 - 08:15 - /index.php?page=home&
127.0.0.1 - 08:15 - /index.php?page=home&restrictedaction=edit

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

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

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

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

HTTP Response Splitting

Описание

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

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

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

X-Your-Name: Bob

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

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

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

Инъекция в HTTP-заголовки

Описание

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

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

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

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

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

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

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

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


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


Добавить комментарий

Кнопка «Наверх»