Проблема с веб-приложениями заключается в том, что они открыто доступны миллиардам интернет-пользователей, многие из которых захотят нарушить меры безопасности по любым причинам.
На заре Интернета одним из наиболее распространенных методов атаки был простой подбор методом грубой силы. Эти атаки обычно выполняли боты — или лица, у которых было много свободного времени, — которые перепробовали миллионы комбинаций имен пользователей и паролей, пока не нашли ту, которая предоставила бы доступ к целевому приложению.
Атаки методом грубой силы больше не представляют угрозы благодаря политикам паролей, ограниченным попыткам входа в систему и капчам. Но киберпреступники любят находить новые эксплойты и использовать их для выполнения новых типов атак. Давным-давно они обнаружили, что текстовые поля в приложениях или веб-страницах можно использовать, вводя в них — или внедряя — неожиданный текст, который заставит приложение делать то, чего оно не должно было делать. Таким образом, на сцену вышли так называемые инъекционные атаки.
Инъекционные атаки могут использоваться не только для входа в приложение без знания имени пользователя и пароля, но и для раскрытия частной, конфиденциальной или конфиденциальной информации или даже для захвата всего сервера. Вот почему эти атаки представляют угрозу не только для веб-приложений, но и для пользователей, чьи данные находятся в этих приложениях, а в худшем случае и для других подключенных приложений и служб.
Оглавление
Внедрение кода
Внедрение кода — один из самых распространенных типов атак путем внедрения. Если злоумышленники знают язык программирования, структуру, базу данных или операционную систему, используемую веб-приложением, они могут внедрить код через текстовые поля ввода, чтобы заставить веб-сервер делать то, что они хотят.
Эти типы атак с внедрением возможны в приложениях, в которых отсутствует проверка входных данных. Если поле ввода текста позволяет пользователям вводить все, что они хотят, то приложение потенциально может быть взломано. Чтобы предотвратить эти атаки, приложение должно максимально ограничить входные данные, которые разрешено вводить пользователям.
Например, необходимо ограничить количество ожидаемых данных, проверить формат данных перед их принятием и ограничить набор допустимых символов.
Уязвимости внедрения кода можно легко найти, просто протестировав текстовый ввод веб-приложения с различными типами контента. Когда обнаружены уязвимости, их довольно трудно использовать. Но когда злоумышленнику удается использовать одну из этих уязвимостей, последствия могут включать потерю конфиденциальности, целостности, доступности или функциональности приложения.
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-инъекций, он потенциально может быть запущен против произвольного количества целей.
Внедрение почтовых команд
Этот метод атаки можно использовать для использования почтовых серверов и приложений, которые создают операторы IMAP или SMTP с ненадлежащим образом проверенным пользовательским вводом. Иногда серверы IMAP и SMTP не имеют надежной защиты от атак, как в случае с большинством веб-серверов, и поэтому могут быть более уязвимыми. Заходя через почтовый сервер, злоумышленники могли обойти такие ограничения, как капчи, ограниченное количество запросов и т.п.
Чтобы использовать SMTP-сервер, злоумышленникам нужна действующая учетная запись электронной почты для отправки сообщений с внедренными командами. Если сервер уязвим, он будет отвечать на запросы злоумышленников, позволяя им, например, обойти ограничения сервера и использовать его сервисы для рассылки спама.
Внедрение IMAP может быть выполнено в основном в приложениях веб-почты, используя функцию чтения сообщений. В этих случаях атаку можно выполнить, просто введя в адресной строке веб-браузера URL-адрес с внедренными командами.
инъекция CRLF
Вставка символов возврата каретки и перевода строки — комбинация, известная как CRLF — в поля ввода веб-формы представляет собой метод атаки, называемый внедрением CRLF. Эти невидимые символы обозначают конец строки или конец команды во многих традиционных интернет-протоколах, таких как HTTP, MIME или NNTP.
Например, вставка CRLF в HTTP-запрос, за которым следует определенный код HTML, может отправить посетителям веб-сайта настраиваемые веб-страницы.
Эта атака может быть выполнена на уязвимых веб-приложениях, которые не применяют надлежащую фильтрацию к пользовательскому вводу. Эта уязвимость открывает двери для других типов инъекционных атак, таких как XSS и инъекция кода, а также может быть связана со взломом веб-сайта.
Внедрение заголовка хоста
На серверах, на которых размещается множество веб-сайтов или веб-приложений, заголовок узла становится необходимым для определения того, какой из резидентных веб-сайтов или веб-приложений, каждый из которых известен как виртуальный хост, должен обрабатывать входящий запрос. Значение заголовка сообщает серверу, на какой из виртуальных хостов отправить запрос. Когда сервер получает недопустимый заголовок хоста, он обычно передает его первому виртуальному хосту в списке. Это представляет собой уязвимость, которую злоумышленники могут использовать для отправки произвольных заголовков хоста на первый виртуальный хост на сервере.
Манипуляции с заголовком хоста обычно связаны с приложениями PHP, хотя это также можно сделать с другими технологиями веб-разработки. Атаки на заголовки хостов работают как средства реализации других типов атак, таких как отравление веб-кэша. Его последствия могут включать в себя выполнение злоумышленниками чувствительных операций, например сброса пароля.
LDAP-инъекция
LDAP — это протокол, предназначенный для облегчения поиска ресурсов (устройств, файлов, других пользователей) в сети. Он очень полезен для интрасетей, а при использовании в составе системы единого входа его можно использовать для хранения имен пользователей и паролей. Запросы LDAP предполагают использование специальных управляющих символов, влияющих на его управление. Злоумышленники потенциально могут изменить предполагаемое поведение запроса LDAP, если они смогут вставить в него управляющие символы.
Опять же, основная проблема, которая допускает атаки с внедрением LDAP, заключается в неверном подтверждении пользовательского ввода. Если текст, который пользователь отправляет приложению, используется как часть запроса LDAP без его очистки, запрос может в конечном итоге получить список всех пользователей и показать его злоумышленнику, просто используя звездочку.
в нужном месте внутри входной строки.
Предотвращение инъекционных атак
Как мы видели в этой статье, все инъекционные атаки направлены на серверы и приложения с открытым доступом для любого интернет-пользователя. Ответственность за предотвращение этих атак распределяется между разработчиками приложений и администраторами серверов.
Разработчики приложений должны знать о рисках, связанных с неправильной проверкой пользовательского ввода, и изучать передовой опыт по очистке пользовательского ввода с целью предотвращения рисков. Администраторам серверов необходимо периодически проводить аудит своих систем, чтобы обнаруживать уязвимости и устранять их как можно скорее. Существует множество вариантов проведения этих аудитов, как по запросу, так и автоматически.