Cross-Platform API Reuse in Mobile Apps: Hidden Attack Surface in Shared Backends

Avatar photo

Pendahuluan

Dalam ekosistem mobile modern, arsitektur lintas platform seperti Flutter, React Native, dan backend API shared semakin lazim digunakan. Keuntungan efficiency, code reuse, dan unified backend sering dijadikan alasan utama.

Namun, di balik kemudahan ini, terselip celah desain yang jarang disorot: tidak adanya pemisahan (segregation) antara request dari platform Android dan iOS di sisi backend.

Studi kasus dalam artikel ini menunjukkan bagaimana sebuah aplikasi iOS yang tampak solid tetap membawa risk surface identik dengan versi Android-nya, hanya karena backend API tidak menerapkan platform validation. Ini adalah potret nyata dari A04:2021 – Insecure Design, dan seringkali tidak terdeteksi hanya melalui dynamic testing permukaan.


Studi Kasus: iOS App dengan Shared Android API

Latar Belakang

Kami melakukan analisis statis terhadap sebuah aplikasi iOS (.ipa) berbasis Flutter. Seluruh request yang dilakukan oleh aplikasi mengarah ke dua domain publik—yang diketahui sebelumnya juga digunakan oleh versi Android.

Tujuan dari reverse engineering ini adalah untuk menjawab pertanyaan berikut:

Apakah backend API cukup cerdas untuk membedakan antara pengguna Android dan iOS?

Spoiler: Tidak.


Reverse Engineering .IPA dan .APK

File .ipa aplikasi dianalisis menggunakan pendekatan statis dengan toolset standar:

unzip app.ipa -d extracted/
cd extracted/Payload/AppName.app/
strings App.framework/App | grep -Ei 'http://|https://'

Ditemukan bahwa domain API endpoint hardcoded di dalam binary Flutter adalah sama persis dengan yang digunakan versi Android:

strings app_dec/lib/arm64-v8a/libapp.so | grep -Ei 'http://|https://'

Struktur payload dan format request juga identik, tanpa ada fragment Platform.isIOS atau kondisional platform-aware dalam bytecode Dart yang direkonstruksi.

Salah satu request yang dikirim oleh aplikasi Android ke backend:

POST /mobile/gal2/user HTTP/2
Host: <redacted>
User-Agent: Dart/3.8 (dart:io)
Authorization: Bearer <token>
Content-Type: application/json

Payload:

{
"email": "example@gmail.com",
"first_name": "pentestingididdaaaaa",
"phone": "88XXXXXXXXXXX",
...
}

Catatan: Tidak ada User-Agent yang mencerminkan asal platform (seperti Android WebView, build ID, atau package signature). Header tambahan seperti X-Platform, X-App-Version, atau X-Signature juga tidak ditemukan.


Implikasi Keamanan: Cross-Platform Attack Inheritance

Reuse = Inheritance (Kerentanan)

Karena backend tidak memfilter request berdasarkan asal platform, maka:

  • Kerentanan yang ditemukan di Android langsung dapat dicoba via iOS

  • Token reuse antar platform dimungkinkan (jika tidak ada scoping platform di payload atau header)

  • Rate limiting & abuse protection dapat dilewati jika diimplementasikan secara global

Contoh eksploitasi:

  1. Attacker menggunakan emulator Android untuk mendapatkan access token.

  2. Token digunakan dalam HTTP request dari Postman/cURL ke endpoint yang ditargetkan.

  3. Server menerima permintaan tanpa membedakan apakah token tersebut berasal dari aplikasi resmi Android atau tidak—apalagi iOS.


Friksi antara Reusability dan Trust Boundary

Penggunaan backend API shared memang efisien, namun berisiko jika:

  • Token tidak dibatasi berdasarkan platform asal

  • Tidak ada validasi User-Agent, X-Platform, atau signed metadata

  • Tidak ada pembedaan antara iOS/Android dalam rate limit bucket

Sebaliknya, sistem yang secure-by-design seharusnya:

AspekImplementasi Aman
Platform IdentificationHeader X-Platform: iOS + validation
Scoped TokenToken hanya valid untuk platform asal
Platform-Specific Abuse ControlRate limit bucket per-platform
Signed Request PayloadHMAC(payload + timestamp + platform)

Rekomendasi Implementatif

Berikut praktik baik yang bisa diadopsi developer dan architect API mobile:

  1. Platform Scoping in Token Payload

    {
    "sub": "user123",
    "platform": "ios",
    "iat": 1723030021
    }
  2. Signed Requests

    • Gunakan secret per platform (ios_secret, android_secret)

    • Tandatangani permintaan dengan metode seperti:

      X-Signature: HMAC_SHA256(body + timestamp, ios_secret)
  3. Validate Device Context

    • Kombinasikan data dari fingerprinting atau secure enclave jika memungkinkan.

  4. Log & Audit Platform Source

    • Catat semua permintaan berdasarkan platform → audit abuse pattern lintas platform.


Catatan Penutup

Praktik code reuse di sisi frontend dan backend memang mempercepat siklus pengembangan. Tapi dalam security, reusability tidak boleh berarti turunnya trust boundary.

Tanpa isolasi platform di backend API, seluruh kerentanan pada satu platform akan diwariskan begitu saja ke platform lainnya. Dalam era di mana banyak aplikasi hanya satu klik dari reverse engineering, tidak ada alasan lagi untuk mengabaikan platform segregation sebagai bagian penting dari secure mobile architecture.


Referensi


Artikel ini adalah bagian dari seri “Mobile Attack Surfaces” oleh Tegalsec. Semua domain dan nama aplikasi telah disamarkan untuk menjaga kerahasiaan hasil uji penetrasi internal.


Total
0
Shares
Leave a Reply

Your email address will not be published. Required fields are marked *

Previous Post

Persistent Threats from Persistent Secrets

Next Post

Glitch in the UI: Exploiting Hidden Frontend Elements for Unauthorized Access

Related Posts