Глава3 кроссплатформенная система автоматизации тестирования

3. 1. Анализ системы автоматизации тестирования

Для проведения проверки безопасности системы на предмет возможности хакерских атак выбран сканнер OWASP Zed Attack Proxy Project (OWASP ZAP).

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

Преимущества перед остальными продуктами????

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

• Тестирование на XSS атаки.

• Тестирование на возможность SQL-инъекций.

• Тестирование приложения методом Fuzzing.

• Контроль сетевых протоколов.

• Составление отчетов по результатам тестирования.

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

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

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

Для тестирования будет использован специально разработанная среда для тестирования безопасности на базе операционной системы Linux - Kali Linux 1.0.6, что сократит затраты на настройку программного обеспечения.

Kali linux версии 1.0.6 был выпущен 9 января 2014 года, что подчеркивает актуальность использования данной платформы, которая содержит более 300 стандартных инструментов, предназначенных для тестирования безопасности систем, в частности: Aircrack-ng, Ettercap, Hydra и другие. У данной операционной системы открытый исходный код, она является безопасной средой разработки с обширной поддержкой беспроводных устройств.

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

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

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

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

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

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

Устанавливается нулевое значение счетчика для работы с основным массивом (i=0). Из массива берется i-ая ссылка, происходит попытка перехода на указанный адрес. Если данная страница недоступна либо не найдена (сервер вернул код ошибки 404 ), то производится запись в отчет о недоступности страницы и i-ая ссылка получает признак недоступности. Производится определение наличия непроверенных ссылок в основном массиве ссылок. Если таковые в массиве отсутствуют, следовательно, все ссылки просмотрены и происходит завершение первого этапа сканирования. Если это происходит при обработке первой ссылки, то пользователю выводится сообщение о невозможности проведения работ и необходимости проверить исходные данные. Если же массив ссылок содержит непроверенные элементы, то производится инкремент счетчика для работы с основным массивом (i=i+1) и из основного массива выбирается очередная ссылка. Если же указанная страница системы доступна, то сканер переходит на неё и получает исходный HTML-код.

Рисунок 3.1- Алгоритм создания массива ссылок для дальнейших проверок

Далее полученный код проверяется на наличие внутренних ссылок ( под внутренними ссылками понимаются ссылки, которые ведут на внутренние страницы системы, то есть они начинаются с того же домена, что и страница или начинаются с "/", или с "./", или с "../", или с "#" ). Общий алгоритм данной проверки имеет следующий вид:

var siteURL = "http://" + top.location.host.toString();

var $internalLinks = $("a[href^='"+siteURL+"'], a[href^='/'], a[href^='./'], a[href^='../'], a[href^='#']");

Если на странице отсутствуют внутренние ссылки, данная ссылка удаляется, производится проверка на наличие непроверенных элементов в основном массиве, если ссылок нет, то происходит завершение составления карты системы, если же в массиве есть ссылки, то производится инкремент счетчика для работы с основным массивом (i=i+1) и выбирается очередная ссылка. Если же на проверяемой странице содержатся внутренние ссылки, то необходимо определить эти ссылки и записать уникальные в основной массив. Для реализации данного механизма создается дополнительный массив, в который заносятся все найденные на странице ссылки. Счетчик для работы с дополнительным массивом принимает начальное значение (j=0). Из дополнительного массива берется j-ая ссылка. Которая последовательно сравнивается с каждым элементом основного массива, Если данная ссылка не содержится в основном массиве, то она добавляется в него, ссылка удаляется из дополнительного массива. Если ссылка содержится в основном массиве, то она просто удаляется без занесения в основной массив. После этого производится проверка наличия непроверенных ссылок в дополнительном массиве, если таковые содержатся, то счетчик работы с дополнительным массивом инкрементируется и данная ссылка извлекается из дополнительного массива для проверки. Если же проверены все элементы дополнительного массива, то происходит проверка основного массива на предмет наличия непроверенных ссылок и проверка повторяется. Если же проверены все ссылки из основного массива, то происходит удаление элементов, имеющих атрибут недоступности. Возможна настройка выведения результатов создания карты системы в отчет.

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

Рисунок 3.2 - Алгоритм проведения проверок на наличие XSS уязвимостей

Основной этап сканирования. Начинается после составления карты системы. Начинается с установки счетчика для работы с основным массивом в нулевое значение и взятие из основного массива ссылок i-ой ссылки. Производится переход на данную страницу с целью получения кода страницы. Полученный код проверяется на наличие параметров, которые передаются на сервер в пакетах с использованием POST и GET метода. При использовании GET метода, передаваемые параметры передаются в строке URL (HTTP-заголовке) и могут быть заданы принудительно путем изменения значения непосредственно в URL.

Методом GET не стоит отправлять конфиденциальные данные вроде паролей, серийных номеров и т. д., так как они передаются открыто через адресную строку и могут быть переданы в виде ссылки. Не стоит также с помощью GET выполнять важные операции, например удаления: script?delete=all, так как поисковики, программы да и сами пользователи могу перейти по этой ссылке. Ну и конечно же самый распространённый способ взлома скриптов — через подбор GET-переменных таким образом, чтобы нарушить работу сайта или получить конфиденциальные данные.

Если переменные GET используются напрямую в SQL-запросах внутри скрипта без фильтрации, то почти на 99% ваш скрипт уязвим для SQL-инъекций. Ведь злоумышленник может просто приписать к URL дополнительную часть SQL-запроса и получить всё, что ему захочется.

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

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

Если на странице содержатся передаваемые параметры, то наступает процесс непосредственной проверки. Все найденные на странице параметры передаются в дополнительный массив. Устанавливается нулевое значение счетчика для работы с дополнительным массивом (j=0). Далее из массива извлекается данный j-ый параметр. В базе знаний сканера содержатся значения параметров для проверки наличия уязвимостей различного рода, для уязвимости к XSS данные значения хранятся в массиве строк.

Передаваемому параметру последовательно присваивается значение из базы знаний и происходит отправка данного параметра на сервер. После обработки сервер отправляет ответ на компьютер пользователя. При проведении проверки на уязвимости к XSS атакам полученный код проверяется на наличие в коде выполненной последовательности символов из присвоенного значения. Рассмотрим данную процедуру на примере значения "><script>alert(уязвимость к XSS атакам)</script>из базы знаний компьютера.

Это значение является наиболее распространенным при проверке. При отсутствии фильтрации полученных значений на сервера часть "> закрывает скрипт и выполняет <script>alert(уязвимость к XSS атакам)</script>, что соответствует появлению на стороне пользователя окна.

Если у пользователя появляется данное сообщение, то найдена уязвимость к XSS. Данное сообщение будет, если на передаваемое значение не настроено никакого фильтра. Далее не составит труда составить и передать скрипт для копирования Cookie пользователя и отправки на сторонний ресурс, что позволит злоумышленнику получить параметры сессии пользователя и авторизоваться с данными правами в системе.

Если же используется фильтр значений, то приходится модифицировать значения передаваемых параметров, и конечная последовательность, при которой может быть произведена атака, принимает вид: >>>><<script>alert(уязвимость к XSS атакам)</script>.

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

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

Пример стандартных ответов сервера будет храниться в отдельном массиве базы знаний сканера.

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

Рисунок 3.3 - Классификация найденной уязвимости

Расшифровка классификации???

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

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

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

Тестирование безопасности системы будет продемонстрировано на примере информационно-поисковой системы «Нормативная база».

Информационно-поисковая система «Нормативная база» предназначена для обеспечения эффективной работы сотрудников с внутренними нормативными документами.

Система состоит из следующих подсистем:

• Подсистема управления документами;

• Подсистема поиска и отображения документов;

• Подсистема отчетности;

• Подсистема интеграции;

• Подсистема администрирования;

• Подсистема безопасности.

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

Подсистема управления документами предназначена для обеспечения возможностей добавления, изменения, удаления и публикации документов в системе и обеспечивает реализацию следующих функций:

• Добавления документов;

• Изменения документов;

• Работу с исходными документами;

• Формирование образа документов;

• Поиск заголовков в образе и составление оглавления;

• Поиск ссылок в документе;

• Удаление документов;

• Управление справочниками.

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

• Сервис поиска документов;

• Сервис отображения документов;

• Работа с сохраненными результатами поиска;

• Поиск документов по шаблону;

• Просмотр текста образа документа;

• Печать документа;

• Отправка документа на адрес электронной почты;

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

• Просмотр последних поступлений документов.

Подсистема отчетности предназначена для предоставления следующих групп отчетов:

• Статистические отчеты;

• Отчеты по правам доступа.

Подсистема отчетности в части формирования статистических отчетов обеспечивает формирование отчетов, содержащих сведения о документах системы:

• Общее число документов в системе;

• Число загрузок исходных документов;

• Формирование отчета в разрезе тематик документов.

Подсистема интеграции обеспечивает возможность взаимодействия системы со следующими системами:

• Файловая система пользователя;

• Адресной книгой корпоративного информационного портала;

• Автоматизированной системой делопроизводства и документооборота;

• Информационной системой «Нормативная база».

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

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

Подсистема администрирования представлена следующими сервисами:

• Сервис по управлению правами пользователей системы;

• Сервис настройки конфигурационных параметров системы;

• Сервис управления подпиской и почтовыми уведомлениями.

В части сервиса по управлению правами пользователей системы реализован механизм управления правами пользователей. Разграничение прав доступа в cистеме осуществляется с помощью настроенных групп безопасности. В cистеме существуют следующие группы пользователей:

• Группы, соответствующие подразделениям – создаются и поддерживаются автоматически (автоматически поддерживается набор групп и пользователи, входящие в состав групп);

• Группы, соответствующие ролям пользователей cистемы;

• Группы, обеспечивающие предоставление определенных прав доступа к cистеме.

В части сервиса настройки конфигурационных параметров cистемы существует возможность настройки следующих параметров:

• Параметры поиска и просмотра документов;

• Параметры управления документами;

• Параметры интеграции;

• Параметры безопасности.

В cистеме реализован механизм рассылки почтовых уведомлений. Уведомления отправляются по электронной почте пользователям и администраторам cистемы при возникновении определенных событий.

Подсистема Безопасности обеспечивает соответствие cистемы требованиям по информационной безопасности.

Подсистема безопасности обеспечивает выполнение следующих функций:

• Отображение полного списка пользователей;

• Выгрузка прав доступа пользователя;

• Блокировка/Разблокировка пользователя;

• Ведение журнала событий;

• Хранение журнала аудита системы;

• Обеспечение и проверка целостности системы.

Структурная схема системы представлена на Рисунке 3.4.

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

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

К выходным данным относятся:

• Экранные формы;

• Печатные формы;

• Файлы экспорта внутреннего образа редакции документа;

• Файлы экспорта отчетов подсистем отчетности и безопасности;

• Записи о событиях cистемы в журнале событий.

Общая схема организации структуры cистемы представлена Рисунке 3.4. Система устанавливается на веб-приложение (Web Application) SharePoint. В систему входит набор коллекций сайтов, служебная база данных, задачи таймеров, модули расширения для FAST Search Server 2010 for SharePoint, сервис транслитерации, сервис журналирования переходов к результатам поиска.

Рисунок 3.4 - Структурная схема взаимодействия подсистем системы

На уровне веб-приложения SharePoint настраивается ASP.NET HTTP модуль для обработки запросов к системе. Основная задача данного модуля состоит в том, чтобы не допустить пользователей системы (кроме системной учетной записи, администраторов коллекции сайтов и пользователями обладающими правами «Полный доступ» на уровне корневого сайта в коллекции сайтов) к служебным страницам MS SharePoint Server 2010. Помимо этого, модуль осуществляет обработку пользователей, которые заблокированы в системе. В случае попытки заблокированного пользователя обратиться к системе будем произведено перенаправление на страницу, отображающую соответствующую информацию. Если пользователь обращается к служебной странице SharePoint, то происходит его перенаправление на главную страницу сайта.

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

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

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

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

Рисунок 3.5 - Структура системы на уровне программного обеспечения

На основе информации о принадлежности пользователя к подразделению происходит добавление пользователя в группу, созданную для подразделения. В профиле пользователя проставляется значение User для поля «НБ: Роли пользователя».

Внутренняя топология сети представлена на Рисунке 3.6.

Рисунок 3.6 - Внутренняя топология системы

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

При последующих срабатываниях задачи таймера происходит обновление данных, в случае если они изменились в представлениях. Если профиль пользователя существует и при обновлении для данного пользователя выставлен флаг «Уволен», а с момента увольнения прошло больше одно месяца (относительно даты увольнения сотрудника, указанной в профиле пользователя) происходит удаление пользователя из всех групп, из промежуточной базе данных удаляется вся информация о правах на тематики и документы, которые были предоставлены пользователю, запускается задание таймера по удалению прав с объектов. После этого, из поля «Национальная база: Роли пользователя» профиля пользователя происходит удаление всех ролей.

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

Если внедрить ранее выбранную кроссплатформенную систему автоматизации OWASP Zed Attack Proxy Project, то процесс тестирования будет происходить намного быстрее и качественнее.

Интерфейс сканера безопасности представлен на Рисунке 3.7.

Рисунок 3.7 - Интерфейс работы сканера

Для просмотра полного списка и выбора уязвимостей, на которые будет производиться проверка необходимо перейти в Анализ/Параметры сканирования и выбрать XSS атаки и настроить пассивный сканер траффика. Диалоговое окно настройки параметров сканирования предоставлен на Рисунке 3.8.

Также необходимо включить контроль сохраняемых Cookie.

Рисунок 3.8 - Настройка параметров сканирования безопасности системы

Для проверки системы с точки зрения авторизированного пользователя необходимо настроить параметр учетной записи пользователя для текущего сеанса проверки. В форму с добавлением учетной записи ввести имя пользователя, пароль, выбрать порт для проверки и указать начальный URL для которого эти данные потребуется. Пример заполненной формы пользователя представлен на Рисунке 3.9.

Рисунок 3.9 - Добавление учетной записи пользователя

Для запуска первого этапа сканирования нажать кнопку «Атаковать» и перейти во вкладку «Паук», в которой будет отображаться полная информация о составлении карты системы. На данной странице отображается прогресс проведения первого этапа, а также общее количество найденных ссылок на страницах системы. Слева отображается составленная карта сайта, дальнейшая работа с которой подразумевает активное сканирование и поиск уязвимостей при обработке передаваемых параметров. Пример процесса составления карты системы представлен на Рисунке 3.10.

Рисунок 3.10 - Составление карты системы

Всего по завершению первого этапа сканирования найдено 1595 ссылок на внутренние страницы системы, время, потраченное на составление карты – 6 минут 34 секунды. Далее сканер автоматически переходит на второй этап сканирования системы, непосредственная проверка на наличия уязвимостей. При этом есть возможность настройки пассивного сканирования и сканер вместо того, чтобы высылать запросы серверу, будет «перепроверять» действия тестировщика информационной безопасности. При таком режиме работы, сканер не имеет возможности изменять отсылаемые запросы, а занимается только анализом полученных пакетов, данная возможность дает хороший результат как дополнение к работе тестировщика, для увеличения качества проверок. На системе документооборота будет проведен этап активного сканирования на уязвимости. Для просмотра в режиме реального времени проводимых проверок необходимо перейти на вкладку «Активное сканирование». На данной вкладке также присутствует индикатор завершенности проверок. Для каждого запроса и ответа сервера сохраняется соответствующая запись на вкладках «Запрос» и «Ответ». Сохраняются передаваемые параметры и также сохраняется ответ сервера на данную проверку. Пример передаваемого запроса представлен на Рисунке 3.11.

Как видно из рисунка в параметре «submit» содержится проверка в зашифрованном виде на уязвимость системы. При просмотре ответа сервера и его анализе производится решение о наличии уязвимости. На странице ответа сохраняется как заголовок ответа сервера, так и его тело. Вид окна ответа представлен на Рисунке 3.12.

Рисунок 3.11 - Передаваемый пакет

Рисунок 3.12 - Принятый пакет

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

После завершения второго этапа сканирования, происходит переход на вкладку «Оповещения» для предоставления информации о результатах сканирования системы. Пример итогового результата представлен на Рисунке 3.13.

Рисунок 3.13 - Результат сканирования системы

Существует возможность различной группировки полученного результата:

• Перечисление типов;

• По приоритету;

• По подтвержденности;

• По URL места уязвимости.

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

Как видно из отчета, время, затраченное на базовое сканирование системы по нескольким видам уязвимостей, составляет 208 минут и 21 секунду. А общее количество запросов составило 6219.

Рисунок 3.14 - Время, затраченное на проведение проверок

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