Trust Issue

Jujur, dulu saya pikir keamanan itu cuma buat sistem-sistem besar yang targetnya memang sudah jelas. Saya sering banget nulis kode yang langsung nembak ke database cuma karena “input-nya dari internal service sendiri”. Waktu itu, saya merasa validasi itu cuma boilerplate yang bikin kerjaan makin lama. “Ah, yang penting fiturnya jadi,” gitu pikir saya.

Baru kerasa separah apa mindset itu waktu saya baca soal insiden Optus tahun 2022. Optus itu telco terbesar kedua di Australia, dan kasus ini jadi salah satu contoh favorit saya soal Trust Issue karena polanya persis sama dengan kebiasaan lama saya. Ada satu API yang awalnya cuma dipakai buat kebutuhan testing, dianggap tidak akan pernah diakses dari luar, jadi dibiarkan tanpa autentikasi sama sekali. Suatu waktu, API itu ternyata kebuka ke internet publik. Karena tidak ada pengecekan otorisasi, dan identifier customer-nya berurutan seperti 1, 2, 3, siapa pun yang nemuin endpoint itu tinggal bikin script buat looping angka dan narik data pelanggan satu per satu. Hasilnya, lebih dari sembilan juta data pelanggan, termasuk nomor paspor dan SIM, bocor ke publik.

OWASP API Security Top 10

Pola ini punya nama resminya, Broken Object Level Authorization (BOLA). Ini kerentanan nomor satu yang paling sering ditemukan di API menurut OWASP API Security Top 10, dan penyebabnya nyaris selalu sama, endpoint mengasumsikan bahwa siapa pun yang bisa mencapainya berhak atas data yang diminta.

Ah, andai aja dari dulu saya nggak males buat validasi. Andai aja dulu saya nganggep semua data yang masuk itu berpotensi bahaya. Padahal validasi dan otorisasi tuh gampang banget, cuma beberapa baris kode doang. Cuma suka males aja.

Kenapa sih kita harus berhenti percaya begitu saja sama input?

Sebenarnya, kuncinya sederhana tapi sering kita abaikan: sistem kita selalu jadi target. Attacker nggak pernah peduli seberapa kecil aplikasi yang kita bangun, atau seberapa “internal” kita pikir sebuah endpoint itu. Optus nggak kebobolan karena attacker-nya jenius. Mereka kebobolan karena satu asumsi yang salah, bahwa endpoint testing itu nggak akan pernah dilihat orang luar.

Meskipun sistem kita digunakan oleh user internal, tapi kan bisa saja akun itu sudah di-takeover oleh attacker. Atau bisa juga ada bug di service lain, atau kesalahan konfigurasi seperti yang terjadi di Optus, yang bikin sesuatu yang harusnya tertutup jadi kebuka ke luar. Jadi, kalau kita masih berpikir “ah, ini kan cuma buat internal, nggak bakal dilirik hacker,” itu adalah mindset yang sangat berbahaya. Kita harus mulai melihat setiap input sebagai potensi ancaman, bukan cuma sebagai data yang perlu diproses.

Melakukan validasi input itu bukan cuma soal “biar nggak error”, tapi soal memegang kendali atas apa yang boleh dan tidak boleh masuk ke sistem kita. Kalau kita sendiri tidak bisa memastikan data itu valid dan aman, bagaimana kita bisa menjamin sistem kita aman? Kita harus mulai membiasakan diri untuk selalu memeriksa setiap input, baik itu dari user, service lain, atau bahkan dari sistem internal kita sendiri. Jangan pernah percaya begitu saja sama input apapun, karena di dunia keamanan, kepercayaan itu adalah pintu masuk bagi serangan.

Yang bikin saya makin yakin ini bukan soal effort besar adalah, celah di Optus itu bisa ditutup dengan satu pengecekan otorisasi yang sederhana. Bukan arsitektur baru, bukan tools mahal. Cuma disiplin buat nggak pernah asumsi sebuah endpoint aman hanya karena posisinya di dalam firewall atau statusnya “cuma buat testing”.

Kesalahan yang sama juga bisa muncul di layer LLM. Kalau sistem nggak pernah mem-validasi dan sanitasi prompt dari user, secara prinsip ini tuh ya Trust Issue. Pernah terjadi pada Chatbot perusahaan mobil dunia, ChatBot-nya dikasih sebuah prompt sampai ChatBot-nya setuju “menjual” mobil dengan harga $1 aja.

Sumber: Optus, laporan investigasi Office of the Australian Information Commissioner, 2022; Chevrolet dealer chatbot, AI Incident Database, Incident 622.

1. Anggap setiap endpoint bisa diakses siapa saja, bahkan yang menurutmu cuma dipakai internal atau testing.

2. Cek ulang, apakah endpoint ini butuh autentikasi, dan apakah user yang sudah login itu memang divalidasi punya izin atas data spesifik yang diminta, bukan cuma sekadar berhasil login.

3. Kalau identifier di endpoint itu gampang ditebak, seperti angka urut atau incremental ID, ganti ke identifier yang nggak bisa ditebak seperti UUID.

4. Jangan asumsikan lapisan lain (firewall, VPN, network internal) akan menutupi kelalaian ini.

5. Selalu lakukan Validasi dan Sanitasi terhadap input dalam bentuk apapun

PRINSIP UTAMA:

Jangan Pernah Percaya Input Apapun