методы тестирования веб приложений
Современные методы исследования безопасности веб-приложений
В данной статье я расскажу о современных методах и подходах к тестированию безопасности веб-приложений.
Начало исследования
Для успешного тестирования веб-приложений необходимо применять систематизированный подход или методологию. Наиболее известные это OWASP и WASC. Они являются наиболее полными и формализованными методологиями на сегодняшний день.
Далее необходимо определится с веб-приложением — для исследования можно взять последнюю версию одной из бесплатных CMS, и установить в нее уязвимый плагин (уязвимые версии можно скачать с сайта exploit-db.com).
Методы тестирования
Т.к. мы не являемся веб-разработчиками данного приложения, мы пропустим этап тестирования при создании архитектуры и разработки приложения (но стоит отметить что они важны — при разработке).
Есть несколько принципов тестирования, которые мы можем применить:
DAST – динамический (т.е. требующий выполнения) анализ приложения без доступа к исходному коду и серверной части, по сути BlackBox.
SAST – статический (т.е. не требующий выполнения) анализ приложения с доступом к исходному коду веб-приложения и к веб-серверу, по сути это анализ исходного кода по формальным признакам наличия уязвимостей и аудит безопасности сервера.
IAST – динамический анализ безопасности веб-приложения, с полным доступом к исходному коду, веб-серверу — по своей сути является WhiteBox тестированием.
Анализ исходного кода – статический или динамический анализ с доступом к исходному коду без доступа к серверному окружению.
Эти методы полностью подойдут для тренировки навыков выявления уязвимостей веб-приложения при наличии у вас доступа к веб-приложению, либо частиноч, если вы исследуете веб-приложение, к примеру, при участии в программе BugBounty.
Основные этапы
Для полноты тестирования необходимо стараться следовать нижеприведенным рекомендациям кастомизирую те или иные этапы в зависимости от веб-приложения.
Разведка
Контроль доступа
Фаззинг параметров
Проверки логики работы веб-приложения
Проверка серверного окружения
Итого
Имея план тестирования приложения мы можем шаг за шагом исследовать все его компоненты на наличие тех или иных уязвимостей. Исходя из веб-приложения те или иные пункты могут быть дополнены специфичными для данного приложения проверками.
В следующей статье я расскажу об инструментарии, подходящем для тестирования веб-приложения по данному чек-листу.
Функциональное тестирование современных web-приложений
Для своевременного обнаружения таких ситуаций и выполнения непрерывной интеграции необходимо функциональное тестирование web-приложения. В статье пойдет речь о двух бесплатных open-source решениях:
Рассматриваемые решения обеспечивают похожий, на первый взгляд, ряд возможностей.
Пример функционального теста
Примером для тестирования будет web-приложение вида TodoMVC, с сервером на node.js и клиентской SPA-страницей на React+Redux-е. Для приближения условий тестирования к реальным, во все redux-овские action-ы добавлены случайные задержки, эмулирующие сетевое взаимодействие с backend-ом (за основу взято это).
В дальнейшем будет предполагаться, что тестовое web-приложение запущено по адресу http://localhost:4000/. Функциональный тест будет простым и включать в себя добавление todo-элемента, правку его содержимого, отметку как выполненное/невыполненное задание и удаление.
Языком для написания тестов в обоих фреймворках является JS (ES2016 и ES5 соответственно для TestCafe и Nightwatch), однако это прекрасно подходит для web-приложений, написанных на любом языке. Если Вы давно не разрабатывали на JS, то необходимо учитывать, что современные редакции ушли очень далеко от старого ES3, и включают удобные средства для написания кода, объектно-ориентированного и функционального программирования и многое другое.
Исходный код функционального теста, проверяющего изложенный выше use-case-сценарий, может быть таким:
Адрес тестируемой web-страницы определяется в fixture-части, за которыми следуют функциональные тесты, по завершении каждого из которых web-страница автоматически восстанавливается в исходное состояние. Для поиска DOM-элементов на странице используются testcafe-специфические Selector-ы, использующиеся в качестве обертки для функции, которая будет выполнять запрос к DOM-модели, возможно используя аргументы.
В этом примере первый селектор представляет обертку над document.querySelector, а второй — над document.querySelectorAll с callback-функцией, помогающей выбрать нужный элемент из списка. Обертка Selector принимает опции, здесь в частности устанавливается максимальное время, в течении которого testcafe будет ожидает появление элемента с заданными характеристиками в DOM-модели.
Сам функциональный тест представляет собой набор асинхронных вызовов Selector-ов, между которыми производятся действия посредством test controller-а, инстанцированного переменной t. Назначение большинства его методов очевидно из названий (click, typeText и т.д.), а t.setNativeDialogHandler используется для предотвращения генерации alert-подобных окон, которые могут “подвесить” тест — что очень удобно.
Для запуска тестов сначала надо создать конфигурационный файл nightwatch.json, описывающий расположение тестов, пути и настройки для selenium-server и webdriver-ов, а далее использовать простую команду nightwatch в текущей директории.
Если использовать Microsoft Web Driver (Edge), то nightwatch.json может выглядеть примерно так:
Исходный код функционального теста, проверяющий аналогичный рассмотренному выше use-case-сценарий, может выглядеть так:
Среди особенностей кода легко заметить, что Nightwatch не поддерживает эмуляцию двойного щелчка по элементу — вместо этого приходится реализовывать обходной путь с inject-функцией на клиенте, выполняющую dispatchEvent на целевом элементе управления.
Удобной возможностью Nightwatch является поддержка XPath, который предоставляет значительно более широкие возможности по селекции элементов DOM-модели, по сравнению с CSS-селекторами — взять хотя бы извлечение элемента по его текстовому наполнению, что довольно часто встречается в функциональном тесте.
Сравнение функциональности TestCafe и Nightwatch
Язык написания тестов:
T: Из коробки предоставляется возможность написания тестов непосредственно на языке ES2016, что позволяет писать простой и читабельный код тестов на том же языке, что и само web-приложение Это также удобно в случаях, когда требуется импортировать определенный модуль из тестируемого проекта.
N: Устаревший ES5-синтаксис и exports-конструкции в исходном коде функционального теста (Возможность прикрутить ES6 все-таки есть, но на костылях)
Поддержка асинхронных операций:
T: Все API-функции основаны на Promise-ах, что позволяет описывать произвольную асинхронную логику работы теста, и при этом интегрировать собственные функции со стороны node.js. Благодаря поддержке ES2016, этот код можно записывать при помощи async и await конструкций в последовательном стиле.
N: В тесте можно реализовать последовательность команд по анализу и управлению содержимым web-страницы, однако они складываются во внутреннюю очередь событий, и интегрировать собственные асинхронные функции с ними проблематично.
Вставка клиентского кода на лету:
T: Легко осуществляется при помощи соответствующего API, поддерживается создание и последующее выполнение клиентских функций, однократное исполнение injected-кода, замена существующих функций в исходной web-странице, а также исполнение клиентских функций в callback-ах node.js-функций с привязкой к тестовому контроллеру.
N: Есть функциональность для выполнение JS-кода на клиентской стороне, или даже вставки целого script-блока, но средств интеграции с тест-контроллером не предоставляется. Подходит для простого синхронного интегрируемого JS-кода, но в более общем случае интеграция проблематична.
Работа с курсором мыши:
T: Предоставляется виртуальный курсор, посредством которого осуществляются hover, click и drag-события для целевым визуальных элементов страницы. В процессе выполнения теста можно наблюдать за перемещением курсора и выполняемыми действиями.
N: Средства для работы с курсором вообще есть — это функции из webdriver api, однако работать с действиями, сложнее одиночного левого клика, довольно проблематично — взять хотя бы двойной щелчок.
Реализация взаимодействия с браузером в TestCafe и NightWatch
Фреймворк NightWatch основывается на известной, в некоторой мере уже традиционной, библиотеке Selenium webdriver, преимущества которой включают устоявшееся API, высокую степень документированности и обширное Q&A в интернете, а также универсальный и достаточно низкоуровневый доступ к браузеру… Взаимодействие с браузерами организуется посредством webdriver-ов, по одному на каждый обозреватель.
Основной недостаток — webdriver-ы существуют далеко не для всех браузеров, а также требуют отдельного обновления при смене версии самого браузера, а еще для работы необходимо наличие внешней зависимости от Java. Более подробно о технологии webdriver можно прочесть в http://www.w3.org/TR/webdriver/
Фреймворк TestCafe основан на подходе, в котором взаимодействие с приложением браузера сведено к минимуму — используются только функции открытия окна/вкладки, изменения размера окна, перехода по URL-адресу и некоторые другие.
Взаимодействие с web-страницей производится посредством web-proxy сервера testcafe-hammerhead, осуществляющего загрузку удаленной web-страницы и модификацию исходного JS-кода таким образом, чтобы выполнить шаги функционального теста, посредством интеграции с DOM-моделью, поиска и управления визуальными элементами, выполнение произвольного JS-кода и так далее. (https://github.com/DevExpress/testcafe-hammerhead/)
Метод TestCafe более универсален, поскольку может потенциально работать с любым браузером, поддерживающим HTML5 и ES 5+, в то время как NightWatch требует соответствующий webdriver. Кроме того, это позволяет прогонять тесты не только на локальном браузере, но на любом браузере в сети, включая любые мобильные — без установки какого-либо ПО на телефоне.
Пример тестирования вышерассмотренного web-приложения в браузере на Android показан в следующем видео: https://youtu.be/2na5jkqvUx0
Однако testcafe-hammerhead имеет и потенциальные недостатки: накладные расходы на анализ и модификацию исходного JS-кода тестируемой страницы, производимые в свою очередь JS-коде ядра Testcafe, а также теоретически некорректная работа тестируемой web-страницы или интеграции теста, если исходный код был проксирован неверно. (К примеру, замещение alert-окна в testcafe можно обойти таким примером http://pastebin.com/p6gLWA75 — и неумешленно или специально “подвесить” его выполнение)
Выводы
Конечно, selenium-webdriver, на котором основан Nightwatch, является популярным и широко известным решением, имеющем стандартный API-интерфейс, что несомненно является его достоинством. Кроме того, в смежных областях задач, например автоматизации целевого web-ресурса в заданном браузере — фактически написании бота для удаленного web-сайта — selenium-webdriver подходит лучше.
Однако для функционального тестирования разрабатываемого или поддерживаемого web-приложения TestCafe несомненно впереди по широкому ряду причин:
1) Запуск тестов в любом браузере, в том числе мобильных телефонах и планшетах, причем это может производиться пакетным образом для всех интересуемых браузеров и не требует установки никакого дополнительного ПО.
2) Удобство написания теста на ES2016, включающее async/await-конструкции для последовательной записи кода, импорт программных элементов из самого проекта, передачу функций в клиент и обратно и так далее — широкие возможности по интеграции и управлению клиентским web-приложением.
3) Широкая поддержка selector-ов для визуальных элементов, легкое взаимодействие с DOM-моделью, виртуальный курсор мыши, эмуляция разнообразных и сложных взаимодействий пользователя со страницей.
Таким образом, среди существующих open-source решений для функционального тестирования web-приложений, TestCafe выглядит очень привлекательным вариантом, к тому же при сочетании легковесности и функциональности.
Функциональное тестирование веб-приложений без боли
Иногда в жизни бывает так — вот ждёшь, ждёшь чего-то, изучаешь теорию по данному вопросу, рассматриваешь разные подходы к решению, дискутируешь с такими же ищущими как ты, внимаешь гласу признанных гуру, но не продвигаешься дальше ни на дюйм. Потом бросаешь, забываешь вообще об этом вопросе, занимаешься другими делами, и вдруг — на тебе, всё встало на свои места, из разрозненных элементов сложилась чудесная мозаика, нагрянуло просветление, а волосы вдруг стали густыми и шелковистыми.
Вот примерно такая же история с автоматическим функциональным(приёмочным) тестированием. О такой классной штуке как автоматические тесты писал ещё Сам Кент Бек. Ну, а автоматические функциональные тесты — это вообще лакомый кусок для современных agile методик разработки ПО. Например, тот же Scrum — включает в себя практику «Демо», в ходе которой заказчику нужно показать развитие продукта, осуществлённое в ходе итерации.
Я, конечно, не спец agile-практик, и не изучал рынок инструментов для функционального тестирование веб проектов — возможно, и раньше в этом сегменте всё было зашибись. Но за те 5 лет, что я работаю программистом — я всего лишь пару раз слыхал такие слова автоматическое функциональное тестирование, Selenium и ни разу не видел применения на практике.
Так вот, возвращаясь к лирическому вступлению, мне кажется, что то колоссальное качественное изменение как раз и произошло недавно. И есть ощущение, что в ближайшее время только ленивый пренебрежет функциональным тестированием своего веб проекта.
Что же собственно произошло? Я подписан на RSS-ку блога Springsource, и однажды обнаружил статью с вот таким интригующим названием — The future of functional web testing?.
Инструменты Geb и Spock, описанные в данной статье, меня зацепили, и я решил попробовать.
Собственно далее, я постараюсь наступить на горло песне прервать приступ графоманства и описать простой пример с использованием данных инструментов.
Установка инфраструктуры
Первый функциональный тест
В данном параграфе будет приведён пример автоматизации простого, но несомненно полезного функционального теста.
Суть функционального теста будет состоять в том, чтобы:
— войти на сайт Википедии
— набрать в поиске «Функциональное тестирование»
— убедиться в том, мы действительно попали на желаемую страницу
(например, мы поищем вхождение в текст страницы строки «это тестирование ПО в целях проверки реализуемости функциональных требований»)
Структура каталога проекта
Структура каталога проекта для тестирования выглядит следующим образом:
pom.xml — файл с описанием проекта в Maven
simplefunctest — пакет, в котором будут храниться классы для описания тестов
Собственно Тест
class MyFirstSpec extends GebSpec <
def «test search functional testing wiki page» () <
given: «we are at main wiki page»
to MainWikiPage
when : «try to search functional testing page»
searchField.value( «Функциональное тестирование» )
searchButton.click()
class MyFirstSpec extends GebSpec
def «test search functional testing wiki page» ()
given: «we are at main wiki page»
to MainWikiPage
when : «try to search functional testing page»
searchField.value( «Функциональное тестирование» )
searchButton.click()
then : «check we are on functional testing page»
at FunctionalTestingWikiPage
Описание главной страницы Википедии
class MainWikiPage extends Page
Описание страницы результата поиска
class FunctionalTestingWikiPage extends Page <
Собственно старт теста
Бинго! У вас должен стартовать FireFox(он настроен как браузер по умолчанию для тестов) и выполнить(без вашего участия(. )) то, что мы задумали.
Возможно, Firefox вам будет недостаточно и вы заходите прогнать тест в IE(для этого настроен специальный профиль):
Заключение
Я не буду обременять ни себя, ни вас описанием библиотек-их есть у него в достаточном количестве на сайтах этих библиотек, а просто порекомендую забрать из репозитория проект и попробовать самостоятельно.
QA evolution
Особенности тестирования web-приложений
Web-приложения — динамично развивающаяся сфера. Не все подходы и методы, применяемые для тестирования классических приложений могут быть применимы для тестирования web-приложений.
Web-приложение — это клиент-серверное приложение, в котором клиентом выступает браузер, а сервером web-сервер, что уже является по сути двумя разнополыми программами, которые необходимо тестировать как отдельно, так и в связке.
Рис.1.1. Структура web-приложения
Почти все современные программы ориентированы на работу с сетью. Хранение данных web-приложений осуществляется, преимущественно, на сервере, обмен информацией происходит по сети. Когда мы видим ошибку в сетевой среде, то зачастую сложно точно указать, где именно она произошла, и потому режим работы, или сообщение об ошибке которое мы получаем, может быть результатом ошибок, случившихся в разных частях сетевой системы.
Имея много общего с тестированием классических приложений, тестирование web-ориентированных приложений имеет свои особенности, связанные прежде всего со средой функционирования. Имея компонентные, структурные и технологические особенности, web-приложениям присущи особенности режимов работы, инсталляции, запуска, остановки и удаления, а также формирования интерфейсов. Работая всегда с сетью и с большим количеством пользователей, web-приложения подразумевают под собой разные права доступа для разных пользователей.
Логика web-приложения распределена между сервером и клиентом, хранение данных осуществляется на сервере, обмен информацией происходит по сети.
Одним из преимуществ подхода является тот факт, что клиенты не зависят от конкретной операционной системы пользователя, поэтому web-приложения являются межплатформенными сервисами.
Особенности тестирования web-приложений:
Классическое приложение работает с использованием одной или семейства родственных технологий.
Web-приложение работает с использованием принципиально различных технологий.
Классическое приложение “ монолитно е”. Состоит из одного или небольшого количества модулей. Не использует серверы БД, web-серверы и т.д.
Web-приложение — “ многокомпонентное ”. Состоит из большого числа модулей. Обязательно использует серверы БД, web-серверы, серверы приложений.
Web-приложение работает в режиме “запрос-ответ”, т.е. известно о некотором наборе действий только после запроса на сервер.
Классическое приложение использует для формирования интерфейса пользователя относительно устоявшиеся и стандартизированные технологии.
Web-приложение использует для формирования пользовательского интерфейса стремительно развивающиеся технологии, множество которых конкурирует между собой.
Классическое приложение практически не использует сетевые каналы передачи данных.
Web-приложение активно использует сетевые каналы передачи данных.
Классическое приложение запускается и останавливается редко.
Web-приложение запускается и останавливается по факту поступления каждого запроса, т.е. очень часто.
Классическое приложение: количество пользователей, одновременно использующих приложение, подвержено контролю, ограничено и легко прогнозируемо.
Web-приложение: количество пользователей, одновременно использующих приложение, сложнопрогнозируемо и может скачкообразно меняться в широких диапазонах.
Классическое приложение: выход из строя тех или иных компонентов сразу становится очевидным.
Web-приложение: выход из строя некоторых компонентов оказывает непредсказуемое влияние на работоспособность приложения в целом.
Классическое приложение — процесс инсталляции стандартизирован и максимально ориентирован на широкую аудиторию пользователей. Не требует специфических знаний. Добавление компонентов приложения выполняется стандартным способом с использованием одного и того же инсталлятора.
Web-приложение — процесс инсталляции часто недоступен конечному пользователю. Инсталляция требует специфических знаний. Процесс изменения компонент приложения не предусматривается или требует квалификации пользователей. инсталлятор отсутствует.
Классическое приложение: процесс деинсталляции стандартизирован и выполняется автоматически или полуавтоматически.
Web-приложение: процесс деинсталляции требует специфических знаний для вмешательства администратора и часто сопряжен с изменением кода среды функционирования приложения, БД, настройки системного ОС.
Классическое приложение: среда функционирования стандартизирована и не сильно влияет на функционирование приложения.
Web-приложение: среда функционирования очень разнообразна и может оказать серьезное влияние на работоспособность и серверной, и клиентской части.
Особенности тестирования web-приложений
Тестирование веб-приложений — задача, с которой ручному тестировщику приходится сталкиваться довольно часто. В этой статье мы расскажем некоторые особенности данного процесса.
Кроссбраузерность
Первое — это проверка на правильность отображения и функционирования web-приложения на различных браузерах. Под правильностью понимается соответствие стандартам и требованиям.
Важно: перед началом тестирования надо выяснить, какие конкретно браузеры поддерживаются.
Что проверяем при кроссбраузерном тестировании: — функциональные возможности продукта, которые реализуются на стороне клиента; — правильно ли отображаются элементы графики; — корректно ли отображаются шрифты, размеры текстовых символов; — доступны ли формы, присутствующие на сайте, выполняют ли они свои функции, являются ли интерактивными.
Необходимо понимать, что тестировать надо все основные браузеры, однако отдельное внимание следует уделить браузеру Internet Explorer. Именно в с этим браузером чаще всего возникают проблемы. Особое внимание тут следует обращать на фокус полей, масштабируемость, работу JavaScript.
Web-формы
Формы для заполнения — важнейшие составляющие веб-приложений. Именно с помощью форм осуществляется взаимодействие клиента с сервером (клиент — это, к примеру, веб-браузер, через который пользователь обращается к серверу приложения).
На что стоит обращать особое внимание: — обязательные поля для заполнения: отмечено ли, что они являются обязательными, а также являются ли они обязательными на самом деле, по факту (проверка пустых значений); — ввод специальных данных — спецсимволов: #%@№&^$*<><>[]; — наличие валидации (что происходит, когда пользователь вводит невалидные значения, получает ли пользователь сообщение об ошибке, что происходит с данными после их ввода).
Хорошая практика — составлять чек-лист UI-компонентов, которые нужно проверить (радио-баттоны, дроп-дауны, чек-боксы).
Но теперь давайте сделаем небольшое отступление и скажем, что валидация бывает как со стороны сервера, так и со стороны клиента.
Валидация со стороны сервера
Представьте, что перед вами стандартная форма входа на сайт с полями для логина и email. Введенные вами значения будут отправлены на сервер и проверены на наличие в базе данных (происходит аутентификация). Если вы уже зарегистрированы и ввели правильные данные, то получите доступ и соответствующие права (происходит авторизация), если нет — увидите сообщение о том, что указанный вами email/логин не существует.
Валидация со стороны клиента
Речь идет о выполнении проверки значений непосредственно при вводе данных. Для этого в Presentation Layer подключают специальные скрипты валидации (Presentation Layer — слой представления веб-приложения — то, что мы видим, UI).
Что такие скрипты могут проверять: — ввел ли пользователь в поле email символ @; — заполнены ли обязательные поля; — ввел ли пользователь цифры в поле ввода номера телефона; — не совпадают ли поля, которые не должны совпадать, и т. п.
Для чего это нужно? Ответ очевиден: валидация на стороне клиента уменьшает число обращений к серверу, снижая нагрузку на него.
База данных
При тестировании web-приложений не забываем про базы данных.
Что проверяем: — данные, введенные со стороны клиента, сохранились в базе; — данные, записанные в БД, корректно отображаются на клиенте; — данные можно удалить/изменить; — число открытых соединений с БД; — скорость обработки запросов.
Сервер
Сервер тестируется отдельно от клиента. Проверяем: — наличие валидации со стороны сервера (о ней упоминали выше); — корректность ответа сервера на подаваемый запрос со стороны клиента (правильный код состояния, заголовок, тело и т. д.) — тут используют такие инструменты, как Fiddler и Postman; — скорость обработки запросов.
Пользователи, multiple users
Как известно, одновременно с веб-приложением может работать большое число пользователей. Какие проверки здесь необходимы: — нагрузочное тестирование (сколько пользователей могут без проблем работать одновременно); — аутентификация и авторизация (что происходит на стороне сервера); — конкурентный (параллельный) доступ к ресурсам (скорость работы приложений не должна меняться); — уровни доступа пользователей.