CC BY
27Научная статья Original article УДК 004.424
ПОДДЕЛКА ЗАПРОСОВ НА СТОРОНЕ СЕРВЕРА
SERVER SIDE REQUEST FORGING (SSRF)
Казарян Каторина Камоевна студент специалитета, Донской государственный технический университет, г. Ростов-на-Дону (344003 Россия г. Ростов-на-Дону, Гагарина 1), kazaryan_katorina@mail.ru
Белан Виктория Вадимовна магистрант, Донской государственный технический университет, г. Ростов-на-Дону, г. Ростов-на-Дону (344003 Россия г. Ростов-на-Дону, Гагарина 1), viktoriyabelan2018@gmail.com
Kazaryan Katorina Kamoevna specialty student, Don State Technical University, Rostov-on-Don (344003 Russia, Rostov-on-Don, Gagarina 1), kazaryan_katorina@mail .ru
Belan Victoria Vadimovna Master student, Don State Technical University, Rostov-on-Don, Rostov-on-Don (344003 Russia, Rostov-on-Don, Gagarina 1), viktoriyabelan2018@gmail.com
Аннотация в статье описаны различные атаки с подделкой запросов на стороне сервера. Так же описан алгоритм атаки для более полного понимания работоспособности информационной системы в целом. Обычно
злоумышленники предоставляют URL-адрес (или изменяют существующий), и код, запущенный на сервере, считывает или отправляет на него данные. Злоумышленники могут использовать URL-адреса для получения доступа к внутренним данным и службам, которые не должны быть раскрыты, включая базы данных с поддержкой HTTP и данные конфигурации сервера.
Abstract This article describes various server-side request forgery attacks. The attack algorithm is also described for a more complete understanding of the health of the information system as a whole. Typically, attackers provide a URL (or modify an existing one) and code running on the server reads or sends data to it. Attackers can use URLs to gain access to internal data and services that should not be exposed, including HTTP-enabled databases and server configuration data.
Ключевые слова: атака с подделкой запросов на стороне сервера, разведка, настройка сервера
Keywords: server side request forgery attack, reconnaissance, server configuration
Атака с подделкой запросов на стороне сервера (SSRF) включает в себя злоумышленник, злоупотребляющий функциональными возможностями сервера для доступа или изменения ресурсов. Злоумышленник нацелен на приложение, которое поддерживает импорт данных с URL-адресов или позволяет им читать данные с URL-адресов. URL-адресами можно манипулировать, либо заменяя их новыми, либо вмешиваясь в обход пути URL-адреса.
Как только злоумышленник подделал запрос, сервер получает его и пытается прочитать данные по измененному URL-адресу. Даже для сервисов, которые не доступны напрямую в общедоступном Интернете, злоумышленники могут выбрать целевой URL-адрес, который позволяет им читать данные.
1.25 Объяснение рисков SSRF
Какой ущерб может нанести SSRF, полностью зависит от конфигурации систем и изобретательности злоумышленника. Вот некоторые общие риски SSRF.
Раскрытие данных
Один из наиболее распространенных примеров атаки SSRF - получение доступа к учетным данным инстанса Amazon EC2. Если роль IAM приписана экземпляру EC2, к временным учетным данным можно получить доступ, заполнив запрос на:приложений это обычно указывает на то, что, по крайней мере, киберпреступник сможет получить информацию о клиенте. Если роли IAM предоставлены чрезмерные разрешения, злоумышленники могут иметь возможность удаленно выполнять код на экземплярах EC2 в учетной записи AWS цели.
Разведка
Распространенной практикой безопасности, используемой для минимизации поверхности атаки из внешних сетей, является ограничение использования общедоступных серверов. Остальные серверы зарезервированы для внутренней связи. SSRF позволяет злоумышленникам выполнять сканирование и собирать информацию о внутренних сетях. Как только злоумышленник получил доступ к серверу, он может использовать эту информацию для компрометации других серверов в сети.
Сканирование портов или межсайтовая атака на порты (XSPA)
Атаки SSRF не всегда возвращают данные злоумышленнику. Однако время отклика или другие метаданные могут позволить злоумышленнику определить, был ли запрос успешным или нет. Если можно определить порт и хост, злоумышленник может сканировать порт в сети сервера приложений, используя эти метаданные в межсайтовой атаке на порты (XSPA).
Тайм-аут для сетевого подключения обычно остается неизменным, независимо от хоста или порта. Таким образом, злоумышленник может
попытаться выполнить запрос, который, как он знает, будет отправлен, и использовать его в качестве основы для будущего времени ответа. Успешные запросы будут, как правило, заметно короче, чем этот базовый уровень, а иногда и длиннее, если установленное соединение не защищено одной из сторон.
Действуя таким образом, злоумышленники могут отследить сервисы, выполняемые в сети, что позволяет им инициировать атаки с использованием контрабанды протоколов.
Отказ в обслуживании (DoS)
Объем запросов, получаемых внутренними серверами, обычно ниже, чем трафик на общедоступные серверы. Таким образом, они настроены на меньшую полосу пропускания. Киберпреступники могут использовать SSRF для наводнения внутренних серверов большим объемом трафика, чтобы занять их полосу пропускания, что приводит к внутренней DoS-атаке .
Помимо этих распространенных атак, киберпреступники могут использовать SSRF для выполнения злонамеренных или несанкционированных действий или для внедрения вредоносного ПО . Чем больше у организаций информации об этих рисках, тем больше это тревожно. Однако есть меры, которые можно предпринять, чтобы остановить эти атаки.
Удаленное выполнение кода (RCE)
Некоторые современные сервисы должны полностью взаимодействовать через HTTP-запросы. Таким образом, неограниченный контроль над URL-адресом может позволить злоумышленнику использовать определенные службы, что может привести к чему угодно - даже к удаленному выполнению кода на главном сервере (хорошо известный пример - Redis).
1.26 Типы атак SSRF
Атаки SSRF обычно используют доверительные отношения внутри самого сервера (известная как SSRF-атака на сервере) или между сервером и другими внутренними системами (известная как внутренняя SSRF-атака).
Серверные SSRF-атаки
В атаке SSRF на сервере злоумышленники используют процесс, в котором браузер или другая клиентская система напрямую обращается к ЦКЬ-адресу на сервере. Злоумышленник заменит исходный ЦКЬ-адрес другим, обычно используя № 127.0.0.1 или имя хоста «localhost», которые указывают на локальную файловую систему на сервере. Под этим именем хоста злоумышленник находит путь к файлу, который ведет к конфиденциальным данным .
Как работает Server SSRF
Например, на веб-сайте погоды веб-приложение запрашивает у своего сервера текущие прогнозы погоды для отображения. Он может сделать это с помощью REST API, передав URL-адрес с запросом API из браузера пользователя на сервер. Запрос может выглядеть так:
POST / метеорология I прогнозы HTTP /1.0
Тип содержимого: application / x-www-form-urlencoded
Длина содержимого: 113
weatherApi = http: //data.weatherapp.com: 8Э8В / meterology / forecasts / checks SFcurrentDateTime'fe 3D6% 26cityld% 3D1 Злоумышленник может изменить это на следующее: weatherApi = http: // localhost / admin
Это заставит сервер отобразить злоумышленнику содержимое папки / admin. Поскольку запрос выполняется в файловой системе сервера, он обходит обычные средства управления доступом и раскрывает информацию, даже если злоумышленник не авторизован.
Внутренние SSRF-атаки
Другой вариант SSRF - это когда сервер имеет доверительные отношения с внутренним компонентом. Если при подключении сервера к этому компоненту он имеет полные права доступа, злоумышленник может подделать запрос и получить доступ к конфиденциальным данным или выполнить неавторизованные операции. Внутренние компоненты часто имеют слабую защиту, потому что они считаются защищенными внутри периметра сети.
Продолжая предыдущий пример, злоумышленник может заменить вызов API на:
weatherApi = http: //192.168.12.5/admin
Если сервер подключается к внутреннему компоненту по IP-адресу 192.168.12.5 и ему разрешен доступ к каталогу / admin в файловой системе этого компонента, злоумышленник может аналогичным образом получить доступ и просмотреть содержимое каталога.
1.27 Устранение подделки запросов на стороне сервера Обычно к пользовательскому вводу применяются регулярные выражения и простые черные списки, чтобы смягчить SSRF и подобные атаки. Однако, вообще говоря, черные списки - неэффективный метод контроля безопасности. Злоумышленники могут легко найти способы их обойти. Например, киберпреступник может использовать службу DNS с подстановочными знаками, перенаправление HTTP или альтернативную кодировку IP.
Белые списки и разрешение DNS
Надежный подход к предотвращению SSRF - занести в белый список IP-адреса или DNS-имена, к которым вашему приложению требуется доступ. Только если подход с использованием белого списка не подходит, вы можете использовать черный список . Очень важно эффективно разрешать ввод данных пользователем. Например, не разрешайте запросы к частным IP-адресам (которые не маршрутизируются).
В случае черного списка подходящая стратегия смягчения будет отличаться в зависимости от приложения . Таким образом, не существует универсального решения для SSRF, поскольку оно очень зависит от требований организации и функциональности приложения.
Обработка ответов
Чтобы информация ответа не доходила до киберпреступника, вы должны убедиться, что полученный ответ соответствует ожидаемому. Ни в коем случае необработанный текст ответа, полученный от запроса, инициированного сервером, не должен передаваться клиенту.
Отключить неиспользуемые схемы URL-адресов
Если ваше приложение использует только HTTPS или HTTP для инициирования запросов, разрешите только эти схемы URL. Отключая неиспользуемые схемы URL-адресов, вы лишаете злоумышленников возможности использовать приложение для выполнения запросов через потенциально опасные схемы, включая diet: //, file: /// и gopher: //.
Аутентификация на внутренних службах
Такие сервисы, как Redis, MongoDB, Elasticsearch и Memcached по умолчанию не требуют проверки. Злоумышленник может получить доступ к определенным сервисам без проверки, используя уязвимости SSRF . Таким образом, для обеспечения безопасности веб-приложений желательно разрешить проверку всякий раз, когда это возможно, в том числе для служб локальной сети.
Литература
1. «Объём HTTP-трафика впервые превысил P2P» -net.compulenta.ru/322974/ — Компьюлента, 22 июня 2007. (Официальный документ от Ellacoya Networks -www.ellacoya.com/news/pdf/2007/NXTcommEllacoyaMediaAlert.pdf)
2. «HTTP-NG — объектно-ориентированный протокол передачи гипертекста» - www.osp.ru/cw/1998/20/29525/, «Открытые системы», 29 мая 1998 г. «(Proposed) HTTP-NG Working Group» - www.w3.org/Protocols/HTTP-NG/
— официальная страница W3C по разработке протокола HTTP-NG.
3. HTTP/1.1: Method Definitions - www.w3.org/Protocols/rfc2616/rfc2616-sec9.html (англ.). W3C.
4. «6.1.1 Status Code and Reason Phrase - tools.ietf.org/html/rfc2068#section-6.1.1» в RFC 2068. На стр. 40 - tools.ietf.org/html/rfc2068#page-40 есть также объявление в формате расширенной БНФ-формы (Augmented BNF) «extension-code = 3DIGIT» для кодов расширений.
5. HTTP errors -www.flickr.com/photos/apelad/sets/72157594388426362/detail/
References
1. "The volume of HTTP traffic for the first time exceeded P2P" -net.compulenta.ru/322974/ - Compulenta, June 22, 2007. (Official document from Ellacoya Networks -www.ellacoya.com/news/pdf/2007/NXTcommEllacoyaMediaAlert.pdf)
2. "HTTP-NG - object-oriented hypertext transfer protocol" -www.osp.ru/cw/1998/20/29525/, Open Systems, May 29, 1998 "(Proposed) HTTP-NG Working Group" - www.w3.org/Protocols/HTTP-NG/
- W3C's official page on the development of the HTTP-NG protocol.
3. HTTP/1.1: Method Definitions - www.w3.org/Protocols/rfc2616/rfc2616-sec9.html W3C.
4. "6.1.1 Status Code and Reason Phrase - tools.ietforg/html/rfc2068#section-6.1.1" in RFC 2068. On page 40 - tools.ietf.org/html/rfc2068#page-40 there is also an Augmented BNF declaration "extension-code = 3DIGIT" for extension codes.
5. HTTP errors -www.flickr.com/photos/apelad/sets/72157594388426362/detail/
© Казарян К.К., Белан В.В., 20221 Научно-образовательный журнал для студентов и преподавателей «StudNet» №1/2022.
Для цитирования: Казарян К.К., Белан В.В. ПОДДЕЛКА ЗАПРОСОВ НА СТОРОНЕ СЕРВЕРА // Научно-образовательный журнал для студентов и преподавателей №1/2022.
