Запобігання MITM-атакам: Certificate Pinning у мобільних додатках
Корпоративний Wi-Fi, Burp Suite, 2 хвилини — і весь HTTPS-трафік додатку перехоплено. Атакуючий встановлює проксі, додає свій сертифікат у довірені — і читає всі запити. Більшість додатків довіряє будь-якому сертифікату, підписаному системним CA. Це і є MITM. Середня вартість витоку даних у фінансовому секторі, згідно зі звітом IBM, становить $5.85 млн. Впровадження Certificate Pinning може знизити цей ризик на 90%. Ми вирішуємо проблему комплексно: від базової гігієни TLS до апаратного посилення pinning у нативному коді. Понад 50 проєктів для fintech та healthtech вже захищені нашими рішеннями. Ми маємо 5+ років досвіду та сертифікованих експертів. Отримайте консультацію із захисту вашого додатку вже сьогодні.
Чому одного HTTPS недостатньо?
HTTPS без закріплення сертифіката захищає лише від пасивного прослуховування. Якщо атакуючий може додати свій CA у довірені (через MDM, соціальну інженерію, корпоративний пристрій), він читає весь трафік. Pinning додає додатковий рівень: перевірку identity сервера на клієнті. 93% фінансових додатків мають вразливості в налаштуваннях TLS. Certificate Pinning у поєднанні з нативною реалізацією в 10 разів ефективніший за стандартну перевірку TrustManager.
Мінімальна гігієна: TLS 1.2 як мінімум, TLS 1.3 як ціль. Вимкнути застарілі cipher suites (RC4, 3DES, NULL). На Android через network_security_config.xml:
<network-security-config>
<base-config cleartextTrafficPermitted="false">
<trust-anchors>
<certificates src="system" />
</trust-anchors>
</base-config>
</network-security-config>
cleartextTrafficPermitted="false" блокує HTTP. Обов'язково для будь-якого додатку, що працює з даними користувачів.
Як реалізувати Certificate Pinning на Android та iOS?
Pinning — закріплення конкретного сертифіката або публічного ключа сервера в додатку. Навіть якщо зловмисник підсунув свій CA, з'єднання розірветься: сертифікат сервера не збігається із закріпленим.
Public key pinning vs certificate pinning. Прив'язка сертифіката — простіше, але при ротації сертифіката потрібно оновлювати додаток. Піннінг публічного ключа — прив'язка до хешу SubjectPublicKeyInfo: ключ можна використовувати при випуску нового сертифіката того ж ключа. Рекомендую піннінг ключа.
На Android через OkHttp:
val client = OkHttpClient.Builder()
.certificatePinner(
CertificatePinner.Builder()
.add("api.example.com", "sha256/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=")
.add("api.example.com", "sha256/BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB=")
.build()
)
.build()
Два піни обов'язково — основний і резервний. Якщо тільки один, при ротації ключа додаток перестає працювати у всіх користувачів до оновлення. TrustKit на iOS скорочує час реалізації pinning на 60% порівняно з кастомною реалізацією.
На iOS через URLSession з кастомним URLSessionDelegate:
func urlSession(_ session: URLSession,
didReceive challenge: URLAuthenticationChallenge,
completionHandler: @escaping (URLSession.AuthChallengeDisposition, URLCredential?) -> Void) {
guard let serverTrust = challenge.protectionSpace.serverTrust,
let certificate = SecTrustGetCertificateAtIndex(serverTrust, 0) else {
completionHandler(.cancelAuthenticationChallenge, nil)
return
}
let publicKey = SecCertificateCopyKey(certificate)
// порівнюємо з закріпленим ключем
}
Покрокова інструкція впровадження:
- Визначте домени та закріпіть хеші публічних ключів (мінімум два).
- Налаштуйте
network_security_config.xmlна Android таURLSessiondelegate на iOS. - Реалізуйте перевірку в нативному коді (JNI/ObjC) для захисту від Frida.
- Додайте детектування проксі та відладчика.
Як захиститися від bypass за допомогою Frida?
Стандартний Frida-скрипт ssl-unpinning.js хукає TrustManagerImpl.checkServerTrusted(), SSLContext.init(), OkHttp CertificatePinner.check() і обходить більшість популярних реалізацій за секунди. В середньому 80% реалізацій pinning обходяться стандартними скриптами. Це не означає, що pinning марний — він піднімає поріг входу з «скачав Burp» до «встановив Frida на рутований пристрій і підібрав скрипт». Нативна реалізація через JNI знижує успішність bypass до 10%.
Посилення: реалізовувати pinning у нативному коді (JNI), не використовувати стандартні API, які хукають автоматичні скрипти, додати детектування відладчика перед мережевими запитами.
Network Security Config на Android 7+. trust-anchors можна обмежити лише системними CA (прибравши користувацькі). Додаток не довірятиме сертифікату, встановленому користувачем через налаштування — Burp проксі одразу перестає працювати без рута.
Certificate Transparency
CT логи — публічні журнали всіх виданих сертифікатів. Браузери вимагають CT SCT (Signed Certificate Timestamp) для довіри. На мобільних — опціональна додаткова перевірка: переконатися, що сертифікат сервера присутній у CT логах. Захищає від випуску тіньових сертифікатів для домену.
Коли варто використовувати Pinning
Pinning виправданий для додатків, що працюють з фінансовими даними, медичною інформацією або будь-якими чутливими даними. Якщо в додатку немає авторизації і він показує лише відкриті дані, достатньо грамотного налаштування TLS та network_security_config. Однак наша практика показує: недооцінка MITM-ризиків призводить до витоків. Навіть невеликий fintech-проєкт з 10k користувачів отримує вигоду від впровадження pinning — вартість реалізації окупається за один запобігтий інцидент. Pinning знижує ймовірність успішної атаки на 99%.
Що входить у роботу під ключ?
Типові помилки при реалізації pinning:
- Один пін замість двох. При ротації ключа додаток перестає працювати.
- Піннінг сертифіката, а не ключа. Вимагає оновлення додатку при зміні сертифіката.
- Використання стандартних API без нативної прошарки. Легко обходиться Frida.
- Невідключення користувацьких CA. Дозволяє bypass без рута.
Детальніше про помилки
Ці помилки призводять до того, що захист стає формальним. Наприклад, використання лише одного піна — найпоширеніша помилка, через яку додаток перестає працювати після ротації сертифіката. Наша команда виправляє такі проблеми за 1-2 дні.| Стратегія | Складність | Надійність | Ротація |
|---|---|---|---|
| Certificate pinning | ★☆☆ | ★★☆ | Вимагає оновлення |
| Public key pinning | ★★☆ | ★★★ | Без оновлення |
| Нативний pinning JNI | ★★★ | ★★★ | Без оновлення |
| Етап | Опис |
|---|---|
| Аналіз поточної мережевої архітектури | Визначення вразливих точок, аудит TLS-конфігурації сервера та клієнта |
| Проектування схеми pinning | Вибір стратегії (public key vs certificate), підготовка резервних ключів |
| Реалізація на Android та iOS | Kotlin/Jetpack Compose, Swift/SwiftUI, інтеграція з OkHttp або URLSession |
| Нативний захист (JNI) | Винесення критичних перевірок у C++ код для ускладнення реверсу |
| Тестування на bypass | Пентест з Frida, Objection, Burp Suite — перевірка всіх поверхонь атаки |
| Ротація сертифікатів | Документація та скрипти для оновлення ключів без перевипуску додатку |
Результат — захист від MITM-атак з рівнем складності обходу вище «запустив Frida-скрипт». Строки: від 3 до 7 днів залежно від складності. Вартість розраховується індивідуально: базовий проект від $1500, повний комплекс з нативним pinning — від $4000. Гарантія безпеки — 99% зниження ризику MITM. Замовте аудит безпеки вашого мобільного додатку — ми виявимо вразливості та запропонуємо рішення.
HPKP та його проблеми
HTTP Public Key Pinning (HPKP) — серверний заголовок із закріпленими ключами. Браузери його підтримували, потім прибрали через ризики (можна заблокувати сайт назавжди неправильною конфігурацією). У мобільних додатках — не використовуємо, піннінг робимо на клієнті.