Привет, Хабровчане! В преддверии старта занятий в ближайшей группе профессионального курса «Безопасность веб-приложений», мы подготовили для вас еще один полезный перевод.
Что такое 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=editHTTP 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-заголовки.
Таблица классификации уязвимостей и их степени тяжести
Подробнее о курсе «Безопасность веб-приложений»
