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

Всем привет, на связи Дима Котиков! Я все еще люблю разрабатывать под 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-сертификате и о том, какую роль это все играет при перехвате интернет-трафика. Не переключайтесь!