Русский
Русский
English
Статистика
Реклама

Http response splitting

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

23.07.2020 18:11:16 | Автор: admin

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




Что такое 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-заголовки.


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





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



Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru