Логика современного бизнеса тесно связана с обработкой конфиденциальной информации, в том числе и информации, доступной посредством Web. Потенциально секреты компании можно получить, используя обычный браузер. Если в дополнение к этому от Web-приложений требуется соблюдение стандартов безопасности (PCI DSS, NIST и др.), международных критериев (ISO/IEC 27005:2008, ITIL, COBIT и др.) и законодательных требований, то станет понятна необходимость проведения регулярного анализа защищенности.
Способы анализа защищенности
Сегодня имеется большое количество материалов, посвященных проведению анализа защищенности Web-приложений. Наиболее интересные из них?— библиотека документов Open Web Application Security Project (OWASP), содержащая полное руководство по поиску всевозможных уязвимостей, их классификацию, а также рекомендации к процессу проведения анализа защищенности.
С точки зрения классификации уязвимостей интересны материалы проекта Web Application Security Consortium (WASC). Стоит также отметить открытый стандарт Open Source Security Testing Methodology Manual (OSSTMM), который рассматривает анализ защищенности Web-приложений в контексте комплексного процесса проведения тестирования на проникновение.
Инструментальный анализ
Данный способ в первую очередь предусматривает использование сканеров безопасности, а также дополнительных инструментов, автоматизирующих некоторые сценарии эксплуатации и выявления уязвимостей. Из наиболее популярных сканеров безопасности можно выделить Acunetix Web Security Scanner, HP Web Inspect и Positive Technologies MaxPatrol (ранее XSpider). Дополнительно может применяться утилита sqlmap, исследующая наличие SQL-инъекций, а также различные утилиты класса fuzzing, суть которых состоит в подаче намеренно некорректных данных на вход приложения и анализе возвращаемых им данных.
Инструментальное обследование является наиболее простым и как следствие наиболее распространенным способом анализа защищенности Web-приложений. За простоту приходится расплачиваться ошибками «второго рода» (false negative) — пропуском части уязвимостей, которым подвержено исследуемое приложение. Например, сегодня сканеры не могут самостоятельно (то есть без использования сигнатур) выявить такие уязвимости, как небезопасное восстановление паролей (Weak Password Recovery Validation), отсутствие тайм-аута сессии (Insufficient Session Expiration) или логические атаки.
Если объектом атаки будет приложение, использующее рабочий процесс, в свою очередь реализующий некую бизнес-задачу, то это приложение может оказаться уязвимым, если не осуществляются проверки выполнения всех предыдущих этапов процесса. Предположим, что существует Web-приложение, которое использует некий процесс для активации денежной суммы с пластиковой карты. На первом этапе этого процесса приложение удостоверяется в корректности данных, вводимых пользователем, затем идет проверка, числится ли эта пластиковая карта в базе клиентов банка и соответствует ли запрашиваемая сумма номиналу счета. При отрицательном результате пользователь получает сообщение об ошибке. На последнем этапе этого процесса происходит изменение баланса счета пользователя в соответствии с введенными данными на первом этапе. Успешная атака на такое приложение может быть реализована в том случае, если существует возможность обратиться к последнему этапу процесса (пополнение счета) с передачей произвольной суммы для изменения баланса. Сканер безопасности пропустит подобную уязвимость — ему не известно, что была выполнена операция пополнения счета с произвольной суммой. Все, чем будет располагать сканер безопасности, это то, что при обращении к «такой-то» странице, на ней меняется «такое-то» значение и с его точки зрения — это не является уязвимостью. По такому же принципу может работать вполне безопасное приложение, например новостная лента или доска объявлений.
Стоит отметить, что, несмотря на некоторые ограничения инструментального анализа защищенности, данный способ удовлетворяет требованиям стандарта Payment Card Industry Data Security Standard (PCI DSS) при проведении оценки защищенности узлов, доступных в Internet.
Анализ вручную
Поиск вручную в большинстве случаев позволяет выявить уязвимости, которые невозможно обнаружить инструментальным путем, однако требует больше времени. При этом качество анализа сильно зависит от уровня знаний специалиста в данной предметной области и его опыта проведения подобных работ. Важно понимать, что когда большинство проверок осуществляется вручную, то растет риск проявления «человеческого фактора». Однако существуют Web-приложения, в отношении которых невозможно или крайне затруднительно провести инструментальное обследование, например приложения из банковской сферы, использующие модель защиты от уязвимостей, основанных на так называемой «межсайтовой подделке запросов» (Cross-Site Request Forgery, CSRF). В этом случае единственным способом анализа защищенности является выполнение всех проверок вручную.
Анализ исходного кода
В отличие от анализа вручную, анализ исходного кода позволяет проверить защищенность Web-приложения, не затрагивая его работу, — исследование может выполняться без доступа к самому Web-серверу, если не требуется выполнение проверок эксплуатации уязвимости. Это наиболее безопасный способ проведения подобных работ. Одним из недостатков этого способа является невозможность провести оценку защищенности состояния Web-ресурса – здесь требуется непосредственный доступ к нему.
Анализ исходного кода позволяет выявить многие уязвимости, которым подвержено Web-приложение, однако для этого может потребоваться довольно много времени, которое зависит от сложности стиля программирования, используемого при написании приложения, и объема анализируемого кода. Кроме того, существует множество коммерческих приложений, разработчики которых распространяют свои продукты только в виде бинарных файлов (например, с использованием кодирования Zend или технологии ASP.NET), что не позволяет применить данный способ. Хотя стоит заметить, что можно проводить и бинарный анализ приложения (этим, в частности, занимается компания Veracode).
На практике анализ исходного кода осуществляется в полном объеме преимущественно лишь для отдельных модулей или функций обследуемого приложения. В случае когда необходим анализ исходного кода на наличие уязвимостей всего приложения, прибегают к автоматизированному способу, проводимому статически или динамически.
Поиск методом статистического анализа исходного кода основан на использовании сигнатур, которые в свою очередь базируются на аппарате регулярных выражений. Данный метод в силу своей простоты получил наибольшее распространение. Необходимо учитывать, что при использовании статического анализа неизбежны ошибки первого и второго рода, когда анализирующее приложение не сможет выявить некоторое число уязвимостей в силу отсутствия соответствующей сигнатуры. Возможны также многочисленные ложные уведомления о наличии уязвимости.
Ошибки первого рода (false positive — «ненайденные уязвимости») при использовании статического анализа исходного возникают в силу следующих причин:
-
при программировании Web-при-ложения используется сложный синтаксис;
-
проверки переменных происходят с использованием собственных функций приложения;
-
отсутствуют соответствующие сигнатуры.
Динамический анализ более эффективен по сравнению со статическим. Средство, позволяющее выполнить динамический анализ кода, досконально разбирает синтаксис языка программирования, на котором написано исследуемое приложение, и проводит ряд проверок, направленных на выявление необработанных данных со стороны пользователя, поступающих в потенциально опасные функции приложения в качестве аргументов. Такой анализ позволяет за короткое время выявить все грубые ошибки, допущенные программистами, и выдать отчет с минимальным количеством ошибок первого и второго рода. Однако из-за сложности реализации таких средств, а также в силу необходимости поддержки множества языков программирования (PHP, ASP, Perl, Python, Java и др.), на которых могут быть написаны Web-приложения, подобных средств не так уж и много. Наибольшее распространение получили Coverity, Valgrind и Fortify PTA.
Стоит учитывать, что автоматизированным анализаторам исходного кода присущи те же недостатки, что и сканерам безопасности. К примеру, невозможно выявить уязвимости «Небезопасное восстановление паролей», «Отсутствие тайм-аута сессии», «Логические атаки» и пр. Поэтому, как правило, при всестороннем анализе исходного кода приходится комбинировать использование одного или обоих методов автоматизированного анализа исходных текстов, а также проводить экспертный анализ отдельных модулей приложения: аутентификации, авторизации, восстановления паролей, проводки транзакций и др.
Из наиболее известных разработчиков коммерческих продуктов по автоматизированному анализу исходных текстов Web-приложений можно выделить компании Armorize Technologies, Fortify и Ounce Labs.
Комплексная оценка
Данный способ позволяет провести анализ защищенности Web-приложения с позиций среды его функционирования, что бывает полезно в случае сервис-ориентированных архитектур и при проведении аудита информационной системы в целом. По сути, можно в разной степени комбинировать перечисленные подходы к анализу защищенности, дополняя процесс исследования такими возможностями, как например Compliance (оценка соответствия неким критериям). При проведении анализа могут использоваться следующие принципы.
Принцип «черного ящика» (black-box). Проведение работ по оценке защищенности приложения без предварительного получения какой либо информации о нем. Это полезно, когда необходимо оценить защищенность с позиций злоумышленника, обычно располагающего минимальными знаниями об исследуемой системе. В основном подобные оценки осуществляются в рамках «тестирования на проникновение» (penetration testing). Все исследования могут проходить как с предупреждением обслуживающего персонала о планируемых работах, так и без него. Во втором случае существует возможность оценить, за какое время после начала исследования персонал зафиксирует инцидент, а также какова адекватность предпринимаемых действий по минимизации его воздействия или предотвращения.
Принцип «серого ящика» (gray-box). Проведение работ с предоставлением всей необходимой информации о приложении, кроме обеспечения непосредственного доступа к самому серверу, на котором функционирует исследуемое Web-приложение. Обычно исполнителю предоставляются следующие данные: структура каталогов приложения, данные для авторизованного подключения в пространстве Web-приложения (например, имя пользователя, пароль и набор одноразовых паролей для проводки транзакций), исходный код некоторых файлов или функций и пр.
Принцип «белого ящика» (white-box). Данный принцип подразумевает передачу исполнителю всего приложения с его последующим развертыванием на площадке консультанта, выполняющего работу по его анализу, либо организацию аналогичной копии приложения в собственной информационной системе с предоставлением исполнителю полного доступа к этому ресурсу. В данном случае имеется возможность отследить, каким образом приложение реагирует на любой передаваемый к нему запрос. Это наиболее продуктивный метод проведения анализа защищенности Web-приложений, позволяющий выявить наибольшее число уязвимостей. Однако стоит заметить, что данный метод лишен возможности взглянуть на приложение с позиций атакующего.
Организация процесса анализа защищенности
Прежде всего, необходимо понять, какую цель должен преследовать анализ, а затем определить область исследования и, руководствуясь стратегией управления информационными рисками и допустимым бюджетом, сформировать перечень проверок. Если цель анализа заключается в демонстрации возможности проникновения, нарушения штатного режима работы приложения или демонстрации компрометации чувствительной информации, тогда работы стоит организовать по принципу «черного ящика» без ограничений по проводимым проверкам.
Результаты подобного исследования продемонстрируют текущее состояние дел с безопасностью объектов исследования. В случае низкого уровня защищенности Web-приложений подобные работы наглядно демонстрируют реализуемые угрозы со стороны внешнего нарушителя, и следствием этого может стать выделение дополнительного бюджета на работы по минимизации рисков.
Когда цель анализа защищенности заключается в повышении уровня безопасности приложения в условиях ограниченного бюджета, то лучше всего организовать процесс анализа ресурса методом «серого ящика» с использованием инструментального подхода к его обследованию с частичными проверками, выполненными вручную.
Какой бы вариант проведения обследования ни был выбран, важно выполнить резервное копирование ресурса до начала проведения.
Дмитрий Евтеев (devteev@ptsecurity.ru) — эксперт по информационной безопасности компании Positive Technologies (Москва).
Широкое распространение Web позволяет использовать однотипные сценарии эксплуатации уязвимостей одновременно для множества ресурсов, а небезопасное программирование, низкая компетенция или недостаточная мотивация обслуживающего персонала может порождать критические уязвимости.
Хорошей практикой системы управления информационной безопасностью является использование «превентивных» подходов, поэтому анализ защищенности, в первую очередь приложений, обрабатывающих критичные для бизнеса данные, должен быть частью общей стратегии построения такой системы.
