Phishing Lewat Izin Aplikasi OAuth yang Sering Lolos

Phishing lewat izin aplikasi OAuth, yang juga disebut consent phishing, adalah serangan yang tidak meminta password korban. Penyerang membuat aplikasi yang tampak sah, lalu membujuk korban menekan Izinkan (Accept atau Allow) di layar persetujuan milik Microsoft atau Google. Setelah izin diberikan, aplikasi itu bisa membaca email, file, atau kontak korban lewat jalur resmi.

Taruhannya besar karena serangan ini melewati dua pertahanan yang paling sering diandalkan perusahaan: pelatihan "cek alamat halaman login" dan MFA. Halaman loginnya memang asli, dan korban memang login sendiri dengan MFA. Yang palsu hanya aplikasinya.

Kenapa phishing OAuth sering lolos?

Semua yang terlihat korban adalah halaman resmi

Pada phishing klasik, korban diarahkan ke halaman login tiruan. Pelatihan keamanan mengajarkan karyawan untuk curiga pada alamat yang aneh. Pada consent phishing, tautan di email justru membawa korban ke alamat login Microsoft atau Google yang asli. Gembok HTTPS ada, domain benar, logo benar.

Dokumentasi Microsoft menjelaskan situasinya dengan lugas: karena aplikasi ditampilkan lewat penyedia yang sah, pengguna yang tidak curiga menerima permintaannya. Penyerang cukup memberi nama aplikasi yang meyakinkan, misalnya mirip alat tanda tangan dokumen, penampil PDF, atau "pemeriksa keamanan akun".

MFA tidak relevan

MFA melindungi proses login. Di serangan ini, login dilakukan korban sendiri dan berhasil dengan sah. Yang diberikan korban setelahnya adalah token akses untuk aplikasi penyerang. Aplikasi memakai token itu langsung ke API layanan, tanpa perlu password dan tanpa memicu MFA lagi.

Mengganti password belum tentu memutus akses

Izin yang sudah diberikan ke aplikasi tercatat sebagai persetujuan tersendiri. Pada banyak layanan, mengganti password tidak otomatis mencabut persetujuan itu. Langkah yang pasti adalah mencabut izin aplikasinya secara eksplisit dan membatalkan tokennya.

Jarang ada yang mengaudit daftar aplikasi

Admin rutin melihat daftar pengguna, tapi jarang membuka daftar aplikasi pihak ketiga yang sudah diberi izin oleh karyawan. Akibatnya, aplikasi berbahaya bisa duduk diam berbulan-bulan, membaca kotak masuk.

Perbandingan dengan phishing password biasa

Ciri phishing biasa dan cara mengenalinya dibahas di cara mengenali phishing. Consent phishing butuh kewaspadaan tambahan karena ciri-ciri lama itu tidak muncul.

Tanda layar persetujuan yang patut dicurigai

Ajarkan karyawan membaca layar persetujuan sebelum menekan tombol apa pun. Beberapa tanda bahaya:

• Aplikasi meminta izin jauh lebih luas dari fungsinya, misalnya "penampil PDF" yang ingin membaca dan mengirim email atas namamu, atau akses ke semua file.
• Ada izin untuk tetap mengakses data walau kamu tidak sedang memakainya (akses offline).
• Nama penerbit tidak terverifikasi, atau namanya meniru merek terkenal.
• Permintaan datang dari email yang mendesak, misalnya "dokumen kontrak menunggu tanda tanganmu dalam 1 jam".
• Ejaan atau tata bahasa yang janggal di email maupun di layar persetujuan.

Microsoft juga mengingatkan agar tidak menjadikan nama aplikasi dan domain sebagai bukti keaslian, karena keduanya mudah ditiru.

Kapan cukup edukasi, kapan perlu membatasi dari sisi admin?

Edukasi saja cukup untuk akun pribadi. Untuk akun kantor, mengandalkan setiap karyawan membaca layar persetujuan dengan teliti setiap kali adalah taruhan yang buruk. Pembatasan dari sisi admin mengubah risiko itu menjadi kebijakan.

Di Microsoft Entra ID (Microsoft 365), atur pengaturan user consent agar pengguna hanya boleh memberi izin ke aplikasi dari penerbit terverifikasi dan hanya untuk izin berisiko rendah yang kamu pilih. Aktifkan juga alur admin consent, supaya permintaan di luar itu masuk ke admin untuk ditinjau, bukan langsung ditolak tanpa jalan keluar.

Di Google Workspace, buka Admin console, lalu Security, Access and data control, API controls. Di sana kamu bisa menandai aplikasi sebagai tepercaya, membatasi aksesnya, memberi akses ke data tertentu saja, atau memblokirnya. Atur juga perlakuan untuk aplikasi yang belum dikonfigurasi, misalnya hanya mengizinkan aplikasi yang meminta info dasar Sign in with Google, dan biarkan karyawan mengajukan permintaan akses yang nanti kamu setujui atau tolak.

Pembatasan ini memang menambah sedikit kerja admin saat ada karyawan yang butuh aplikasi baru. Tapi itu jauh lebih ringan dibanding membersihkan kotak masuk yang sudah dibaca aplikasi asing. Prinsip yang sama berlaku untuk semua hak akses, seperti dijelaskan di apa itu least privilege.

Bagaimana mengaudit aplikasi yang sudah terhubung?

Jadikan audit ini kegiatan rutin, misalnya tiap kuartal:

1. Buka daftar aplikasi pihak ketiga yang punya izin di tenant atau domain kantor.
2. Urutkan berdasarkan jumlah pengguna dan luas izin. Perhatikan aplikasi dengan izin baca atau kirim email, akses seluruh file, dan akses offline.
3. Untuk setiap aplikasi yang tidak dikenali, cari tahu siapa yang memakainya dan untuk apa.
4. Cabut yang tidak diperlukan, dan ganti aplikasi berizin luas dengan alternatif yang lebih sempit bila ada.
5. Catat aplikasi yang disetujui sebagai daftar resmi, sehingga audit berikutnya lebih cepat.

Kebiasaan karyawan memakai aplikasi tanpa sepengetahuan IT adalah akar dari banyak masalah ini, dan topiknya dibahas di shadow IT.