Keamanan aplikasi di era agentic

Halo, saya Kristen.

Halo, dan saya Sabs.

Kami di sini untuk membahas keamanan di era agen.

Pada tahun lalu, kami memberikan reward senilai lebih dari $2 juta untuk program Android Bug Hunters, dan lebih dari $200 ribu untuk perangkat seluler.

Di era agentic saat ini, keamanan aplikasi terus berkembang.

Jadi, mari kita bahas alat yang dapat membantu kita menyelesaikan masalah ini dengan cepat dan efektif.

Untuk meningkatkan performa agen dalam keamanan Android, jawabannya bukanlah perintah yang lebih baik.

Alat dan alur kerja ini membantu agen memahami toolchain dan API kami untuk membantu menjaga keamanan aplikasi Anda.

Jadi, sekarang pukul 16.30.

Pada hari Kamis.

Anda sedang memotong rilis, dan CI berubah menjadi merah, hanya ada satu error: Penerima siaran terdaftar tanpa flag ekspor.

Jadi, baik Anda berada di tim kecil, menangani semua tugas, atau di tim besar, tempat pemeriksaan keamanan dilakukan saat Anda merilis, kenyataannya sama.

Kami adalah engineer produk, yang mengirimkan fitur berkualitas tinggi dengan cepat, dan kami belum tentu peneliti keamanan.

Jadi, apa insting alaminya?

Jadi, kita berikan peringatan itu ke alat agentic, dan meminta agen untuk memperbaikinya.

Namun, alat agen, yang bekerja tanpa konteks project Anda, memiliki tiga titik buta.

Alat ini mungkin tidak mengetahui bahwa aplikasi Anda dibuat dari modul fitur dinamis atau paket multi-APK.

Sistem ini melihat file, bukan artefak yang dikirim.

Alat ini mungkin tidak mengetahui atau dapat melacak aliran data dari UI Kotlin ke logika bersama KMP ke dalam panggilan JNI C++ native.

Model hanya melihat satu lapisan.

Terakhir, alat ini mungkin tidak mengetahui SDK minimum atau ragam build Gradle Anda.

Jadi, kami mengarahkan agen ke aplikasi tersebut, dan meminta audit keamanan.

Ada enam temuan.

Dan inilah masalahnya.

Setiap jenis serangan.

Semuanya dapat dipertahankan, tetapi hanya satu yang merupakan bug yang sebenarnya kita mulai.

Sisanya adalah kombinasi dari praktik yang baik, hal-hal yang perlu diselidiki lebih lanjut, spekulasi, dan hal-hal yang mungkin tidak berlaku.

Jadi, sekarang Anda menskalakannya ke code base yang sebenarnya, dengan lebih banyak peringatan, dan di setiap permintaan pull, Anda akan tergoda untuk menggunakan suppress lint.

Anda akan mendapatkan kesempatan untuk menggabungkan perubahan tersebut, atau bahkan mungkin melewatkan kerentanan sama sekali.

Dan itulah cara kerentanan yang sebenarnya lolos.

Alat ini tidak ceroboh, melainkan berhati-hati, tetapi berhati-hati tidak sama dengan berguna.

Mari kita buat ini konkret.

Misalnya, Anda meminta agen, "Audit setiap komponen yang diekspor di aplikasi ini untuk pengalihan intent aplikasi".

Ini adalah tugas keamanan yang sesungguhnya, dan pada aplikasi multi-modul, tugas ini sangat besar.

Itulah jenis permintaan yang benar-benar menampilkan biaya.

Dan tanpa panduan khusus Android, agen tidak memiliki strategi untuk pertanyaan tersebut.

Jadi, ini adalah brute force.

Alat ini dapat membaca modul yang tidak mengekspor apa pun.

Model ini dapat memperoleh kembali dari prinsip pertama apa yang membuat pengalihan intent dapat dieksploitasi.

Mungkin mengikuti jalur yang tidak pernah dapat dijangkau.

Anda membayar untuk eksplorasi, bukan analisis.

Keterampilan adalah hal yang menyediakan strategi yang hilang.

Misalnya, keterampilan keamanan Android memberikan petunjuk kepada agen Anda yang mengikuti panduan saat ini, urutan langkah yang sama dengan yang akan diikuti oleh peneliti keamanan, dan agen berhenti menebak-nebak.

Asisten tidak akan menemukan kembali aturan tersebut karena aturan disediakan oleh skill.

Saat ini, kami telah meluncurkan dua keterampilan keamanan: Keamanan Intent dan Izin.

Keamanan intent adalah tentang apa yang dapat dilakukan aplikasi lain terhadap aplikasi Anda.

Aplikasi Anda memiliki izin, sesi login yang tidak dimiliki pengguna.

Jadi, setiap komponen yang diekspor dan setiap intent tertunda yang Anda berikan adalah cara potensial bagi seseorang untuk bertindak melalui Anda.

Keterampilan ini membantu melindungi dari hal ini.

Kemampuan izin membantu menutup kesenjangan antara izin yang dideklarasikan dan izin yang benar-benar diterapkan.

Hal ini dapat membantu Anda menulis pemeriksaan izin yang sesuai.

Hal ini membantu mengidentifikasi apakah penyedia dengan jalur karakter pengganti memberikan akses ke seluruh database, bukan hanya satu direktori.

Fitur ini juga mendeteksi permintaan izin yang berlebihan.

Misalnya, meminta akses luas padahal pemilih foto sudah cukup.

Gunakan dengan Android CLI, lalu tanyakan, "Audit untuk keamanan intent".

Tidak ada konfigurasi.

Tidak ada penyesuaian aturan.

Jadi, output-nya tidak akan berupa daftar panjang peringatan.

Ini adalah ulasan.

Berikut adalah bug, alasan bug tersebut penting untuk aplikasi Anda, dan perbaikannya.

Berikut tips pro-nya.

Gunakan Android CLI untuk memudahkan pencarian dan penginstalan.

android skills list
android skills add android-intent-security
android skills add android-permissions-security

Dan karena skill ini tahu persis apa yang harus dicari dalam project Anda, skill ini akan melihat aplikasi Anda sebagaimana aplikasi tersebut benar-benar dikirimkan.

Gemini mematuhi SDK minimum Anda sehingga perbaikan dapat dikompilasi, jalur file yang sebenarnya, nomor baris yang sebenarnya.

Berikut ulasan yang Anda dapatkan kembali.

Tindakan ini menunjukkan file dan baris yang tepat, menjelaskan ancaman sebenarnya dan penjelasan untuk perubahan tersebut, bukan hanya karena Lint mengatakannya.

Gemini akan mengutip keahlian yang digunakan.

Alat ini membaca konfigurasi build, melihat SDK minimum 26, dan memilih ContextCompat sehingga perbaikan berfungsi, dan memberi Anda diff sehingga Anda dapat menerapkannya.

Itu adalah peringatan yang kita buka, tetapi sekarang dengan perbaikan yang disarankan dan alasan tambahan.

Jadi, keterampilan sebelumnya mendeteksi bug keamanan.

Sekarang mari kita bahas area lain, yaitu kepatuhan terhadap kebijakan aplikasi.

Misalnya, bayangkan Anda adalah developer aplikasi baru yang ingin meluncurkan aplikasi di Google Play Store.

Mengisi formulir keamanan data adalah langkah penting dalam meluncurkan aplikasi, jadi mari kita gunakan setiap alat yang kita bisa untuk membantu memastikan kita melakukannya dengan benar sebelum mengirimkan aplikasi.

Keterampilan kebijakan Google Play melakukan analisis statis pada code base Anda.

Jika Anda memublikasikan aplikasi Google Play Store yang sudah ada, aplikasi tersebut juga dapat mereferensikan silang analisis kode statis tersebut dengan pernyataan Google Play Store.

Menjalankan keahlian ini dapat membantu Anda mendeteksi potensi masalah kebijakan Google Play sebelum, bukan setelah, pengiriman aplikasi, dan membantu mempercepat proses pengiriman Anda.

Alur kerjanya mirip dengan keterampilan lain yang telah kita bahas: impor, lalu tanyakan, "Audit aplikasi ini untuk kepatuhan terhadap kebijakan Google Play sebelum saya mengirimkannya."

Anda akan melihat screenshot contoh laporan di sebelah kanan, dan perintah Android CLI untuk menginstalnya di bawah.

android skills list
android skills add play-policy-insights

Jadi, semua yang telah kita bahas sejauh ini terjadi sebelum Anda mengirim: mengaudit intent, memeriksa izin, memvalidasi kepatuhan.

Itulah keamanan waktu build, dan ini sangat penting.

Namun, ada seluruh kelas ancaman yang hanya ada setelah APK Anda dirilis, yang berjalan di perangkat yang mungkin tidak Anda kontrol.

Play Integrity API menjawab tiga pertanyaan saat runtime yang tidak dapat dijawab oleh kode Anda sendiri: Apakah ini build aplikasi Anda yang asli dan tidak dimodifikasi?

Apakah aplikasi ini berjalan di perangkat Android yang asli?

Apakah ini akun pengguna Play?

Jadi, Anda dapat menggunakan Play Integrity API untuk menampilkan verdict tentang integritas aplikasi, integritas perangkat, dan lainnya.

Selain membuat publikasi aplikasi Anda lebih cepat, mudah, dan aman, kami juga mempermudah pengamanan pendapatan dan reputasi aplikasi Anda.

Jadi, lindungi bisnis Anda dari penipuan dan penyalahgunaan.

Dasbor Dilindungi dengan Google Play yang baru, yang dapat Anda lihat di sini, membantu Anda memantau dan mengonfigurasi pertahanan integritas, distribusi, dan monetisasi di satu tempat.

Kami juga mengurangi latensi pemanasan untuk Play Integrity API agar Anda dapat menggunakan pemeriksaan ini selama perjalanan pengguna yang memerlukan kecepatan tinggi untuk memblokir ancaman dan perangkat berisiko dengan lebih cepat.

Jadi, kita baru saja membahas fitur dan alat Android untuk membantu menjaga keamanan aplikasi, tetapi bagaimana dengan pengguna Anda?

Pertama-tama, mari kita lihat Perlindungan OTP SMS.

Misalnya, Anda ingin menerapkan verifikasi pengguna berbasis SMS untuk aplikasi Anda dan mengirim kode verifikasi.

Izin SMS memberikan akses aplikasi ke data pesan, termasuk data sensitif seperti OTP.

Jadi, kami telah memperkenalkan beberapa API di aplikasi Anda agar Anda dapat menerapkannya, sehingga Anda tidak perlu meminta izin SMS yang luas, tetapi masih dapat mengambil kode OTP SMS untuk verifikasi.

SMS Retriever API memungkinkan aplikasi Anda memverifikasi OTP secara otomatis tanpa izin SMS yang luas.

Anda menambahkan hash 11 karakter yang mengidentifikasi aplikasi Anda ke pesan, dan sistem hanya akan memberikan satu pesan tersebut kepada Anda.

Jika Anda tidak dapat mengontrol format pesan, gunakan SMS User Consent API.

Sistem akan menampilkan satu perintah satu kali.

Pengguna mengetuk izinkan atau tolak, dan jika mereka mengizinkan, Anda akan mendapatkan satu pesan tersebut.

Tetap tidak perlu izin SMS yang luas.

Beberapa aplikasi mungkin hanya memerlukan lokasi presisi satu kali untuk menyelesaikan tugas.

Izin satu kali yang ada memiliki friksi pengguna yang tinggi, sehingga terkadang developer akan meminta izin akurat yang lebih luas.

Jadi, Tombol Lokasi adalah alat yang memberikan cara mudah untuk memberikan akses lokasi presisi satu kali kepada aplikasi.

Ini adalah elemen UI Android yang dapat disesuaikan dan disematkan oleh developer aplikasi.

Kami meluncurkan versi pertama library Jetpack Tombol Lokasi alfa pada bulan Juni.

Di sini, Anda dapat melihat izin yang diperlukan untuk mengaktifkan Tombol Lokasi di manifes Android Anda.

<uses-permission android:name="android.permission.ACCESS_FINE_LOCATION"
    android:usesPermissionFlags="onlyForLocationButton"/>

<uses-permission android:name="android.permission.USE_LOCATION_BUTTON" />

    <application
        android:icon="@mipmap/ic_launcher"
        android:label="LocationButtonSample"
        android:theme="@style/Theme.PinPoint">
        <activity
            android:name=".MainActivity"
            android:exported="true">
            <intent-filter>
                <action android:name="android.intent.action.MAIN" />
                <category android:name="android.intent.category.LAUNCHER" />
            </intent-filter>
        </activity>
    </application>

Anda harus mendeklarasikan izin akses lokasi standar dengan menambahkan flag izin onlyForLocationButton, bersama dengan izin USE_LOCATION_BUTTON khusus yang diperlukan oleh layanan rendering jarak jauh sistem.

Di sebelah kanan, ada kode Jetpack untuk menerapkannya.

...
import androidx.core.locationbutton.compose.LocationButton

@Composable
fun LocationPermissionScreen(onPermissionGranted: () -> Unit, onPermissionDenied: () -> Unit) {
    // Renders the secure system-trusted Location Button composable
    LocationButton(
        // Callback triggered when the user taps the secure button and makes a decision on the permission dialog
        onPermissionResult = { isGranted ->
            if (isGranted) {
                onPermissionGranted()
            } else {
                onPermissionDenied()
            }
        },
...

Anda dapat melihat di sini bahwa kita membuat Tombol Lokasi dan melakukan inisialisasi callback.

Callback ini dipicu saat pengguna mengetuk Tombol Lokasi untuk membuat keputusan apakah izin diberikan atau ditolak.

Mode Perlindungan Lanjutan adalah fitur yang ditujukan untuk pengguna yang berisiko atau yang peduli dengan keamanan, tetapi siapa pun dapat memilih untuk menggunakannya.

Misalnya, jika Anda adalah aplikasi perbankan, Anda tidak akan menerapkan autentikasi multifaktor tambahan pada setiap transfer karena pengguna biasa tidak menyukai hambatan tambahan tersebut.

Namun, saat Mode Perlindungan Lanjutan aktif, aplikasi Anda tahu bahwa pengguna ini menginginkan perlindungan maksimal, sehingga Anda dapat otomatis mewajibkan autentikasi biometrik pada setiap transfer.

Mode Perlindungan Lanjutan menerapkan serangkaian konfigurasi standar yang dirancang untuk memperkuat perlindungan perangkat.

Di sini, kami akan menunjukkan cara mengintegrasikan ke dalam aplikasi Anda.

Anda perlu meminta izin, mengkueri Mode Perlindungan Lanjutan, dan memeriksa apakah pengguna telah mengaktifkan Mode Perlindungan Lanjutan menggunakan layanan sistem Advanced Protection Mode Manager yang dipanggil di perangkat.

class AdvancedProtectionManager() {
  // Check the current status
  fun isAdvancedProtectionEnabled(): Boolean

  // Be alerted when status changes
  fun registerAdvancedProtectionCallback(executor: Executor,
                                         callback: Callback)

  fun unregisterAdvancedProtectionCallback(callback: Callback)
}

interface Callback() {
  // Called when advanced protection state changes
  fun onAdvancedProtectionChanged(enabled: Boolean)
}

Kemudian, Anda dapat memproses perubahan runtime dengan mendaftarkan callback.

Kita telah membahas banyak topik hari ini.

Berikut adalah link cepat jika Anda ingin mempelajari lebih lanjut.

Kami akan berhenti sejenak di sini agar Anda dapat mencatat URL yang diperlukan.

Terima kasih.

Terima kasih.