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

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


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

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

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

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

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

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

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

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

SQL-инъекция

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

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

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

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

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

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

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

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

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

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

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

XPath инъекция

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

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

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

Внедрение команды Mail

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

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

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

CRLF инъекция

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

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

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

Внедрение Host Header

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

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

Инъекция LDAP

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

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

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

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

Разработчики приложений должны знать риски, связанные с неправильной проверкой пользовательского ввода, и изучать передовые методы для очистки пользовательского ввода в целях предотвращения рисков. Администраторы серверов должны периодически проверять свои системы, чтобы выявлять уязвимости и исправлять их как можно скорее. Существует много вариантов проведения этих аудитов, как по запросу, так и автоматически..

Jeffrey Wilson Administrator
Sorry! The Author has not filled his profile.
follow me
    Like this post? Please share to your friends:
    Adblock
    detector
    map