Автоматизированное тестирование безопасности с SoapUI и Hudson

база знаний
#1

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

Происхождение

Когда мы обратились к нашим пользователям с он-лайн исследованием пару лет назад, больше всего запросов получило «тестирование защищенности». Сначала нас это удивило, но задумавшись об этом, мы поняли, что это логично. Как и, например, функционирование; защищенность -  не функциональное требование, которое может иметь значительные последствия, если ею пренебречь – посмотрите на Sony, Facebook, Nokia, MySQL, и т.д. – все основные корпорации, которые за прошедшие несколько лет подвергались сравнительно простым атакам с внедрением SQL кода, направленным на данные, которые не предназначались для широкой общественности – наиболее показателен случай с  Sony, где записи более 1 миллиона пользователей, включая адреса и т.п. подверглись такой атаке и просочились в публичный доступ.   

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

Так что же такое Функциональное тестирование защищенности?

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

  1. ПСИ (плата сетевого интерфейса) и ее драйвера
  2. Сама операционная система, так как она обрабатывает входящие  запросы ПСИ
  3. Сервер целевого приложения, обрабатывающий запрос (например, Apache, IIS, и т.д.)
  4. Само приложение, что дает некоторую функциональность конечному пользователю.

В то время как в атаках, направленных на первые 2 слоя, часто используется грубая сила, чтобы отследить уязвимые точки в обработке связей, памяти, и т.д., атаки на 3 и 4 слои обычно нацелены на уязвимые точки, связанные с фактической функциональностью самого приложения.  Например, у сервера приложения может быть уязвимая точка безопасности, связанная с тем, как он обращается с идентификаторами сессии, в то время как само приложение могло бы иметь уязвимые точки в том, как оно выполняет определенную функциональность для клиента (например, поиск, обновление данных, и т.д.). Когда речь идет о первых 3 слоях, уже существует большое количество отличных инструментов (как бесплатных, так и коммерческих), которые помогут вам идентифицировать связанные уязвимые точки. И так как soapUI уже имеет поддержку функционального тестирования и тестирования производительности приложений их API, добавляющие тестирование защищенности в эту структуру, была естественным выбором, особенно потому, что она также, как оказалось, является довольно частой целью злонамеренных атак.

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

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

(Перейдите на веб-сайт soapUI, чтобы почитать больше о soapUI SecurityTests).

Как определить уязвимые точки?

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

Когда вы задумываетесь об этом – как бы вы в первую очередь идентифицировали уязвимые точки безопасности? Какой бы ответ вы получили назад, испытывая (например), атаку с внедрением SQL, что позволило бы вам идентифицировать присутствие уязвимости безопасности? На самом деле, это не всегда так легко, как  звучит. Очевидный признак "успешной" атаки состоит в том, что ваш целевой сервис прекращает отвечать на запросы (то есть, терпит крах), но это  относительно необычное открытие (но очень ценное, так как вы нашли его первым!). Чаще вы получаете назад сообщение об ошибке, которое говорит вам, что обслуживание не смогло обработать (злонамеренный) запрос – это могло бы быть хорошей вещью во время развития, но это также одна из тех ситуаций, в которых вы должны схватить хакера за руку; говорит ли сообщение об ошибке клиента что-то, чего они не должны знать о вашей системе? Например, какую базу данных вы используете? Какую версию? Какой язык или фреймворк? Возможно ей подвергаются внутренние IP номера (“не удалось связаться с …”)? Любой из них мог бы быть точно тем, что ищет клиент; информация позволяет им предназначаться для определенных атак на инфраструктуру вашей системы (существуют общественные базы данных известных запросов безопасности для большей части программного обеспечения), которые в свою очередь могли бы дать им заднюю дверь, которую они искали.  soapUI обеспечивает определенное обеспечение обнаружения этих видов реакций, мы называем его утверждением “Незащищенности уязвимой информации”; оно ищет сообщения, возвращенные вашим сервисом  для любой информации, которая могла бы подвергнуть воздействию системные детали клиента – номера версии, разработки программного обеспечения, и т.д. Список, конечно, конфигурируем поэтому, если у вас есть текст для поиска, вы абсолютно не захотите подвергнуться воздействию по ошибке вашего сервиса, Вы можете добавить это к общей конфигурации и удостовериться, что она не подвергается воздействию ни одного из ваших сервисов  во время тестирования защищенности. 

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

Итак, вкратце;

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

На что мы можем тестировать?

soapUI 4.0 имеет в общей сложности 10 сканирований безопасности, которые имитируют некоторые из наиболее обычных атак, используемых в наше время;

  • Сканирования защищенности от внедрения SQL и XPath пытаются провоцировать соответствующие уязвимые точки в коде сервера.
  • Сканирование на безопасность неверных данных, граничной проверки, Fuzzing и подозрительных вложений  отправляет неверный ввод чтобы спровоцировать ошибки, неожиданные ошибки, сообщения об ошибках и соответствующие сообщения об ошибках, которые могли бы повлиять на информацию системы
  • Сканы безопасности искаженных  XML и XML Bomb  пытаются исследовать уязвимые точки в целевых системах обработки XML  – XML Bombs могут потенциально закончиться  DOS атакой, если сервер не защищен или не сконфигурирован правильно.
  • Сканы межсайтового скриптинга помогают вам проверить как перманентные, так и не-перманентные уязвимые точки  XSS
  • Скан безопасности скрипта  (в истинном духе  soapUI) помогают вам записать ваши собственные мутации параметров на обычном языке скрипта.

Поддерживаемые протоколы и API

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

  • Запросы SOAP  – любой элемент или  параметр в запросе может быть использовано в качестве параметра сканами безопасности. Это для запроса, отправленного по  HTTP, HTTPS или JMS
  • REST / HTTP запросы, которые отправляют XML в своем теле  (POST и PUT) – такая параметризация применяется тут для SOAP запросов
  • REST / HTTP / AMF запросы с параметрами – эти параметры могут быть целью сканов безопасности также

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

Атаки с внедрением SQL кода

Атаки с внедрением SQL являются наиболее распространенными атаками современных веб-сайтов. Причины для этого (как минимум) двойственны;

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

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

  • select * from tb_user where username = ‘%uname%’  and password = ‘%pwd%’
    • Если ввод в скрипт это действительная комбинация uname/pwd, фактический код SQL будет выглядеть следующим образом;
      • For uname = bob, pwd = fish
        • select * from tb_user where username= ’bob’ and password = ’fish’

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

Сейчас, давайте посмотрим, что происходит, когда ввод следующий;

  • For uname = bob, pwd = ’ or ‘1’ = ‘1
    • select * from tb_user where username= ’bob’ and password = ’’ or ‘1’ = ‘1’

Значение, предоставленное как пароль, фактически “растворяется в” существующем SQL, используемом, для подтверждения пользователя и дает в результате SQL-оператор, который будет всегда возвращать ряды из базы данных, независимо от того какое представлено имя пользователя, приводя к тому, что пользователь будет всегда загружаться  – чистое зло!

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

И все же, как вам определить это в soapUI? Как уже упоминалось выше, специфическое утверждение XPath могло использоваться для обнаружения того, что недействительный SQL-оператор не приводит к успешному логину. Полная установка в soapUI выглядела бы следующим образом:

Сверху вниз в этом (несколько путанном) скриншоте мы можем увидеть следующее;

  1. Тест на защищенность, выполняющий сканирование внедрения SQL для запроса логина
  2. Диалог конфигурации сканирования внедрения SQL, имеющий два параметра (имя пользователя и пароль) сконфигурировал куда вставить несколько предварительно сконфигурированных SQL-операторов для имитации атаки внедрения SQL. Утверждение  XPath Match для сканирования безопасности видно внизу диалога конфигурации.
  3. Диалог конфигурации  XPath Match содержит  XPath –оператор, считающий количество возвращаемых значений в ответах  (идентификаторах сессий) и ожидающий, что значение должно быть  0 (иначе в результате запроса был бы получен успешный вход).

Проведение этого теста дает следующие вводы в лог безопасности;


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

Межсайтовый скриптинг

Атаки межсайтового скриптинга (“XSS” атаки) также одни из самых распространенных атак, направленных как на веб-приложения, так и на свои APIs. Как правило атака использует недостатки в клиентском веб-приложении, где она внедряет скрипт, выполненный в браузере и там может регистрировать действия пользователя, пароли, и т.д. и передает их, чтобы отделить сервер так, что он даже не заметил этого.

Атака может выполняться двумя основными способами;

  • Неустойчивые атаки: включают злонамеренный клиентский скрипт в запросе, который затем составит часть отвечающей веб-страницы и выполнит в браузере клиента. Это направлено прямо на веб-приложения, например, страница поиска могла бы показать фактическую строку для поиска на странице ответа (“вы искали…”) не покидая ее; если строка поиска является полностью раскрывшимся скриптом, она будет выполнена в клиенте и могла бы выполнить соответствующие нежелательные действия.

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

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

  • Вверху вы можете увидеть параметры поиска сконфигурированные в диалоге сканирования  межсайтового скриптинга
  • Было добавлено назначенное утверждение “Cross Site Scripting Detection” и его диалог конфигурации показа ниже  –  тут вы можете выбрать
  • проверить немедленный ответ для вставленного контента 
  • указать  обычный скрипт, который строит перечень вторичных  URL, которые будут проверены на вставленный контент; причина того, что это скрипт в том, что вам может потребоваться включить некоторые типа идентификаторов или других динамических параметров в эти URL, основываясь на немедленном ответе, полученном первоначальным запросом  (например, ответ может содержать уникальный идентификатор позиции, которую создал запрос и это должно быть пропущено как параметр ко вторичным запросам).

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

Автоматизация тестирования защищенности

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

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

soapUI предоставляет файл командной линии  securityrunner.bat/.sh, позволяющий проведение тестов защищенности в условиях сервера без монитора и он сгенерирует для вас соответствующий отчет. Такая автоматизация с  Hudson  (почти) чрезвычайно проста;

  1. Создайте новый свободный программный проект в  Hudson
  2. Сконфигурируйте шаг  “Execute Windows batch command” и соответствующие триггеры а также действия после построения:
  3. (Убедитесь, что у вас есть  –j опция, указанная в  раннере командной строки, которая будет отправлять отчеты, совместимые с  JUnit-, используемые далее действиями после построения)
  4. Если вы возлагаете функцию ведущего узла на проект soapUI в  архиве данных кода, сконфигурируйте соответствующую связь в разделе  “Source Code Management”  конфигурации Job.

И вы все сделали! Если вы запустите Job в Hudson, soapUI securitytestrunner выполнит сконфигурированные тесты защищенности, позволяющие вам следовать результату на Консоли;

Любые ошибки будут выведены в логе в ходе выполнения теста;

А конец лога покажет вам статус выполнения;

Возвращаясь назад к виду Проекта в  Hudson, он покажет агрегированный вид прошлых выполнений;

Углубившись в последний результат, вы увидите 

Элементарно!

Заключение

Надеюсь, мне удалось рассказать о следующих моментах;

  • Пренебрежение возможными уязвимыми точками и связанными вопросами в ваших сервисах и  API могут поставить ваши данные (и ваш бизнес!) под серьезную угрозу.
  • Серьезная забота о безопасности и знания, вложенные в нее – хорошая инвестиция, которую стоит сделать.
  • Основной механизм большинства уязвимых точек безопасности очень просто понять, протестировать и предотвратить.
  • С новой возможностью тестирования защищенности в soapUI 4.0 нет причин не выполнить, как минимум, базовое тестирование, проведя проверку самых базовых уязвимых точек.
  • Автоматизация выполнения тестов защищенности  (soapUI или нет) далее даст вам возможность быть в курсе событий и создать защиту от ненужной уязвимости.

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

Спасибо за ваше время!

Оле Ленсмар