Pendahuluan
Salah satu tantangan paling konsisten yang kami temui saat melakukan penetration testing pada aplikasi Android adalah certificate pinning. Mekanisme ini dirancang untuk mencegah serangan man-in-the-middle (MitM) dengan memverifikasi bahwa sertifikat yang digunakan server adalah sertifikat spesifik yang sudah dikenal oleh aplikasi, bukan sekadar sertifikat yang valid secara umum.[1]
Tujuannya jelas, yaitu mencegah tools seperti Burp Suite atau mitmproxy mengintersepsi traffic antara aplikasi dan server. Namun dalam konteks penetration testing, kemampuan mem-bypass certificate pinning adalah langkah fundamental sebelum analisis traffic API bisa dimulai.
Artikel ini menjelaskan bagaimana certificate pinning bekerja secara kriptografis, teknik bypass yang umum digunakan dalam engagement nyata, studi kasus dunia nyata di mana kelemahan pinning berdampak langsung, serta cara tim development mendeteksi dan memperkuat implementasinya.
Fondasi Kriptografis: TLS Handshake dan Rantai Kepercayaan
Untuk memahami mengapa pinning diperlukan, penting memahami dulu bagaimana TLS bekerja tanpa pinning. Dalam TLS handshake standar, sebagaimana didefinisikan dalam RFC 8446 untuk TLS 1.3, klien memverifikasi identitas server dengan memeriksa apakah sertifikat yang disodorkan ditandatangani oleh Certificate Authority (CA) yang dipercaya, membentuk rantai kepercayaan dari sertifikat server hingga root CA.[12]
Proses ini melibatkan pertukaran ClientHello dan ServerHello, autentikasi sertifikat, serta negosiasi kunci simetris untuk enkripsi sesi.[11] Model kepercayaan ini kuat, tetapi punya satu kelemahan mendasar: klien mempercayai siapa pun yang memiliki sertifikat valid dari CA mana pun yang ada di trust store, termasuk CA yang diinstal attacker untuk keperluan intercept. Certificate pinning menutup celah ini dengan mengunci kepercayaan aplikasi hanya pada satu sertifikat atau public key tertentu, terlepas dari CA mana pun yang menandatanganinya.
Bagaimana Certificate Pinning Bekerja
Secara default, Android mempercayai semua Certificate Authority yang ada di system trust store, termasuk CA yang bisa diinstal sendiri oleh attacker untuk keperluan intercept. Certificate pinning mengubah model kepercayaan ini: aplikasi hanya mau berkomunikasi dengan server yang sertifikatnya, atau public key-nya, sudah di-hardcode atau dikonfigurasi di dalam aplikasi itu sendiri.[1]
Ada dua bentuk utama implementasinya.
Certificate Pinning mengharuskan aplikasi menyimpan salinan lengkap sertifikat server. Pendekatan ini lebih ketat, tetapi lebih rapuh saat sertifikat server diperbarui.
Public Key Pinning hanya menyimpan public key dari sertifikat. Pendekatan ini lebih fleksibel karena public key bisa tetap sama meski sertifikat diperbarui.
Di ekosistem Android, implementasi pinning bisa dilakukan melalui beberapa lapisan: network_security_config.xml,[2] OkHttp CertificatePinner,[3] TrustManager custom, atau library pihak ketiga seperti TrustKit.[4]
Menariknya, pendekatan pinning berbasis header HTTP yang sempat populer, yaitu HTTP Public Key Pinning atau HPKP, kini sudah dideprekasi dan dihapus dari browser modern karena risiko yang dikenal sebagai pinning suicide, yaitu skenario ketika kesalahan konfigurasi pin justru mengunci pengguna sah keluar dari situs mereka sendiri secara permanen.[13] Kegagalan HPKP ini menjadi pelajaran penting bahwa pinning yang diimplementasikan tanpa rencana rotasi yang matang berisiko lebih besar daripada tidak memiliki pinning sama sekali.
Perbedaan Implementasi: Android dan iOS
Meski artikel ini berfokus pada Android, perlu dicatat bahwa iOS memiliki pendekatan native yang berbeda melalui App Transport Security (ATS). Sejak iOS 14, Apple menyediakan mekanisme deklaratif bernama NSPinnedDomains di dalam Info.plist yang memungkinkan pinning tanpa menulis kode custom, di samping opsi pinning manual melalui challenge di URLSession.[14] Pendekatan deklaratif ini membuat implementasi pinning di iOS cenderung lebih konsisten dibanding Android, yang implementasinya tersebar di berbagai lapisan dan library sehingga lebih rentan terhadap kesalahan konfigurasi parsial.
Teknik Bypass: Pendekatan Umum
Sebelum memilih teknik bypass, langkah pertama adalah memahami bagaimana pinning diimplementasikan di aplikasi target. Static analysis pada APK menggunakan tools seperti jadx atau apktool biasanya sudah cukup untuk mengidentifikasi hal ini.
1. Memodifikasi network_security_config.xml
Ini adalah cara paling sederhana untuk aplikasi yang menggunakan Network Security Configuration bawaan Android. File XML ini mengontrol kebijakan trust aplikasi, termasuk apakah user-installed CA diizinkan.[2]
Prosesnya secara umum sebagai berikut.
- Decompile APK dengan apktool
- Modifikasi network_security_config.xml, tambahkan elemen trust-anchors untuk user CA
- Recompile dan re-sign APK
- Install ulang di device
Limitasinya, cara ini tidak efektif jika pinning diimplementasikan di level kode seperti OkHttp atau TrustManager, dan membutuhkan device yang bisa menginstal APK hasil modifikasi.
2. Frida Dynamic Instrumentation
Frida adalah tools dynamic instrumentation yang memungkinkan kita meng-hook fungsi di dalam aplikasi saat runtime, tanpa perlu memodifikasi APK.[5] Pendekatan ini paling fleksibel dan paling sering digunakan dalam engagement nyata.
Script Frida untuk bypass pinning bekerja dengan meng-hook method yang bertanggung jawab melakukan validasi sertifikat, seperti checkServerTrusted pada TrustManager atau verify pada HostnameVerifier, kemudian mengganti return value-nya agar selalu lolos validasi.
Library seperti frida-multiple-unpinning[6] atau script dari Frida CodeShare menyediakan cakupan untuk library pinning yang umum digunakan: OkHttp3, Conscrypt, TrustKit, dan Android default SSL. Pendekatan yang sama juga menjadi dasar teknik bypass yang didokumentasikan secara resmi dalam OWASP Mobile Application Security Testing Guide.[8]
3. Objection Framework
Objection adalah toolkit mobile security yang dibangun di atas Frida, menyediakan antarmuka command-line yang lebih mudah digunakan untuk bypass pinning tanpa perlu menulis script manual.[7]
Perintah dasarnya cukup sederhana, yaitu menjalankan objection dengan target gadget aplikasi lalu masuk ke mode explore, kemudian mengeksekusi perintah android sslpinning disable.
Cara ini cocok untuk quick assessment, meski untuk kasus pinning yang lebih custom, script Frida manual tetap lebih andal.
4. Magisk dan LSPosed (Berbasis Root)
Untuk device yang sudah di-root, module seperti AlwaysTrustUserCerts atau MagiskTrustUserCerts bisa mengangkat user-installed CA ke level system CA,[10] sehingga bypass pinning tidak lagi diperlukan karena CA milik kita sudah dipercaya di level sistem.
Pendekatan ini efektif, tetapi membutuhkan rooted device yang tidak selalu tersedia di setiap setup pengujian.
5. Xposed dan LSPosed sebagai Alternatif Frida
Di device yang sudah di-root, LSPosed menawarkan pendekatan hooking berbasis Zygisk atau Riru yang kompatibel secara API dengan Xposed Framework klasik, dan bisa menjadi alternatif Frida untuk skenario ketika Frida server terdeteksi atau diblokir oleh aplikasi target.[15] Modul Xposed untuk bypass pinning bekerja dengan prinsip yang sama seperti script Frida, yaitu meng-hook method validasi sertifikat, namun berjalan lebih persisten karena terintegrasi di level sistem operasi, bukan diinjeksikan per proses.
Inspeckage adalah salah satu tool berbasis modul Xposed yang berguna untuk dynamic analysis yang lebih luas, tidak terbatas pada pinning, mencakup inspeksi activity, hooking API, dan pemantauan perilaku runtime aplikasi secara umum.[16]
Kasus yang Lebih Sulit: Anti-Tampering dan Frida Detection
Tidak semua aplikasi mudah di-bypass. Aplikasi dengan security posture yang lebih matang, terutama di sektor perbankan dan fintech, sering mengimplementasikan lapisan pertahanan tambahan yang tercakup dalam kategori resilience testing pada OWASP MASVS.[9]
Root detection bekerja dengan mendeteksi apakah device sudah di-root dan menolak aplikasi untuk berjalan.
Frida detection secara aktif mendeteksi kehadiran Frida server atau proses injeksi, lalu membuat aplikasi crash atau menolak melanjutkan eksekusi.
Integrity checks memverifikasi integritas APK itu sendiri, sehingga modifikasi file bisa terdeteksi.
Studi Kasus: Ketika Pinning Absen atau Rusak
Dampak dari pinning yang lemah atau tidak ada bukan sekadar risiko teoretis. Pada 2025, CVE-2025-56146 mendokumentasikan kegagalan validasi sertifikat SSL/TLS pada aplikasi perbankan Android IndSMART, tempat WebView di dalam aplikasi tidak memvalidasi sertifikat server dengan benar, sehingga membuka celah intersepsi MitM terhadap traffic login, kode OTP, dan transaksi pembayaran UPI.[17] Kasus ini menggambarkan bahwa kelemahan pinning bukan hanya soal aplikasi native yang bisa di-bypass tester, melainkan juga soal implementasi WebView yang sering luput dari perhatian tim development.
Skala masalah ini juga terkonfirmasi secara akademis. Studi yang dipublikasikan pada ACM Internet Measurement Conference 2022 menemukan bahwa adopsi SSL pinning di aplikasi Android dan iOS yang diteliti hanya berkisar antara 0,9 persen sampai 8 persen dari total sampel. Bahkan di antara aplikasi yang mengklaim mengimplementasikan pinning, ditemukan cacat validasi hostname pada aplikasi perbankan besar sekalipun.[18] Temuan ini sejalan dengan pengalaman kami di lapangan, tempat pinning yang absen atau cacat konfigurasi jauh lebih sering ditemukan dibanding implementasi pinning yang benar-benar solid.
Implikasi bagi Tim Development
Dari perspektif tim security, menemukan bahwa certificate pinning berhasil di-bypass dalam waktu singkat adalah temuan yang perlu dikomunikasikan dengan jelas kepada tim development. Bukan berarti pinning tidak berguna, sebab pinning tetap meningkatkan barrier yang harus dihadapi attacker. Namun ada beberapa praktik yang membuat implementasi pinning menjadi lebih tahan uji.
Gunakan public key pinning, bukan certificate pinning. Certificate pinning akan gagal berfungsi setiap kali sertifikat server diperbarui. Public key pinning lebih tahan terhadap rotasi sertifikat selama key pair tidak berubah.[1]
Implementasikan di beberapa lapisan sekaligus. Jangan hanya mengandalkan network_security_config.xml. Kombinasikan dengan OkHttp CertificatePinner[3] dan validasi tambahan di level kode, sesuai persyaratan komunikasi jaringan pada OWASP MASVS-NETWORK.[19]
Tambahkan deteksi terhadap environment yang mencurigakan. Root detection, emulator detection, dan Frida detection bukan solusi tunggal yang sempurna, tetapi ketiganya meningkatkan upaya yang diperlukan attacker secara signifikan, sesuai rekomendasi pada kontrol resilience OWASP MASVS.[9] Untuk deteksi tampering yang lebih andal di level platform, Google merekomendasikan migrasi ke Play Integrity API, penerus resmi SafetyNet Attestation API yang telah dihentikan sepenuhnya sejak 31 Januari 2025.[20]
Rencanakan proses rotasi pin. Tentukan mekanisme pembaruan pin sebelum go-live, baik melalui update aplikasi maupun dynamic pinning melalui endpoint tertentu. Pertimbangkan pula Certificate Transparency sebagai kontrol pelengkap. Log publik yang bersifat append-only ini membuat penerbitan sertifikat yang tidak sah atau keliru menjadi bisa diaudit secara publik, sehingga menambah lapisan deteksi di luar pinning itu sendiri.[21]
Kesimpulan
Certificate pinning adalah kontrol keamanan yang valid dan penting untuk aplikasi mobile, terutama yang menangani data sensitif seperti aplikasi perbankan, fintech, atau kesehatan. Namun implementasi yang tidak tepat atau tidak berlapis justru memberikan rasa aman yang semu, sebab bypass bisa dilakukan dalam hitungan menit oleh tester yang berpengalaman, dan data akademis menunjukkan bahwa adopsi pinning yang benar masih jauh dari mayoritas aplikasi yang beredar.
Penetration testing pada lapisan ini bukan hanya soal membuktikan bahwa bypass bisa dilakukan, melainkan soal memahami seberapa jauh attacker bisa masuk setelah traffic berhasil diintersepsi, dan memberikan rekomendasi yang bisa langsung dieksekusi oleh tim development.
Jika Anda ingin mengetahui seberapa kuat implementasi certificate pinning aplikasi Anda, atau ingin melakukan penetration testing menyeluruh pada aplikasi mobile perusahaan Anda, tim Security Squad LOGIQUE siap membantu.
Daftar Referensi
- OWASP Foundation. “Certificate and Public Key Pinning.” OWASP Community Pages. https://owasp.org/www-community/controls/Certificate_and_Public_Key_Pinning
- Android Developers. “Network security configuration.” https://developer.android.com/privacy-and-security/security-config
- Square, Inc. “CertificatePinner.” OkHttp API Documentation. https://square.github.io/okhttp/3.x/okhttp/okhttp3/CertificatePinner.html
- Data Theorem. “TrustKit-Android.” GitHub repository. https://github.com/datatheorem/TrustKit-Android
- Frida Project. “Welcome.” Frida Documentation. https://frida.re/docs/home/
- akabe1. “frida-multiple-unpinning.” Frida CodeShare. https://codeshare.frida.re/@akabe1/frida-multiple-unpinning/
- SensePost. “objection.” GitHub repository. https://github.com/sensepost/objection
- OWASP Mobile Application Security Testing Guide (MASTG). “MASTG-TECH-0012: Bypassing Certificate Pinning.” https://mas.owasp.org/MASTG/techniques/android/MASTG-TECH-0012/
- OWASP Mobile Application Security Verification Standard (MASVS). “MASVS-RESILIENCE.” https://mas.owasp.org/MASVS/11-MASVS-RESILIENCE/
- NVISO Security. “AlwaysTrustUserCerts.” GitHub repository. https://github.com/NVISOsecurity/AlwaysTrustUserCerts
- Cloudflare Learning Center. “What Happens in a TLS Handshake?” https://www.cloudflare.com/learning/ssl/what-happens-in-a-tls-handshake/
- IETF. RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3. https://www.rfc-editor.org/rfc/rfc8446
- MDN Web Docs. “HPKP.” Glossary. https://developer.mozilla.org/en-US/docs/Glossary/HPKP
- Apple Developer Documentation. “Preventing Insecure Network Connections.” https://developer.apple.com/documentation/security/preventing-insecure-network-connections
- LSPosed Developer Team. “LSPosed.” GitHub repository. https://github.com/LSPosed/LSPosed
- ac-pm. “Inspeckage.” GitHub repository. https://github.com/ac-pm/Inspeckage
- National Vulnerability Database (NVD). CVE-2025-56146. https://nvd.nist.gov/vuln/detail/CVE-2025-56146
- ACM Internet Measurement Conference (IMC) 2022. “A Comparative Analysis of Certificate Pinning in Android and iOS.” https://dl.acm.org/doi/10.1145/3517745.3561439
- OWASP MASVS-NETWORK. “Network Communication Requirements.” https://mas.owasp.org/MASVS/08-MASVS-NETWORK/
- Android Developers. “Play Integrity API Overview.” https://developer.android.com/google/play/integrity/overview
- IETF. RFC 6962: Certificate Transparency. https://www.rfc-editor.org/rfc/rfc6962.html






