Смотрите на Кинопоиске с подпиской 
Условия: clck.ru/FMQND Условия: clck.ru/FMQND. 18+
Личный опыт
CRTWEB

Сниффер трафика и для чего он нужен тестировщику

Всем привет! Меня зовут Эрик, и я QA-инженер компании Creative. Сегодня хочу поднять тему анализаторов трафика или снифферов. Это понятие знакомо многим, как что-то вредноносное. В сети много публикаций про то, как лучше защищаться от снифферов и сохранять свои данные от хакерских атак. В этой статье мы взглянем на анализаторы трафика немного под другим углом и разберём, как можно применять их в работе тестировщика.

Для вашего удобства я разделил статью на три раздела:

  • познакомимся с принципом работы сниффера,
  • рассмотрим основные фичи сниффера,
  • разберём примеры использование сниффера в QA.

В качестве инструмента будем использовать Charles Proxy – кроссплатформенный http-прокси, который «сидит» между браузером (или мобильным приложением) и интернетом и перехватывает отправляемый и получаемый трафик (иллюстрация 1):

Иллюстрация 1

Принцип работы, или каким образом сниффер трафика справляется со своей задачей видеть всё

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

Это работает так: браузер отправляет запрос, сниффер его «проксирует» и отправляет от своего лица пользователю. Далее приходит ответ от сервера – он тоже поступает сначала в сниффер, а затем – к нам.

Когда нам надо просмотреть запросы, например из localhost – проблем не возникает, так как там используется протокол HTTP в чистом виде. При использовании протокола HTTPS и SSL-сертификата данные может читать только отправитель и получатель. Поэтому, для того чтобы просмотреть данные по определённому URL, нужно включить в Charles опцию SSL-proxying – и тогда данные станут видны и читаемы (об этом подробнее расскажу дальше).

А теперь – о фичах сниффера Charles Proxy

Структура интерфейса

Интерфейс Charles Proxy прост. Слева – список перехваченных запросов, справа – детали. В списке запросов есть две основные вкладки – Structure и Sequence.

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

Так выглядит интерфейс – на подобных продуктах он будет схожим (иллюстрация 2):

Иллюстрация 2

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

Иллюстрация 3

Фильтрация

В Charles Proxy очень много вариантов фильтрации запросов. Самое примитивное – это скопировать URL запроса в поле Filter, и мы будем видеть запросы только к этому хосту.

Примерно того же результата можно добиться, если в контекстном меню хоста выбрать Focus. Остальные запросы будут собраны в папке Other Hosts. Также Charles принимает регулярные выражения. Можно выбрать все запросы, в которых в начале имени хоста находится четыре буквы, а потом идёт точка: ^\w{4}\. Также можно блокировать определенные хосты. Например, я могу добавить наш тестовый стенд в blocklist, и все запросы с этого хоста будут со статусом failed (Connection dropped), либо вернутся с ошибкой 403.

Просмотр SSL-трафика

Вернёмся к фиче Charles Proxy, касающейся просмотра зашифрованного трафика. Это происходит очень простым путём: нужно установить SSL-сертификат в Charles proxy и включить SSL-proxying для нужного хоста в самом сниффере. Это можно сделать через контекстное меню конкретного хоста. Далее все запросы через него станут прозрачными, и мы сможем просмотреть тело запроса и ответа (иллюстрация 4):

Иллюстрация 4

Как использовать сниффер в QA

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

Charles vs Postman

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

  • достать токен авторизации с мобильного устройства,
  • получить тело ответа при оплате на мобильном устройстве,
  • выбрать запрос, поменять 1 символ в jwt токене и проверить, будет ли ошибка 401 (или вообще без него отправить запрос),
  • выбрать запрос, поменять ему метод POST на PUT и проверить, будет ли ошибка 405.

Если бы я делал это в Postman, нужно было бы ввести URL, выполнить запрос на авторизацию (конечно, с вводом своих данных) и получить токен. Потом в целевом запросе нужно было бы правильно ввести параметры и токен, и лишь после всей этой цепочки действий поменять Post на Put.

Как сделать проще? Сделать запрос с frontend мобильного устройства в Charles: контекстное меню -> клик на Compose, в теле запросе изменить Post на Put и нажать Execute. Вот так просто и красиво!

Break points

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

Есть вариант проще! Изменить ответ сервера. Для этого нужно включить функцию Break points, и у нас появится возможность на любом запросе редактировать и тело самого запроса, и тело ответа.

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

Также Break points можно использовать в другой фиче. Представим абстрактный список пользователей, у которых есть рейтинг. Если этот рейтинг ниже 3.0, то фронт должен показывать смайлик «Палец вниз». Рейтинг может варьироваться от 0.0 до 5.0.

Чтобы не создавать много пользователей с разными рейтингами, можно использовать Break points и подменять параметр «Рейтинг» в ответе. Это упростит работу.

REWRITE – автоматическая подмена запросов и ответов

Rewrite – это инструмент, позволяющий создавать правила, которые изменяют запросы и ответы, когда те проходят через Charles Proxy. Например, можно добавлять и изменять заголовок, искать и заменять текст в теле ответа или запроса и т.д. Настройка выглядит не такой уж и сложной: указывается Location = путь запроса. Далее создаётся правило, которое состоит из 5 разделов:

Type: Body (потому что параметр находится в теле);

Where: Response (потому что параметр находится в ответе от сервера);

Раздел Match: в «Value» указываем значение и параметр, который возвращает сервер; Раздел Replace: в «Value» указываем значение и параметр, который мы хотим увидеть на клиенте.

Вот так выглядит правило, если бы мы хотели увеличить в ответе количество «Бонусов» (иллюстрация 5):

Иллюстрация 5

Map Remote позволяет переадресовать запросы с одного URL «Map From» на другой – «Map To». Подменяет хост, путь целиком или только параметры в зависимости от вашей задачи. В примере ниже подменён запрос с prod-сервера на dev-сервер – чтобы посмотреть логи (иллюстрация 6):

Иллюстрация 6

Throttling – ограничение пропускной способности сети

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

No-caching

Инструмент No Caching предотвращает кэширование, манипулируя заголовками HTTP. Заголовки If-Modified-Since и If-None-Match удаляются из запросов, добавляются Pragma: no-cache и Cache-control: no-cache. Заголовки Expires, Last-Modified и ETag удаляются из ответов и добавляются Expires: 0 и Cache-Control: no-cache.

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

Block cookies

По аналогии с No caching эта функция удаляет заголовок Cookie из запросов. Также из ответа сервера она удаляет заголовок Set cookie. После включения этой опции сервер не сможет собирать Cookie с запросов. Также можно настраивать это для всех хостов или для какого-то конкретного.

Итог, Финиш, Завершение!

Мы рассмотрели основные функции снифферов трафика (в аналогичных программах fiddler, wireshark можно сделать все те же действия). Разобрали примеры использовании в тестировании и то, какие проблемы они могут помочь решить. Буду рад ответить на ваши вопросы в комментариях, спасибо за чтение!

0
Комментарии
Читать все 0 комментариев
null