Всем привет, на связи Дима Котиков! Я все еще люблю разрабатывать под Android/KMP, разбираться с инструментами для упрощения работы и латте на фундучном молоке. За пять лет мобильной разработки я неоднократно сталкивался с ситуацией, когда бэкенд запаздывает, а дедлайн горит.
Зимой 2026 мы получили задачу: новый финансовый инструмент, дедлайн через три месяца, готовность бэкенда — через полтора. Команда начала работу на моках и успела. В статье я расскажу, какие инструменты перехвата и мокирования трафика помогли нам выпустить фичу в срок без готового бэкенда, как настроить их за один вечер и почему понимание принципов работы TLS и MITM‑атаки экономит часы отладки.
Проблемы разработки и тестирования мобильных приложений и сайтов
Начну с истории, которая привела к тому, что появился целый цикл статей. В один прекрасный солнечный зимний день на daily‑созвоне бизнес‑аналитик принес задачу: необходимо реализовать фичу — новый финансовый инструмент для пользователей.
Исходные данные: бизнесовое описание функционала, готовые дизайны экранов и конкретная дата дедлайна — знакомая ситуация при запуске нового продукта. Системный аналитик берет задачу в проработку спецификации, определяется с необходимым перечнем доработок в различных системах, через некоторое время приносит команде список работ по части мобильной разработки, веб‑разработки, доработок бэкенд‑части.
Начинается этап планирования, на котором выясняется, что команды мобильной и веб‑разработки готовы браться за работу уже сейчас, а команда бэкенда сможет приступить к своей части доработок только через полтора месяца. Дедлайн на выпуск фичи — три месяца.
Мы рассмотрели различные варианты и поняли, что сейчас можем утвердить контракты взаимодействия между фронтенд‑ и бэкенд‑частями, тогда команда мобильной и веб‑разработки сможет начать реализацию фичи на моках согласованных контрактов end‑point‑ов, бэкенд начнет разработку своей части через полтора месяца и в позитивном исходе событий примерно месяц остается на интеграционные тесты QA‑специалистами и правки отловленных багов. План прост, потому красив — ударили по руками и закоммитились на работу.
В современной фронтенд‑ и мобильной разработке часто можно встретить ситуации, когда:
Необходимо реализовать какой‑то функционал, но на бэкенде еще не существует сервиса с REST API, необходимым для интеграции с фронтенд‑частью.
Запланирована миграция существующих end‑point, но реализации еще нет.
Тестовая среда нестабильна, тестовые серверы падают либо не соответствуют production‑среде.
Необходимо посмотреть отправляемые запросы и получаемые ответы в мобильном приложении или сайте: проверить корректность, отправку по специфичным условиям и тому подобное.
Необходимо подменить параметры или тело запроса и ответа, чтобы протестировать различные сценарии работы приложения или сайта.
Для решения этого спектра ситуаций можно мокать какие‑либо данные в коде, использовать встроенные в IDE средства отслеживания и подмены интернет‑трафика и так далее. Иногда этого либо бывает недостаточно, либо перечисленные способы не позволяют более полно протестировать функционал, либо же настройка различных тестовых данных прямо в коде сложна и может сломать функционал. А еще нужно не забыть после тестов удалить эти моки из кода.
Бывает, что нам нужно отправлять какие‑то запросы и получать какие‑то ответы, но end‑point по какой‑то причине недоступны или не готовы. В таких случаях нужно использовать специализированные инструменты: перехватчики (снифферы) интернет‑трафика и инструменты мокирования ответов от end‑point‑ов.
Наша история с разработкой фичи на моках в конечном итоге закончилась удачно и все успели к дедлайну. Важную роль в разработке мобильной и веб‑части, а еще при тестировании как раз и сыграли инструменты перехвата и мокирования.
Инструменты тестирования и управления HTTP‑трафиком
Для разработки функционала с использованием моковых контрактов end‑point нам могут быть полезны инструменты для перехвата HTTP‑запросов и подмены ответов на моковые контракты. Еще можно перехватить запрос и направить его на локальный сервер, на котором будет развернута тестовая среда с нужными нам моковыми ответами на запросы. Рассмотрим инструменты, которыми можно воспользоваться для этих задач.
Для перехвата, подмены и перенаправления HTTP‑запросов пригодятся снифферы трафика — программы, позволяющие перехватывать HTTP‑запросы и проводить с ними разного рода манипуляции:
подменять «на лету» URL, хедеры, тело запросов и ответов;
подменять ответы на запросы заранее подготовленными тестовыми json‑файлами;
перенаправлять запросы на рабочие тестовые среды;
приостанавливать запросы и ответы на них, чтобы проверить различного рода состояния ожидания или загрузки в мобильном приложении или на сайте;
смотреть количество отправляемых запросов и правильность передаваемых параметров и так далее.
Примеры снифферов: Charles Proxy, Proxyman, OWASP ZAP.
При отсутствующем или нестабильном бэкенде могут быть полезны инструменты, позволяющие развернуть сервер локально на ПК и замокать необходимые end‑point.
Примеры таких программ: JSON Server, WireMock и Mockoon.
Прежде чем окунуться в настройку и использование инструментов, необходимо понимать в общих чертах принцип их работы. Это нужно, чтобы знать что делать и куда копать в случае, когда что‑то будет работать не так как ожидается. Поэтому разберем как работает HTTP‑соединение и как можно перехватывать трафик в HTTP‑соединении.
Общий принцип работы HTTP‑соединений и возможности просматривать трафик в них
В нашем разборе работы HTTP‑соединения опущены некоторые шаги для упрощения. Чтобы отправить запрос с клиента, устанавливается соединение и происходит так называемый Handshake: TCP, затем TLS. При Handshake происходит обмен ключами и генерация сессионного ключа, после чего этим ключом шифруются передаваемые данные и передаются между клиентом и сервером.
Пошагово это выглядит так:
1. ClientHello — клиент отправляет серверу поддерживаемые им версии TLS, поддерживаемые алгоритмы шифрования и рандомный набор байт (Random_C).
2. ServerHello — сервер отвечает, какую версию TLS из доступных клиенту он выбрал, алгоритм шифрования из предложенных клиентом и свой рандомный набор байтов (Random_S).
3. Сервер отправляет сертификат, обычно это файл с расширением.pem,.crt,.cer. В файле сертификата указан публичный ключ, доменное имя и цифровая подпись удостоверяющего центра сертификатов.
4. Клиент проверяет подлинность сертификата — использует ключи root‑сертификатов, установленных в систему, чтобы расшифровать цифровую подпись сертификата с сервера. Еще клиент убеждается, что сертификат выдан для того домена, к которому он обращается, и срок действия сертификата не истек.
5. Клиент генерирует симметричный ключ шифрования на открытом ключе сертификата и отдает серверу, сервер расшифровывает ключ закрытым ключом сертификата (схема генерации ключа шифрования сложнее и зависит от версии TLS).
6. На симметричном ключе генерируется Session Keys, на которых и будет происходить шифрование и расшифровка трафика.
7. Передача данных, зашифрованных на Session Keys, получение ответа от сервера и расшифровка на этих же Session Keys.
Соберем все шаги в общую схему.
Подключение программы‑сниффера и прослушивание трафика в расшифрованном виде в этой схеме получается с помощью MITM‑атаки.
MITM (Man‑in‑the‑Middle) или «человек посередине» — кибератака, при которой злоумышленник внедряется в канал связи между клиентом и сервером, перехватывая, прослушивая или изменяя передаваемые данные.
В случае с программой‑сниффером для того, чтобы перехват трафика MITM‑атакой удался, на клиенте устанавливается root‑сертификат. Он используется при проверке подлинности сертификата от сниффера.
Пошагово схема взаимодействия «Клиент‑Сниффер‑Сервер» будет выглядеть так:
1. В систему Клиента добавляется root‑сертификат (вручную или через малварь).
2. Клиент отправляет ClientHello на сервер.
3. Сниффер (или MITM‑прокси) перехватывает ClientHello и пересылает его от имени Сниффера на Сервер.
4. Сервер отвечает ServerHello Снифферу и передает ему свой оригинальный сертификат.
5. Сниффер проверяет сертификат Сервера и на лету генерирует фальшивый сертификат для хоста Сервера, при этом подписывает фальшивый сертификат тем же root‑сертификатом, который установлен и у Клиента (пункт 1).
6. Сниффер отправляет сгенерированный фальшивый сертификат Клиенту.
7. На Клиенте проверяется фальшивый сертификат от Сниффера, и, так как на Клиенте установлен root‑сертификат от Сниффера как доверенный, при проверке фальшивого сертификата root‑сертификатом не выводится никакой ошибки. Клиент думает, что все хорошо.
8. Клиент генерирует сессионный ключ на фальшивом сертификате, Сниффер делает то же самое, между Клиентом и Сниффером устанавливается соединение, зашифрованное на сессионном ключе с использованием фальшивого сертификата.
9. Между Сниффером и Сервером происходит генерация сессионного ключа, но уже на оригинальном сертификате от Сервера, устанавливается соединение между Сниффером и Сервером, зашифрованное на оригинальном сертификате Сервера. Сервер тоже ничего не подозревает.
10. От Клиента уходит запрос к Снифферу, зашифрованный на фальшивом сессионном ключе.
11. Сниффер расшифровывает запрос от Клиента фальшивым ключом, зашифровывает его оригинальным ключом от сессии Сниффер‑Сервер и отправляет запрос на Сервер.
13. Сервер расшифровывает данные оригинальным ключом сессии, подготавливает ответ, шифрует его оригинальным ключом и отдает Снифферу.
14. Сниффер расшифровывает ответ оригинальным ключом, зашифровывает фальшивым ключом сессии Клиент‑Сниффер, отправляет ответ на Клиент.
15. Клиент расшифровывает ответ, все счастливы.
Вся схема выглядит так:
Примерно так работает прослушивание трафика при успешной MITM‑атаке: ни клиент, ни сервер не подозревают, что с ними общается посредник в виде сниффера. При этом посредник может видеть все данные в незашифрованном виде и производить какие угодно манипуляции: подменить что‑либо в запросе, установить соединение не с целевым сервером, а с вредоносным.
Заключение
Мы разобрали, как работает HTTP‑соединение между клиентом и сервером и как сниффер встраивается в цепочку «клиент‑сервер» и может производить манипуляции с передаваемыми данными.
Краткие выводы:
Для перехвата HTTP‑трафика используется механизм MITM‑атаки.
При MITM‑атаке клиент соединяется не напрямую с сервером, а со сниффером/MITM‑прокси, в свою очередь сниффер/MITM‑прокси соединяется с сервером.
Для успешного перехвата трафика снифферу нужно прикинуться сервером для клиента и клиентом — для сервера.
Чтобы клиент не заподозрил, что трафик уходит не туда и не разорвал соединение со сниффером, на клиент должен быть установлен root‑сертификат, про который знает сниффер. Этим root‑сертификатом будет подписываться фальшивый сертификат сниффера и потом проверяться на клиенте.
Фальшивый сертификат на лету генерирует и передает сниффер на клиент, используется для шифрования данных, которые передаются между клиентом и сниффером.
Между сниффером и легитимным сервером, в свою очередь, устанавливается обычное HTTP‑соединение и используется реальный сертификат от сервера для шифрования данных, передаваемых между сниффером и сервером.
В следующих статьях разберем настройку сниффера трафика на примере OWASP ZAP, где нам и пригодятся знания о MITM‑атаке, root‑сертификате и о том, какую роль это все играет при перехвате интернет‑трафика. Не переключайтесь!
