MITM-атаки в мобильных приложениях — что это, виды и защита от перехвата

Что такое MITM-атака?

Man-in-the-Middle (MITM) — тип кибератаки, при которой злоумышленник тайно встраивается в канал связи между двумя сторонами. Злоумышленник может перехватывать, читать и модифицировать передаваемые данные, оставаясь невидимым для обеих сторон.

В мобильных приложениях MITM-атаки особенно опасны, поскольку устройства постоянно подключаются к различным сетям — домашним, офисным, публичным Wi-Fi в кафе и аэропортах. Каждое переключение сети потенциально создаёт окно для атаки. По данным Verizon Mobile Security Index (2025), 43% организаций хотя бы раз сталкивались с MITM-атаками на корпоративные мобильные устройства.

Главная опасность MITM — скрытность: пользователь и сервер не получают сигналов о перехвате. Сессия выглядит нормальной, данные передаются, ошибок сертификатов нет (если атакующий использует собственный сертификат). Обнаружить атаку можно только на уровне сетевой инфраструктуры или с помощью специализированных инструментов.

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

Основные виды MITM-атак

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

ARP Spoofing в локальной сети

ARP Spoofing — техника, при которой злоумышленник отправляет поддельные ARP-пакеты в локальную сеть, связывая свой MAC-адрес с IP-адресом шлюза. После этого весь трафик жертвы направляется через устройство атакующего, который пересылает его шлюзу, оставаясь невидимым.

Для проведения атаки достаточно инструментов вроде Ettercap или BetterCAP, которые автоматизируют ARP-спуфинг. Атака возможна только в пределах одной подсети, поэтому наиболее уязвимы пользователи публичных Wi-Fi-сетей. Современные сети с динамической ARP-инспекцией (DAI) на управляемых коммутаторах блокируют этот тип атаки.

Защита на уровне приложения от ARP Spoofing невозможна — это проблема сетевой инфраструктуры. Однако приложение может детектировать аномалии в сетевом подключении с помощью библиотек вроде TrustKit для iOS или Network Security Config для Android.

DNS Spoofing и перехват трафика

DNS Spoofing (или DNS Cache Poisoning) — подмена DNS-записей на пути от клиента к DNS-серверу. Злоумышленник перехватывает DNS-запрос приложения и возвращает поддельный IP-адрес, направляя трафик на свой сервер вместо легитимного.

Атака особенно эффективна в публичных сетях, где DNS-сервер назначается автоматически через DHCP. Злоумышленник может настроить собственный DNS-сервер, который возвращает подставные IP-адреса для целевых доменов. Пользователь видит легитимный URL в браузере, но соединяется с сервером атакующего.

Защита от DNS Spoofing на стороне приложения реализуется через DNS-over-HTTPS (DoH) или DNS-over-TLS (DoT), которые шифруют DNS-запросы. Android 9+ и iOS 14+ поддерживают системный DoH, приложение может явно включить эту опцию.

SSL Stripping — обход HTTPS

SSL Stripping — атака, при которой злоумышленник понижает защищённое HTTPS-соединение до незащищённого HTTP. Техника эксплуатирует то, что многие пользователи вручную вводят example.com вместо https://example.com, и первое соединение устанавливается через HTTP.

Инструменты вроде sslstrip (Moxie Marlinspike, 2009) и bettercap автоматически перехватывают HTTP-запросы, устанавливают HTTPS-соединение с сервером от своего имени и передают расшифрованный трафик клиенту через HTTP. При этом браузер не показывает значок замка — пользователь не знает, что соединение не защищено.

Современная защита — HTTP Strict Transport Security (HSTS): сервер сообщает браузеру, что все будущие соединения должны быть только через HTTPS. HSTS Preload List дополнительно защищает от первой атаки, но требует предварительной регистрации домена.

Как работает MITM-атака в мобильных приложениях

Типичная MITM-атака на мобильное приложение проходит четыре этапа. Каждый этап использует разные уязвимости, и для полной защиты требуется перекрывать все векторы.

Первый этап — внедрение: злоумышленник оказывается на пути трафика между устройством и сервером. Это может быть ARP Spoofing в локальной сети, поддельная точка Wi-Fi (Evil Twin) или компрометация DNS-сервера провайдера. Мобильные устройства особенно уязвимы при автоматическом подключении к открытым сетям.

Второй этап — перехват: после внедрения злоумышленник начинает читать все пакеты, которыми обмениваются приложение и сервер. На этом этапе он собирает метаданные: URL запросов, размер пакетов, cookies, заголовки. Даже если данные зашифрованы, метаданные могут раскрыть структуру приложения и бизнес-логику.

Третий этап — дешифровка (если трафик зашифрован): злоумышленник устанавливает два TLS-соединения — одно с сервером (используя подставной сертификат), другое с клиентом. Приложение считает подключение безопасным, но атакующий видит все данные в открытом виде. Без Certificate Pinning это работает для любого сертификата, установленного в системном хранилище.

Четвёртый этап — модификация и эксфильтрация: злоумышленник может не только читать, но и изменять передаваемые данные. В финансовых приложениях это может означать подмену номера счёта получателя, в API-запросах — изменение параметров авторизации. iOS и Android рекомендуют реализовывать проверку целостности ответов на уровне приложения.

Примеры кода: защита от перехвата на Android и iOS

Рассмотрим практические примеры защиты от MITM-атак с использованием Certificate Pinning на Kotlin и Swift. Эти примеры блокируют подмену сертификата даже при наличии скомпрометированного системного хранилища.

Certificate Pinning на Android (OkHttp)

OkHttp — стандартная HTTP-библиотека для Android, которая поддерживает CertificatePinner. Укажите SHA-256 хеш сертификата вашего сервера — любые другие сертификаты будут отклонены.

import okhttp3.CertificatePinner
import okhttp3.OkHttpClient

val certificatePinner = CertificatePinner.Builder()
    .add(
        "api.example.com",
        "sha256/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA="
    )
    .build()

val client = OkHttpClient.Builder()
    .certificatePinner(certificatePinner)
    .build()

Certificate Pinning на iOS (URLSession)

На iOS используйте URLSessionDelegate для проверки сертификата сервера вручную. Сравнивайте SecCertificateRef с локально сохранённой копией.

class SessionDelegate: NSObject, URLSessionDelegate {
    func urlSession(
        _ session: URLSession,
        didReceive challenge: URLAuthenticationChallenge,
        completionHandler: @escaping (
            URLSession.AuthChallengeDisposition,
            URLCredential?
        ) -> Void
    ) {
        guard let serverTrust = challenge.protectionSpace
            .serverTrust else { return }

        let pinnedCert = SecCertificateCreateWithData(
            nil,
            pinnedCertData as CFData
        )

        let serverCerts = (0..<SecTrustGetCertificateCount(serverTrust))
            .compactMap { SecTrustGetCertificateAtIndex(serverTrust, $0) }

        if serverCerts.contains { CFEqual($0, pinnedCert) } {
            completionHandler(.useCredential, URLCredential(trust: serverTrust))
        } else {
            completionHandler(.cancelAuthenticationChallenge, nil)
        }
    }
}

Network Security Config на Android

Android поддерживает декларативную защиту через XML-файл network_security_config.xml, который блокирует трафик на уровне ОС без написания кода.

<!-- network_security_config.xml -->
<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
    <domain-config cleartextTrafficPermitted="false">
        <domain includeSubdomains="true">api.example.com</domain>
        <pin-set expiration="2027-07-01">
            <pin digest="SHA-256">AAAAAAAAAAAAAAAAAAAAAAAAAAAA</pin>
        </pin-set>
    </domain-config>
</network-security-config>

Методы защиты мобильных приложений от MITM

Комплексная защита от MITM-атак включает меры на уровне приложения, сервера и сетевой инфраструктуры. Ниже приведены основные рекомендации для Android и iOS.

Используйте Certificate Pinning — привязку сертификата сервера в коде приложения. В отличие от стандартной TLS-проверки, которая доверяет любому сертификату из системного хранилища, Certificate Pinning проверяет конкретный сертификат или его публичный ключ. OkHttp на Android и TrustKit на iOS предоставляют готовые реализации этого механизма.

Принудительно используйте HTTPS и HSTS: все сетевые запросы должны идти через HTTPS, а сервер должен возвращать заголовок Strict-Transport-Security. Для Android добавьте android:usesCleartextTraffic="false" в манифест — это запретит HTTP-соединения на уровне ОС. iOS по умолчанию запрещает HTTP с iOS 9 через App Transport Security (ATS).

Реализуйте проверку целостности ответов: подписывайте ответы сервера цифровой подписью, которую проверяет приложение. Даже если злоумышленник перехватит HTTPS-трафик (через прокси с переустановкой сертификата), он не сможет подделать подпись без приватного ключа сервера. Используйте JWT с RS256 или HMAC-подписи для критических операций.

На серверной стороне включите HTTP Public Key Pinning (HPKP) — директива, которая указывает браузеру или приложению, какой сертификат считать валидным для данного домена. Однако HPKP требует осторожности: неправильная настройка может заблокировать доступ к приложению на длительный срок. Google рекомендует использовать HPKP только в комбинации с резервными сертификатами.

По данным NIST SP 800-52 Rev. 2 (2024), комбинация TLS 1.3, Certificate Pinning и HSTS устраняет 99% известных векторов MITM-атак на мобильные приложения. Разработчикам рекомендуется протестировать защиту с помощью инструментов вроде mitmproxy перед публикацией приложения.