Что такое MITM (man-in-the-middle) атака и как с ней бороться
Что проверяют
Знаете ли вы, что на мобильном клиенте защита от посредника это не «мы используем HTTPS», а конкретные настройки платформы. Интервьюер смотрит, понимаете ли вы, кому доверяет устройство, что происходит при установке чужого корневого сертификата и как приложение ведёт себя в чужой сети.
Как отвечать
Суть атаки: между приложением и сервером встаёт узел, который терминирует оба соединения и читает или правит трафик. На мобильном это открытый Wi-Fi, подменённый DNS, прокси со своим корневым сертификатом на самом устройстве.
Что даёт платформа и что делаете вы:
- В современных версиях Android пользовательские сертификаты приложению по умолчанию не доверяются: чтобы читать ваш трафик, недостаточно поставить корень в систему.
- Конфигурация сетевой безопасности в манифесте: запрет открытого текста, список доверенных корней, послабления только для отладочной сборки.
- Пиннинг сертификата или публичного ключа для критичных доменов, например через CertificatePinner в OkHttp.
- Ничего чувствительного в логи и в незащищённый кэш: посредник на устройстве видит их тоже.
Где спотыкаются
Отключают проверку, чтобы заработал тестовый сервер: свой менеджер доверия, принимающий всё, или проверка имени хоста, всегда возвращающая истину. Такой код переезжает в релиз и делает атаку тривиальной. Послабления должны жить в конфигурации, привязанной к типу сборки.
Продолжают загрузку в обработчике ошибки сертификата в WebView. Это отдельная и очень заметная дыра: магазин приложений такую сборку отклоняет, а пользователь подмены не увидит.
Включают пиннинг и забывают про ротацию. Сертификат меняется, приложение перестаёт ходить в сеть сразу у всех, откатить нечем без выпуска новой версии. Пинить нужно с запасным ключом и сроком, а лучше промежуточный центр, а не конечный сертификат.