4.2.1 Тестирование конфигурации инфраструктуры веб-приложения

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

Для тестирования конфигурации инфраструктуры необходимо:

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

После составления карты архитектуры веб-приложения (OTG-INFO-010) можно переходить к тестированию конфигурации каждого элемента инфраструктуры в отдельности.

Цель тестирования:

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

Как тестировать:

Известные серверные уязвимости

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

Проверка сервера на наличие уязвимостей затрудняется в случае “слепого” пен-теста. В таком случае тестирование обычно проводится удаленно, с использованием автоматических инструментов. Однако, подобного рода тестирование может иметь непредсказуемые последствия, а также такой подход неприменим для некоторых типов уязвимостей (например, атаки, ведущие к отказу в обслуживании).

Многие автоматические инструменты определяют наличие уязвимостей на основе информации о версии используемого ПО (здесь и далее — программное обеспечение). Это приводит как к ложно-положительным, так и к ложно-отрицательным срабатываниям. С одной стороны, если администратор веб-сервера каким-либо образом скроет версию веб-сервера от сканирующих инструментов, они не смогут определить наличие уязвимостей, основываясь на версии ПО. С другой стороны, если поставщик не изменяет версию ПО при выпуске обновлений, закрывающих какие-либо уязвимости, автоматические сканирующие инструменты будут указывать на уязвимости, которых нет. Такое поведение — довольно часто встречающаяся ситуация среди поставщиков операционных систем, которые отдельно выпускают патчи, закрывающие уязвимости. Подобное происходит с большинством GNU/Linux дистрибутивов, таких как Debian, Red Hat, SuSe. В большинстве случаев, автоматическое сканирование архитектуры приложения может выявить наличие уязвимостей только во “внешних” элементах архитектуры (веб-сервер), и неспособно обнаружить уязвимости в элементах, которые недоступны напряму извне (например, бэкэнд аутентификации, сервер баз данных, реверсивный прокси).

Наконец, не все поставщики ПО публично делятся информацией об уязвимостях, и такие уязвимости не попадают в публичные базы. Информация о таких уязвимостях доступна только клиентам или становится известной только благодаря выпущенным исправлениям. Подобное поведение снижает эффективность автоматических инструментов по поиску уязвимостей. Для автоматизированных инструментов характерно широкое покрытие уязвимостей для наиболее известных и распространенных продуктов (таких как Apache web server, Microsoft’s IIS, IBM’s Lotus Domino) и меньшее покрытие для менее известных продуктов.

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

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

Инструменты администрирования

Любой веб-сервер нуждается в инструментах администрирования и обновления информации, используемой веб-приложением (статический контент, исходный код, базы данных). Такие инструменты отличаются в зависимости от поставщика и используемых технологий. Например, некоторые веб-серверы управляются через интерфейсы администрирования, которые также являются веб-серверами (iPlanet web server), некоторые управляются посредством конфигурационных файлов (Apache) или с использованием инструментов с графическим интерфейсом (Microsoft’s IIS или ASP.Net). В большинстве случаев конфигурация сервера также осуществляется посредством различных технологий (FTP, WebDAV, сетевые файловые системы — NFS, CIFS). Веб-приложения также могут иметь собственные встроенные интерфейсы и инструменты администрирования, наличие которых необходимо задокументировать.

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

определить и проверить механизмы контроля доступа к инструментам администрирования;
изменить используемые по умолчанию имя пользователя и пароль для доступа к инструментам администрирования;

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

Описание :

Перевод подготовлен специально для канала t.me/FreedomF0x

Contact: t.me/freedomf0x t.me/Slippery_Fox twitter.com/FlatL1ne

xmpp(жаба_ёпт): [email protected]

При поддержке друзей: t.me/in51d3 t.me/NeuroAliceMusic t.me/vulnersBot t.me/darknet_prison

Our private (no logs) xmpp server: FreedomFox.im (for add, write to [email protected])

Хорошо там где нас нет (с) Русские хакеры
Добре там де нас немає (с) Російські хакери