Web14: Проблемы безопасности в протоколе HTTP

В этой статье представлены некоторые проблемы безопасности протокола HTTP, поднятые в двух документах RFC 7230 и RFC 7231. Примеры в статье о конкретных ошибках взяты из OWASP.

1. Риски от промежуточных факторов

HTTP позволяет использовать посредников для ответа на запросы посредством серии соединений. Существует три общих промежуточных элемента: прокси, шлюз и туннель.

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

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

Пользователи должны знать об опасностях использования ненадежных прокси или шлюзов.

2. Разделение ответов

Разделение ответов (также известное как внедрение CRLF) — популярный метод веб-эксплойтов. Злоумышленник отправляет закодированные данные в некоторых параметрах запроса, которые затем декодируются и повторяются в определенном поле заголовка ответа.

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

Контрабанда запросов — это метод, который использует различия в обработке запросов разными типами серверов, чтобы скрыть, казалось бы, безобидные запросы, добавленные к исходному запросу.

Давайте рассмотрим следующий пример:

Предположим, запрос POST содержит в заголовке два поля Content-length с двумя разными значениями. Некоторые серверы отклонят этот запрос (IIS и Apache), а другие — нет. Например, SunONE W/S 6.1 сначала использует поле Content-length, а sunONE Proxy 3.6 — во вторую.

Предполагая, что SITE является DNS SunONE W/S, расположенным за прокси-сервером SunONE, на SunONE W/S находится файл яда.html. Вот как можно использовать подсказку HTTP-запроса на основе несогласованности обработки между двумя серверами:

(Обратите внимание, что каждая строка заканчивается CRLF (”), кроме строки 10)

Давайте рассмотрим, что происходит, когда запрос отправляется на W/S через прокси-сервер. Сначала прокси проанализирует запрос из строк с 1 по 7 (синий) и обнаружит два поля Content-Length. Как упоминалось выше, он проигнорирует первое поле и поймет, что длина тела запроса составляет 44 байта. Поэтому он рассматривает данные из строк 8–10 как тело первого запроса (в строках 8–10 данные имеют длину ровно 44 байта). Затем прокси-сервер проанализирует строки с 11 по 14 (красные) как второй запрос клиента.

Теперь давайте посмотрим, как W/S интерпретирует приведенные выше данные, пересылаемые с прокси. В отличие от прокси, W/S будет использовать первое поле Content-Length и интерпретировать его следующим образом: первый запрос не имеет тела, а второй запрос начинается со строки 8 (обратите внимание, что W/S будет анализировать, начиная со строки 11, как значение месторождения Бла).

Далее давайте посмотрим, как ответ возвращается клиенту. Запрос, который понимает W/S, — это «POST /foobar.html» (из строки 1) и «GET /poison.html» (из строки 8), поэтому он отправит клиенту 2 ответа с содержимым страницы foobar. html и яд.html. Прокси понимает, что эти 2 ответа соответствуют 2 запросам: «POST/foobar.html» (из строки 1) и «GET /page_to_poison.html» (строка 11). Прокси-сервер будет кэшировать содержимое страницы Poison.html, соответствующее URL-адресу «page_to_poison.html» (отравление кэша). Оттуда, когда клиент запрашивает «page_to_poison.html», он получит содержимое страницы Poison.html.

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

Например, UNIX, Microsoft Windows и некоторые другие операционные системы используют «.». как элемент пути для представления каталога на один уровень выше текущего файла/каталога. Без надлежащего контроля ввода и авторизации доступ к конфиденциальным файлам/папкам системы можно получить путем ввода путей, указывающих на эти файлы/папки.

5. Типы атак: внедрение команд, внедрение кода, внедрение запроса.

(Веб-серверы часто используют параметры в URI в качестве входных данных для выполнения системных команд и запросов к базе данных. Однако данным, полученным в запросе, не всегда можно доверять. Злоумышленник может создавать и изменять компоненты запроса (например, методы, поля в заголовок, тело.), для выполнения системных команд, запроса к базе данных.

Например, SQL-инъекция — это распространенная атака, при которой веб-сервер получает параметры в URI, которые являются частью SQL-запроса. Таким образом, злоумышленник может обманом заставить веб-сервер выполнить незаконные SQL-запросы, чтобы украсть или саботировать базу данных.
Как правило, данные, предоставленные пользователями, не должны использоваться непосредственно для выполнения операций на сервере. Эти данные должны пройти через фильтры, которые определяют, что действительно, а что нет, тем самым удаляя ненужные данные.

6. Раскрытие личной информации

Клиенты часто содержат много личной информации, включая информацию, предоставленную пользователем для взаимодействия с сервером (например, имя пользователя, пароль, местоположение, адрес электронной почты и т. д.), а также информацию о действиях в Интернете. пользователя (история, закладки и т.п.). При реализации следует обратить внимание на предотвращение точек, которые могут раскрыть эту личную информацию.

7. Раскрытие конфиденциальной информации в URI

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

Избегайте использования метода GET для отправки личной информации на сервер, поскольку она будет отображаться в URI. Вместо этого используйте метод POST.

8. Раскрытие информации об используемом программном обеспечении

В приведенной выше статье вы познакомились с «Web14: проблемы безопасности в протоколе HTTP». СоветыНадейтесь, что эта статья вам поможет! Если эта статья кажется вам интересной и полезной, не забудьте поделиться ею. Спасибо!