Pendahuluan
Industri fintech Indonesia adalah salah satu yang paling berkembang di Asia Tenggara. Dari dompet digital hingga platform pinjaman peer-to-peer, dari aplikasi investasi hingga payment gateway, ekosistem ini menangani transaksi bernilai triliunan rupiah setiap harinya.
Tapi pertumbuhan yang cepat sering berbanding terbalik dengan kematangan security. Dalam beberapa engagement penetration testing pada aplikasi fintech Indonesia yang kami lakukan, pola yang muncul konsisten: fitur diluncurkan cepat untuk mengejar kompetitor, dan security menjadi pertimbangan yang datang belakangan, jika datang sama sekali.
Artikel ini membahas kerentanan yang paling sering kami temukan di aplikasi fintech Indonesia, dengan konteks spesifik tentang mengapa kerentanan tersebut berbahaya dalam konteks keuangan.
Konteks Regulasi: OJK dan POJK 11/2022
Otoritas Jasa Keuangan (OJK) melalui POJK Nomor 11 Tahun 2022 tentang Penyelenggaraan Teknologi Informasi oleh Bank Umum mewajibkan pelaku industri keuangan untuk menerapkan pengamanan yang komprehensif terhadap sistem teknologi informasi mereka, termasuk pengujian keamanan secara berkala.
Bagi perusahaan fintech yang terdaftar di OJK, ketidakpatuhan terhadap ketentuan ini bukan hanya risiko security, tapi juga risiko regulasi yang bisa berdampak pada izin operasional.
Temuan dari penetration testing bukan hanya laporan teknis, tapi juga dokumentasi yang dibutuhkan untuk demonstrasi compliance kepada regulator.
Kerentanan yang Paling Sering Ditemukan
1. Implementasi OTP yang Lemah
One-Time Password (OTP) adalah mekanisme autentikasi yang hampir universal di aplikasi fintech Indonesia. Tapi implementasinya sering memiliki celah yang signifikan.
Beberapa kelemahan yang paling sering kami temukan: OTP dengan panjang hanya 4 digit yang bisa di-brute force dalam hitungan menit jika tidak ada rate limiting, OTP yang masa berlakunya terlalu panjang (30 menit atau lebih) yang memberikan window yang cukup lebar untuk eksploitasi, validasi OTP yang dilakukan di sisi client sehingga bisa dimanipulasi, dan OTP yang sama bisa digunakan lebih dari sekali karena tidak di-invalidasi setelah penggunaan pertama.
Studi Kasus: Bypass Verifikasi OTP
Dalam salah satu pengujian, penulis menemukan bahwa proses verifikasi OTP pada aplikasi yang diuji bergantung sepenuhnya pada respons yang dikirim oleh server, tanpa validasi tambahan apa pun di sisi client. Aplikasi membaca parameter response code dan response status dari server sebagai satu-satunya penentu apakah verifikasi berhasil, dan kedua parameter tersebut dapat diintersep serta diubah melalui HTTP proxy sebelum sampai ke aplikasi.
Dengan mengubah nilai response status menjadi status yang menandakan verifikasi berhasil, meskipun OTP yang dimasukkan sebenarnya salah, proses autentikasi dapat dilewati sepenuhnya. OTP yang benar tidak diperlukan sama sekali; penulis cukup memanipulasi respons yang diterima aplikasi untuk membuatnya percaya bahwa verifikasi telah lolos.
Dampak dari kerentanan ini tergolong kritis. Selama nomor akun target diketahui, penyerang dapat login ke akun tersebut tanpa perlu mengetahui kredensial maupun kode OTP yang valid, setara dengan pengambilalihan akun penuh melalui satu titik lemah pada logika verifikasi di sisi client.
2. Logika Bisnis yang Bisa Dimanipulasi
Ini adalah kategori kerentanan yang paling unik untuk fintech dan paling sulit dideteksi oleh tools otomatis. Logika bisnis yang seharusnya mencegah fraud sering bisa dimanipulasi melalui manipulasi parameter yang dikirimkan dalam request.
Contoh yang paling sering ditemukan: nilai transaksi yang bisa diubah negatif untuk menghasilkan penambahan saldo, promo atau voucher yang bisa digunakan berkali-kali melebihi batas yang seharusnya, limit transfer yang diterapkan di sisi client tapi tidak di sisi server, dan urutan langkah transaksi yang bisa di-skip sehingga melewati validasi yang seharusnya.
Studi Kasus: Manipulasi Logika Transaksi
Dua pola kerentanan logika bisnis paling signifikan yang diidentifikasi penulis selama pengujian melibatkan manipulasi harga dan race condition pada proses pembelian.
Pada kasus pertama, nilai nominal barang yang dibeli dikirim sebagai parameter dalam request, dan nilai tersebut tidak divalidasi ulang oleh server terhadap harga sebenarnya di katalog. Dengan mencegat request menggunakan HTTP proxy, penulis dapat mengubah nominal barang menjadi nilai yang jauh lebih rendah dari harga aslinya sebelum request diteruskan ke server, sehingga transaksi diproses berdasarkan harga yang sudah dimanipulasi.
Pada kasus kedua, beberapa request pembelian dikirim secara bersamaan melalui thread paralel. Server memproses validasi saldo untuk tiap request secara terpisah tanpa mekanisme locking yang memadai, sehingga beberapa transaksi dapat disetujui sebelum saldo pengguna sempat diperbarui. Akibatnya, saldo pengguna berkurang hingga mencapai nilai negatif.
Potensi kerugian finansial dari kedua kerentanan ini tergolong signifikan. Keduanya memungkinkan pengguna memperoleh barang atau layanan tanpa membayar nilai yang semestinya, dan eksploitasi dapat diulang berkali-kali selama celah pada logika bisnis belum ditutup.
3. Keamanan Penyimpanan Data Finansial
Data yang disimpan di perangkat oleh aplikasi fintech lebih sensitif dari rata-rata aplikasi. Nomor rekening, riwayat transaksi, informasi KYC, dan saldo adalah data yang memiliki nilai langsung bagi attacker.
Dalam pengujian, kami sering menemukan data ini tersimpan dalam format yang tidak terenkripsi atau dengan enkripsi yang lemah di SharedPreferences, SQLite database tanpa enkripsi, atau cache yang bisa diakses tanpa autentikasi.
4. Endpoint Transfer dan Pembayaran yang Tidak Aman
Endpoint yang menangani transaksi finansial seharusnya memiliki lapisan keamanan yang lebih ketat dibanding endpoint biasa: validasi yang lebih ketat, logging yang lebih komprehensif, dan rate limiting yang lebih agresif.
Dalam praktiknya, kami sering menemukan endpoint transaksi yang memiliki kelemahan IDOR yang memungkinkan melihat atau memanipulasi transaksi milik pengguna lain, tidak ada validasi idempotency yang memungkinkan pengiriman request yang sama berkali-kali, dan parameter yang mengontrol jumlah transaksi yang bisa dimanipulasi di sisi client.
Dari keempat kategori kerentanan yang dibahas di atas, IDOR (Insecure Direct Object Reference) atau BOLA (Broken Object Level Authorization) merupakan yang paling sering ditemukan penulis dalam pengujian aplikasi fintech Indonesia. Pola ini konsisten muncul pada endpoint yang menangani data transaksi maupun profil pengguna, di mana identifier objek seperti ID transaksi atau ID akun dapat diubah untuk mengakses atau memanipulasi data milik pengguna lain tanpa otorisasi yang memadai.
Perbedaan Risiko Antara Fintech dan Aplikasi Biasa
Yang membuat kerentanan di aplikasi fintech berbeda dari aplikasi lain adalah konsekuensi langsungnya. Kerentanan di aplikasi media sosial mungkin mengekspos data personal. Kerentanan di aplikasi fintech bisa langsung mengakibatkan kerugian finansial yang konkret.
Ini berarti standar pengujian untuk aplikasi fintech seharusnya lebih tinggi, frekuensi pengujian seharusnya lebih sering, dan cakupan pengujian seharusnya mencakup logika bisnis secara mendalam, tidak hanya kerentanan teknis standar.
Rekomendasi untuk Tim Development Fintech
Berdasarkan pola temuan yang konsisten dalam engagement kami, beberapa rekomendasi yang paling berdampak:
Terapkan server-side validation untuk semua parameter yang berkaitan dengan nilai transaksi. Tidak ada parameter finansial yang boleh di-trust dari client tanpa validasi ulang di server.
Implementasikan idempotency key untuk semua operasi transaksi. Setiap request transaksi harus memiliki identifier unik yang mencegah pemrosesan yang sama dua kali meski request dikirim berkali-kali.
Audit logika bisnis secara khusus sebagai bagian dari setiap pengujian keamanan. Kerentanan logika bisnis tidak bisa ditemukan oleh scanner otomatis; memerlukan tester yang memahami konteks bisnis aplikasi.
Lakukan penetration testing sebelum setiap rilis fitur baru yang berkaitan dengan alur transaksi. Perubahan di satu bagian alur transaksi bisa memperkenalkan kerentanan di bagian lain yang tidak dimodifikasi.
Kesimpulan
Aplikasi fintech adalah target yang sangat menarik bagi attacker karena nilai finansial yang langsung bisa diekstrak dari kerentanan yang berhasil dieksploitasi. Pola kerentanan yang kami temukan menunjukkan bahwa tekanan untuk rilis cepat sering mengalahkan pertimbangan security, dengan konsekuensi yang bisa sangat signifikan.
Pengujian keamanan yang komprehensif dan teratur bukan hanya tentang compliance regulasi, tapi tentang melindungi pengguna dan bisnis dari ancaman yang nyata.
Jika Anda ingin memastikan keamanan aplikasi fintech Anda sebelum kerentanan ditemukan oleh pihak yang salah, tim Security Squad LOGIQUE siap membantu.
