9 популярных типов атак с внедрением веб-приложений

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

На заре Интернета одним из наиболее распространенных методов атаки был простой подбор методом грубой силы. Эти атаки обычно проводились ботами или людьми с большим количеством свободного времени, которые перепробовали миллионы комбинаций имени пользователя и пароля, пока не нашли ту, которая открыла бы доступ к целевому приложению.

Атаки полным перебором больше не представляют угрозы благодаря политикам паролей, ограниченным попыткам входа в систему и капчам. Но киберпреступники любят открывать новые эксплойты и использовать их для новых типов атак. Они давно обнаружили, что текстовые поля в приложениях или веб-страницах можно использовать, вводя в них — или внедряя — неожиданный текст, который заставит приложение делать что-то, чего оно не должно было делать. Вот так и появились так называемые инъекционные атаки.

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

Внедрение кода

Внедрение кода — один из самых распространенных типов атак путем внедрения. Если злоумышленники знают язык программирования, структуру, базу данных или операционную систему, используемую веб-приложением, они могут внедрить код через текстовые поля ввода, чтобы заставить веб-сервер делать то, что они хотят.

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

Например, необходимо ограничить объем ожидаемых данных, проверить формат данных перед их принятием и ограничить набор допустимых символов.

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

инъекция СКЛ

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

Приложения PHP и ASP подвержены атакам путем внедрения кода SQL из-за их старых функциональных интерфейсов. Приложения J2EE и ASP.Net обычно более защищены от этих атак. Как только уязвимость для инъекции SKL будет обнаружена — а найти ее легко — размер потенциальных атак будет ограничен только навыками и воображением злоумышленника. Таким образом, влияние инъекции СКЛ, несомненно, велико.

Инъекция команд

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

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

Эти атаки может предотвратить системный администратор, ограничив уровень доступа к системе веб-приложений, работающих на сервере.

Межсайтовый скриптинг

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

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

CSS-атаки обычно можно разделить на две категории: сохраненные и отраженные.

В сохраненных атаках CSS вредоносный скрипт постоянно находится на целевом сервере, доске объявлений, базе данных, журнале посетителей и т. д. Жертва получает его, когда их браузер запрашивает сохраненную информацию. В отраженных атаках CSS вредоносный скрипт отражается в ответе, который включает входные данные, отправленные на сервер. Например, это может быть сообщение об ошибке или результат поиска.

XPath-инъекция

Этот тип атаки возможен, когда веб-приложение использует предоставленную пользователем информацию для выполнения запроса XPath для данных XML. Принцип действия этих атак аналогичен SQL-инъекциям: злоумышленники отправляют приложению ложную информацию, чтобы узнать, как структурированы XML-данные, а затем снова атакуют, чтобы получить доступ к этим данным.

XPath — это стандартный язык, с помощью которого, как и в SQL, вы можете указать атрибуты, которые хотите найти. Для запроса XML-данных веб-приложения используют пользовательский ввод для установки шаблона, которому должны соответствовать данные. Отправляя искаженный ввод, шаблон можно превратить в операцию, которую злоумышленник хочет выполнить с данными.

В отличие от того, что происходит с SQL, в XPath нет разных версий. Это означает, что внедрение XPath может быть выполнено в любом веб-приложении, использующем данные XML, независимо от реализации. Это также означает, что атаку можно автоматизировать; поэтому, в отличие от инъекции SKL, его можно активировать против произвольного количества целей.

Внедрение почтовых команд

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

Чтобы использовать SMTP-сервер, злоумышленникам нужна действующая учетная запись электронной почты для отправки сообщений с внедренными командами. Если сервер уязвим, он будет отвечать на запросы злоумышленников, позволяя им, например, обойти ограничения сервера и использовать его услуги для рассылки спама.

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

инъекция CRLF

Вставка символов возврата каретки и перевода строки — комбинация, известная как CRLF — в поля ввода веб-формы — это метод атаки, называемый внедрением CRLF. Эти невидимые символы обозначают конец строки или конец команды во многих традиционных интернет-протоколах, таких как HTTP, MIME или NNTP.

Например, вставка CRLF в HTTP-запрос, за которым следует определенный HTML-код, может привести к отправке настраиваемых веб-страниц посетителям веб-сайта.

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

Внедрение заголовка хоста

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

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

LDAP-инъекция

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

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

в нужном месте во входной строке.

Предотвращение инъекционных атак

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