Всем привет! Меня зовут Эрик, и я QA-инженер компании Creative. Сегодня хочу поднять тему анализаторов трафика или снифферов. Это понятие знакомо многим, как что-то вредноносное. В сети много публикаций про то, как лучше защищаться от снифферов и сохранять свои данные от хакерских атак. В этой статье мы взглянем на анализаторы трафика немного под другим углом и разберём, как можно применять их в работе тестировщика.
Для вашего удобства я разделил статью на три раздела:
- познакомимся с принципом работы сниффера,
- рассмотрим основные фичи сниффера,
- разберём примеры использование сниффера в QA.
В качестве инструмента будем использовать Charles Proxy – кроссплатформенный http-прокси, который «сидит» между браузером (или мобильным приложением) и интернетом и перехватывает отправляемый и получаемый трафик (иллюстрация 1):
Принцип работы, или каким образом сниффер трафика справляется со своей задачей видеть всё
Благодаря тому что снифферы являются инструментами, которые позволяют перехватывать, анализировать и модернизировать все проходящие через них запросы, их удобно использовать в ситуациях, когда из потока нужно извлечь сведения или создать нужный ответ сервера.
Это работает так: браузер отправляет запрос, сниффер его «проксирует» и отправляет от своего лица пользователю. Далее приходит ответ от сервера – он тоже поступает сначала в сниффер, а затем – к нам.
Когда нам надо просмотреть запросы, например из localhost – проблем не возникает, так как там используется протокол HTTP в чистом виде. При использовании протокола HTTPS и SSL-сертификата данные может читать только отправитель и получатель. Поэтому, для того чтобы просмотреть данные по определённому URL, нужно включить в Charles опцию SSL-proxying – и тогда данные станут видны и читаемы (об этом подробнее расскажу дальше).
А теперь – о фичах сниффера Charles Proxy
Структура интерфейса
Интерфейс Charles Proxy прост. Слева – список перехваченных запросов, справа – детали. В списке запросов есть две основные вкладки – Structure и Sequence.
На вкладке Structure запросы рассортированы по хостам-папкам. Наведя на любой из них, можно получить всю информацию о количестве запросов к этому корневому хосту, доле удачных, таймингах, размерах и т.п. Фактически, здесь представлена вся та же информация, которую можно получить из панели разработчика в браузере. Нужно просто выбрать конкретный URL – и мы увидим код ответа, версии протоколов, контент и т.п. Тело запроса, заголовки, cookie (если есть) можно посмотреть в разных форматах – даже в HEX.
Так выглядит интерфейс – на подобных продуктах он будет схожим (иллюстрация 2):
На вкладке Sequence запросы выведены по времени в формате настраиваемой таблицы. Видно, когда начался запрос, сколько он длился, его размер, статус и т.п. Наведя на конкретную строку, мы получим ту же информацию о теле, заголовках, что на вкладке Structure (иллюстрация 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):
Как использовать сниффер в 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):
Map Remote позволяет переадресовать запросы с одного URL «Map From» на другой – «Map To». Подменяет хост, путь целиком или только параметры в зависимости от вашей задачи. В примере ниже подменён запрос с prod-сервера на dev-сервер – чтобы посмотреть логи (иллюстрация 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 можно сделать все те же действия). Разобрали примеры использовании в тестировании и то, какие проблемы они могут помочь решить. Буду рад ответить на ваши вопросы в комментариях, спасибо за чтение!