Введение в IBM Rational AppScan Developer Edition

С какими проблемами нам придется иметь дело?

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

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

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

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

К решению этих проблем должны привлекаться все рабочие группы, осуществляющие разработку Web-приложения, но прежде всего - группы разработки и обеспечения качества ПО. В конечном итоге такие проблемы являются результатом большого количества уязвимостей, которые возникают в Web-приложении, если при создании программного кода не уделяется должного внимания обеспечению безопасности. В этой статье рассказывается о том, какую роль должны играть разработчики в повышении уровня безопасности Web-приложений и о том, как инструмент IBM Rational AppScan Developer Edition может помочь им в этом.

Разработчики и безопасность Web-приложений

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

В таблице 1 приводятся примеры различий между этими рабочими группами.

Таблица 1. Роли и обязанности

Поскольку эти две группы не одинаковы, то и продукты, предназначенные для каждой из них, также должны быть разными. Так же, как инструмент Rational AppScan Standard Edition предназначен для аудиторов безопасности, Rational AppScan Developer Edition предназначен для разработчиков и учитывает специфику их работы.

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

Принципы сканирования безопасности приложений

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

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

  Динамический анализ аналогичен применению Web-браузера для поэтапного изучения Web-приложения: в каждое поле формы вставляются простые кавычки, после чего изучаются ошибки SQL-кода (что обычно подразумевает наличие SQL-инъекций) в отклике приложения.

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

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

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

Инструмент Rational AppScan Developer Edition включает все три технологии анализа, которые выполняются параллельно и используют в своей работе данные друг друга. Параллельное выполнение усиливает эффективность каждого метода, а их симбиотическое использование помогает компенсировать слабые стороны каждого метода. В данной статье изучаются описанные методы и рассказывается о том, как объединить их в эффективное решение.

Динамический анализ

Динамический анализ связан с тестированием Web-приложения как закрытого объекта, взаимодействие с которым осуществляется через его официальные интерфейсы (в основном, HTTP). Это действие часто называют сканированием по принципу черного ящика , поскольку оно не обеспечивает и не требует понимания того, что происходит внутри приложения. На данный момент динамический анализ представляет собой преобладающий подход к тестированию безопасности Web-приложения. В качестве примера инструментов динамического анализа можно назвать Rational AppScan Standard и Enterprise Editions.

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

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

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

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

Ниже перечислены некоторые преимущества динамического анализа.

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

У метода динамического анализа много преимуществ, но есть и недостатки. Преимущества метода обусловлены тем, что тестирование выполняется извне работающего приложения; но это обстоятельство является также источником проблем. Вот некоторые из них.

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

Статический анализ

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

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

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

Выполняя анализ потока загрязненных данных, сканер моделирует поток данных в системе. Если данные из ненадежного источника входа (например, поля формы) проходят через уязвимый выход (например, вызов базы данных) и при этом приложение не проверяет, не является ли информация на входе вредоносной, то генерируется отчет о проблеме безопасности. Ненадежные данные называются загрязненными данными , а код, проверяющий, не являются ли эти данные вредоносными, называют модулем очистки ; часто говорят, что он очищает загрязненные данные.

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

Поэтому к преимуществам статического анализа можно отнести следующие.

• Выявление дополнительных типов проблем: поскольку этот тип анализа не ограничивается проблемами, которые можно тестировать через внешние HTTP-интерфейсы, он может тестировать приложение на степень надежности, использование ненадежных в отношении безопасности методов и многие другие проблемы, скрытые от динамического анализа.
  
• Широкий спектр целевых программ: благодаря видимости других точек входа данных (таких, как считываемые файлы и проверяемые переменные окружения), статический анализ может проверить наличие проблемы практически в любой программе, а не только в Web-приложении. Некоторые из этих свойств можно тестировать и динамически, но современным инструментам динамического анализа это недоступно.
  
• Понятный механизм обеспечения покрытия кода: поскольку сам код сканируется статически, то для того чтобы обеспечить покрытие кода, достаточно просто указать, какой участок кода должен быть включен в охват анализа.
  
• Пониженная чувствительность к технологии клиентской стороны: возможность видеть точки входа в приложения в программном коде избавляет от необходимости "проводить" приложение через клиенты инструментов динамического анализа, что делает сканирование полнофункциональных интернет-приложений (rich Internet application, RIA) для выявления проблем на серверной стороне не сложнее сканирования традиционных Web-приложений.
  
• Отсутствие необходимости в пользовательском интерфейсе: вы можете приступить к идентификации дефектов до того, как будет доступен интерфейс или законченный рабочий поток.
  

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

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

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

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

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

В итоге, статический анализ имеет следующие недостатки.

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

Построчный анализ

У метода статического анализа на данный момент есть еще один недостаток - это необходимость тщательной настройки модулей очистки (sanitizer).

Проблема настройки модуля очистки

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

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

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

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

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

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

Решение: анализ строк

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

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

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

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

Листинг 1. Отслеживание переменной входной строки

public void submitQuery(String userName) 
{
    userName = clean(userName);
    String query = "SELECT id FROM users WHERE name = '" + userName + "'";
    execute(query);
}
public String clean(String input) 
{
    return input.replaceAll(";","").replaceAll("'","");
}

Примечание. В строке public String входом является ".*", а в строке return входом является "[~;']*"

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

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

Реальный потенциал построчного анализа

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

Давайте рассмотрим приложение форума, в котором пользователь указывает свое публичное имя, как показано в листинге 2.

Листинг 2. Определение публичного имени

statement.executeUpdate("UPDATE Users SET PubName='" +  SqlEncode(Name) +
     "' WHERE UserName = '" + SqlEncode(UserName) + "';");

Когда пользователь размещает сообщение, другая страница извлекает имя и отображает его рядом с каждым сообщением, размещаемым данным пользователем, как показано в листинге 3.

Листинг 3. Отображение публичного имени

ResultsSet rs = statement.executeQuery("SELECT PubName FROM Users " +
     " WHERE UserName='" +  SqlEncode(UserName) + "';");

При условии, что данное имя пользователя теперь вписывается напрямую в HttpResponse, это означает наличие уязвимости персистентного межсайтового скриптинга (Persistent Cross-Site Scripting (XSS): загрязненные данные проходят в HttpResponse без очистки по XSS.

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

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

• чтение из определенных файлов и запись в определенные файлы;
• вызовы серверов аутентификации;
• передача данных по многим другим протоколам.

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

Анализ периода выполнения

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

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

Чаще всего рабочий поток анализа периода выполнения включает следующие шаги:

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

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

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

Хотя анализ периода выполнения является очень эффективным дополнением к другим методам анализа, важно отметить, что его нельзя использовать отдельно: он может применяться лишь для усиления других методов анализа.

Поток исполнения

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

Чтобы решить эту проблему, инструмент Rational AppScan Developer Edition использует анализ периода выполнения для идентификации точного участка кода, выполняемого при вызове каждой проблемы динамического анализа. В этом потоке выполнения, представленном в текстовом или графическом виде, точно указывается соответствующая проблеме строка кода. Это облегчает поиск источника проблемы и ее решение.

Покрытие кода

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

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

Исходя из этих данных, несложно настроить конфигурацию и обеспечить более результативное сканирование. Инструмент Rational AppScan Build Edition использует эффективные функции платформы Eclipse Test and Performance Tools Platform (TPTP) и инфраструктуры IBM Rational Application Developer для визуализации и быстрой интерпретации точного покрытия кода в ходе сканирования.

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

Комплексный анализ

В этой статье мы рассмотрели три основных аналитических метода, их значение и связанные с ними возможные проблемы при изолированном использовании. Rational AppScan Developer Edition объединяет эти три различных метода для того, чтобы использовать их сильные стороны и компенсировать слабые. Как это достигается?

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

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

Однако это еще не все, что может делать IBM Rational AppScan Developer Edition . Совместно используя эти два метода , можно также использовать один из них для того, чтобы компенсировать слабые стороны другого. Вы можете использовать динамический анализ для того, чтобы выявить возможности использования уязвимостей злоумышленниками и определить приоритеты для результатов статического анализа, тогда как статический анализ может автоматически конфигурировать динамический анализ, что в значительной степени уменьшит количество конфигураций, необходимых для достижения заданного покрытия кода.

Корреляция результатов

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

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

Объединение двух наборов проблем не является простой операцией: динамический анализ описывает результат в терминах URL и параметров, а статический анализ имеет дело с классами и строками программного кода. К счастью, поток выполнения, предоставляемый анализом периода выполнения инструмента Rational AppScan Developer Edition отображает проблемы, обнаруженные динамическим анализом, на строки кода, с которым они связаны, где их можно сопоставить с кодом, связанным с проблемами, выявленными статическим анализом.

Это критически важно для точной корреляции, потому что обратная корреляция (отображение проблем, выявленных статическим анализом, на уровень URL и параметров) требует точной информации и знания условий развертывания приложения, что не всегда доступно инструменту статического анализа.

Симбиотический анализ

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

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

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

Взаимопомощь методов анализа

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

Таблица 2. Решения, помогающие справиться с ограничениями метода динамического анализа

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

Таблица 3. Решения, помогающие справиться с ограничениями статического анализа

Что мы узнали из этой статьи

Подытожим: инструмент Rational AppScan Developer Edition создавался как лучшее решение обеспечения безопасности Web-приложений для разработчиков. Это простое в применении решение обеспечения безопасности, которое встраивается в среду и процессы разработки и генерирует высокоточные и простые для интерпретации результаты.

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

Сильные стороны Rational AppScan Developer Edition - это сумма преимуществ разных методов, которые встроены в данный инструмент, а также преимущества, обусловленные их сочетанным применением. Конечный результат - это продукт, который:

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

Кроме того, инструмент Rational AppScan Developer Edition служит примером глубокого понимания нужд разработчиков, сред сборки и процесса поставки программного обеспечения в корпорации IBM. Сочетание различных технологий обеспечивает крайне мощный механизм, предоставляющий специальные средства для удовлетворения потребностей разработчиков.

Rational AppScan Developer Edition - прекрасное дополнение в семействе решений для обеспечения безопасности Web-приложений AppScan; новый программный продукт предоставляет возможность обеспечить безопасность Web-приложений уже при разработке - верный шаг на пути решения данной проблемы.