Ошибка или особенность? Обнаружены скрытые уязвимости веб-приложений.

Brother

Professional
Messages
2,565
Reputation
3
Reaction score
363
Points
83
Безопасность веб-приложений состоит из множества элементов управления безопасностью, которые гарантируют, что веб-приложение:
  1. Функционирует, как ожидалось.
  2. Не могут быть использованы для работы вне ограничений.
  3. Не удается инициировать операции, которые оно не должно выполнять.
Веб-приложения стали повсеместными после распространения Web 2.0, платформы социальных сетей, веб-сайты электронной коммерции и почтовые клиенты заполнили интернет-пространства в последние годы.

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

Распространенные методы атаки​

Тремя наиболее распространенными уязвимостями, существующими в этом пространстве, являются инъекции (SQL, удаленный код), криптографические сбои (раскрытие ранее конфиденциальных данных) и нарушение контроля доступа (BAC). Сегодня мы сосредоточимся на инъекциях и неработающем контроле доступа.

Инъекции​

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

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

Отправной точкой для этого является команда, подобная приведенной ниже:
Уязвимости веб-приложений


Это вернет ВСЕ строки из таблицы "Пользователи", поскольку OR 1 = 1 всегда равно TRUE. Продолжая, этот метод также вернет пароли, если таковые имеются.

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

Нарушен контроль доступа​

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

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

CVE-2019-0211, который представлял собой локальное повышение привилегий Apache. Эта критическая уязвимость 2019 года затронула HTTP-серверы Apache, работающие в системах Unix, особенно те, которые используют библиотеки mod_prefork, mod_worker и mod_event.

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

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

Уязвимости веб-приложений


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

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

Поскольку BAC становится все более распространенным явлением в последние пару лет, важно помнить:
  • Зависимость исключительно от обфускации не является достаточным методом для контроля доступа.
  • Если ресурс не предназначен для общего доступа, доступ к нему должен быть запрещен по умолчанию.
  • Разработчики должны явно указывать разрешенный доступ для каждого ресурса на уровне кода, с отказом в доступе в качестве настройки по умолчанию.

Рекомендации - читать между строк (кода!)​

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

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

Практический пример – Проверка входных данных​

Проверка входных данных - это самый простой и эффективный способ реализовать безопасное кодирование, в данном примере для предотвращения SQL-инъекций.
  1. Ввод данных пользователем: пользователь вводит данные, например:
    Уязвимости веб-приложений
  2. Очистка: вводимые пользователем данные не вставляются напрямую в SQL-запрос. Они очищаются и обрабатываются как данные, а не как SQL-код.
  3. Выполнение запроса: SQL-запрос выполняется с использованием пользовательского ввода в качестве параметра:
  4. Таким образом, запрос поступает в серверную часть, как показано ниже:

Уязвимости веб-приложений


В этом коде (user_input,) представляет собой кортеж, содержащий входные данные пользователя. Драйвер базы данных заботится об экранировании и правильной обработке этих входных данных. Это гарантирует, что входные данные обрабатываются как значение данных, а не как исполняемый код SQL.

Если пользовательский ввод содержит вредоносный код, такой как "105 или 1 = 1", он не выполняется как SQL. Вместо этого он обрабатывается как значение для сравнения с идентификатором пользователя в базе данных.

Драйвер базы данных автоматически обрабатывает экранирование входных данных, предотвращая их влияние на структуру SQL-запроса или появление уязвимостей в системе безопасности.

Брандмауэры веб-приложений (WAF)​

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

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

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

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

Реагирование на инциденты и восстановление​

Предложения SecurityHQ по защите от атак:
  1. Использование WAF в качестве первой линии защиты имеет решающее значение для обеспечения защиты бизнеса от большого количества атак.
  2. Убедитесь, что используются современные и надежные стандартные алгоритмы и протоколы, это должно сочетаться с надлежащим управлением ключами.
  3. Шифруйте данные при передаче с помощью безопасных протоколов, таких как TLS, с использованием шифров прямой секретности (FS), при этом сервер устанавливает приоритет шифрования. Применяйте шифрование с помощью директив, таких как HTTP Strict Transport Security (HSTS).
  4. Включите стратегии управления ботами на веб-сайтах и имейте документированный план реагирования на инциденты.
  5. Обеспечьте внедрение безопасных методов разработки с помощью документированного процесса тестирования новых функций в веб-приложениях и убедитесь, что проверка входных данных развернута.
    • Это должно сочетаться с обеспечением принципа наименьших привилегий.
  6. Регулярно проверяйте наличие уязвимостей с помощью управления уязвимостями и управляемой защиты с помощью инструментов IBM tooling и отслеживайте версии компонентов.
  7. Используйте красный тест приложения для выявления уязвимостей, которые не могут обнаружить сканеры.
  8. Убедитесь, что разработчики регулярно проходят обучение, чтобы быть в курсе последних тенденций в области безопасности и возникающих угроз.
Для получения дополнительной информации об этих угрозах обратитесь к эксперту здесь. Или, если вы подозреваете инцидент с безопасностью, вы можете сообщить об инциденте здесь.

Примечание: Эта статья была профессионально написана Тимом Чемберсом, старшим менеджером по кибербезопасности SecurityHQ
 
Top