Bayangkan sebuah bank memberi cashback Rp50.000 untuk setiap nasabah baru yang daftar lewat aplikasi. Dalam satu akhir pekan, ribuan akun baru masuk dan semuanya mengklaim cashback. Di log server tidak ada yang aneh: endpoint-nya benar, API key-nya benar, format datanya juga benar. Padahal sebagian besar request itu tidak pernah dikirim dari aplikasi.

Caranya cukup sederhana. Penyerang memasang aplikasi di ponselnya sendiri, lalu melihat request apa saja yang dikirim ke server beserta isinya. API key, client ID, dan header lainnya ada di dalam aplikasi, jadi semuanya bisa disalin. Setelah itu, penyerang tinggal membuat skrip yang mengirim request yang sama ribuan kali, tanpa perlu membuka aplikasinya.

Cara yang sama juga dipakai untuk mencoba password hasil kebocoran data (credential stuffing), mengklaim voucher berulang-ulang, dan memicu pengiriman SMS OTP dalam jumlah besar yang biayanya ditanggung bank. OWASP memasukkan pola ini ke dalam daftar risiko keamanan API. Salah satu contohnya adalah skrip yang mendaftarkan akun secara otomatis untuk mengumpulkan bonus referral.1

Kenapa kontrol yang biasa dipakai belum cukup

API key yang ditanam di aplikasi hanya menunjukkan bahwa pengirimnya punya aplikasi tersebut, dan siapa pun bisa mengunduhnya. Header dan user-agent juga bisa disalin. Informasi yang dikirim aplikasi tentang dirinya sendiri, misalnya "perangkat tidak di-root", bisa dikirim skrip dengan isi yang sama persis. Certificate pinning memang menyulitkan orang mengintip lalu lintas data, tapi tidak banyak menghalangi orang yang menguasai ponselnya sendiri. Pembatasan per IP pun bisa diakali dengan berganti jaringan.

Kontrol-kontrol ini tetap ada gunanya, karena membuat penyerang harus bekerja lebih keras. Tapi tidak satu pun yang bisa memastikan bahwa request itu benar-benar datang dari aplikasi asli Anda.

Apa yang harus dibuktikan setiap request

Server butuh bukti yang bisa dicek sendiri. Google (lewat Play Integrity dan key attestation) dan Apple (lewat App Attest) sudah menyediakan caranya: ponsel membuat bukti yang ditandatangani hardware keamanannya, lalu server mengecek apakah bukti itu memang berasal dari aplikasi asli Anda di perangkat asli.23 Emulator tidak akan lolos, karena tidak punya hardware tersebut.

Selain itu, ada dua hal yang tidak kalah penting. Pertama, pengecekannya harus dilakukan di server. Dokumentasi Apple menjelaskan alasannya: aplikasi tidak bisa diandalkan untuk mengecek keamanannya sendiri, karena aplikasi yang sudah dimodifikasi bisa memalsukan hasilnya.3 Kedua, bukti itu harus dibuat untuk menjawab tantangan unik dari server dan hanya bisa dipakai sekali. Dengan begitu, request yang sudah direkam penyerang tidak bisa dikirim ulang.

Batasnya: phone farm

Cara ini bisa menghentikan skrip, request rekaman, dan emulator. Penyerang yang lebih serius biasanya pindah ke phone farm, yaitu puluhan sampai ratusan ponsel murah sungguhan yang menjalankan aplikasi asli secara otomatis. Di titik ini, pengecekan keaslian akan lolos, karena ponsel dan aplikasinya memang asli.

Yang masih bisa terlihat adalah cara ponsel-ponsel itu dipakai. Satu ponsel dipakai untuk mendaftarkan banyak akun. Satu perangkat bergonta-ganti akun. Ketukan layarnya terlalu rapi untuk dilakukan manusia. Banyak perangkat menjalankan langkah yang sama di waktu yang sama. Semua ini tidak tercatat di log transaksi, jadi harus dikumpulkan langsung dari perangkat.

Pertanyaan untuk tim Anda

  1. Kalau seseorang menyalin semua key dan header dari aplikasi Anda, bisakah ia mendaftarkan akun tanpa membuka aplikasinya?
  2. Apakah server Anda mengecek attestation sendiri, atau hanya menerima hasil pengecekan dari aplikasi?
  3. Apakah request yang direkam kemarin masih bisa dipakai hari ini?
  4. Apakah Anda akan tahu kalau ada sepuluh akun yang didaftarkan dari satu ponsel dalam satu sore?

Peran MoSecure. MoNetra mengecek di server bahwa sesi berasal dari aplikasi asli di perangkat asli, lalu memberi backend bank token yang berlaku singkat dan hanya bisa dipakai sekali untuk setiap aksi penting. MoNetra juga bisa mendeteksi pola lintas akun, misalnya beberapa pendaftaran dari satu ponsel. MoTogu memperkuat aplikasi agar lebih sulit dipelajari, dan bisa menandatangani request dengan key yang disimpan di hardware keamanan ponsel. Tidak ada yang bisa menghentikan semua serangan otomatis, tetapi kombinasi keduanya membuat aplikasi Anda jauh lebih sulit ditiru tanpa ketahuan.

Sumber

  1. OWASP API Security Top 10 (2023): API6, akses tanpa batas ke alur bisnis yang sensitif
  2. Android Developers: gambaran umum Play Integrity API
  3. Apple Developer: memastikan integritas aplikasi Anda (App Attest)

Angka sesuai laporan sumber di atas pada saat tulisan ini dibuat. Menemukan kesalahan? Kirim email ke contact@mosecure.id dan kami akan memperbaikinya.