Garuda CBT — Pembongkaran Keamanan

Controller Install tidak pernah dinonaktifkan setelah instalasi selesai, dan createAdmin() tidak punya guard autentikasi. Siapa pun, tanpa login, bisa meng-POST akun baru ke group admin pada instance yang sedang berjalan — lalu cukup masuk dengan akun itu. Guard check_installer() yang tersedia hanya menempel di index(), bukan di method yang benar-benar berbahaya.

Takeover total aplikasi: kelola guru dan siswa, baca dan ubah semua nilai serta rapor, ekspor bank soal beserta jawabannya, unduh backup database — dan bersama GBT-003, eksekusi SQL dan kode arbitrer. Tanpa kredensial, tanpa interaksi korban.

Kunci installer setelah instalasi (lock file atau konstanta INSTALLED) dan tolak createAdmin, createApp, createSetting, serta checkDatabase begitu admin sudah ada — guard harus menempel di setiap method, bukan hanya halaman pembuka.

checkDatabase() menerima nilai koneksi dari POST, melakukan str_replace ke template config PHP, lalu menulis ulang application/config/database.php — file yang justru diinstruksikan panduan instalasi untuk di-chmod 777. Filter xss_clean memblokir pemanggilan mencolok seperti system( dan eval(, tetapi daftar hitamnya mudah dilewati: popen() plus stream_get_contents() mengeksekusi perintah dengan sama senangnya. Satu request menulis payload; request berikutnya meng-include-nya.

Eksekusi perintah OS sebagai user web-server, tanpa autentikasi. Reverse shell, pembacaan config, persistensi — dan karena alur instalasinya sendiri menuntut config yang writable, kondisi rentan ini justru keadaan default dari deployment nyata.

Kunci installer (lihat GBT-001); hentikan interpolasi string mentah ke PHP yang tereksekusi — validasi input secara ketat (hostname hanya boleh [a-zA-Z0-9.:-]) dan tulis nilainya dengan var_export(); setelah instalasi, kembalikan permission yang waras dan hapus installer.

Controller Update dirilis tanpa guard autentikasi. Method-methodnya mendekrypt payload POST masukan dan langsung memasukkannya ke mysqli::multi_query() — stacked queries sesuai pesanan. Jebakannya seharusnya payload terenkripsi; tapi encryption key di-hardcode di repositori publik, identik di setiap instalasi. Saya mereimplementasi derivasi kunci HKDF-SHA512 milik CI3 secara offline, memalsukan payload terenkripsi yang valid, dan server mengeksekusi SQL di dalamnya. Dengan hak FILE milik user DB, SELECT ... INTO OUTFILE kemudian menulis webshell PHP ke webroot — rantai penuh, dari repo publik hingga RCE.

Dump seluruh database — hash password, data siswa, bank soal, jawaban, nilai. Sisipkan user admin, ubah atau drop tabel apa pun. Bila user DB memegang hak FILE (umum di shared hosting), webshell mendarat di webroot. Ini temuan dengan severity maksimum dari audit ini: CVSS 10.0, terverifikasi dari ujung ke ujung.

Guard admin dan nonce status update wajib di semua method Update; encryption key acak per-instalasi yang di-generate saat instalasi; validasi skema JSON payload terhadap whitelist alih-alih konkatenasi ke multi_query; cabut hak FILE dari user DB aplikasi dan set secure_file_priv yang ketat.

Parameter GET kelas melewati xss_clean — yang bukan escaping SQL — lalu dikonkatenasi langsung ke klausa LIKE di dalam string WHERE. Sesi level siswa (role terendah di sistem) bisa menutup quote, menyeimbangkan kurung, mengomentari sisanya, dan menjalankan oracle waktu: SLEEP(4) dijawab empat detik, SLEEP(0) seketika. Ekstraksi karakter demi karakter menyusul setelahnya.

Siswa mana pun bisa mengekstrak seluruh database lewat blind retrieval otomatis: hash kredensial, data pribadi teman sekelas dan guru, bank soal beserta jawabannya. Error SQL yang verbose (GBT-008) mempermudah pemetaannya.

Query Builder binding — where("a.kepada LIKE", "%$kelas%") — atau prepared statement; jangan pernah konkatenasi input ke string WHERE. Audit setiap pemanggilan get_where() yang menginterpolasi variabel.

Pola sink yang sama, pintu berbeda: controller buku rapor meneruskan tp (tahun ajaran) dan smt (semester) ke lookup model yang membangun klausa get_where() dengan konkatenasi mentah. Satu AND SLEEP(4)# pada parameter tp menahan respons selama empat detik. Pola identik berulang di beberapa controller lain — satu sink, banyak jalur.

Kelas ekstraksi database penuh yang sama seperti GBT-004, dapat dijangkau role terautentikasi mana pun yang bisa membuka buku rapor.

Parameter binding di getTahunById() dan getSemesterById() plus audit atas semua pemanggilnya; perlakukan ini sebagai satu perbaikan sistemik, bukan dua tiket.

Tiga endpoint yang mengubah state — saveMateri, uploadfile, deletefile — dikecualikan dari proteksi CSRF demi kemudahan progress bar AJAX. Halaman yang dikontrol penyerang karenanya bisa mengarahkan browser guru yang sedang login untuk mengunggah file, dan lebih parah lagi: saveMateri memproses konten materi sebagai HTML, mendekode setiap data URI <img> base64, lalu menuliskannya ke disk dengan ekstensi file yang diambil dari MIME type yang dikontrol penyerang. application/php lolos sebagai file .php — webshell, tersimpan dan tersaji.

Satu kunjungan ke halaman jebakan saat login sebagai guru atau admin menyerahkan webshell PHP di server kepada penyerang — RCE dengan satu klik korban. deletefile merangkap sebagai penghapusan file materi sembarangan.

Hapus ketiga URI dari csrf_exclude_uris dan buat handler-nya kompatibel CSRF (token via header AJAX); jangan pernah menurunkan ekstensi file dari MIME yang dikontrol klien — whitelist ekstensi gambar dan paksa img_*.jpg|png; matikan eksekusi PHP di dalam uploads/ sebagai defense in depth yang mutlak.

Field teks pengumuman disimpan tanpa filter XSS dan dirender kembali dengan output <?= ?> mentah — tidak ada html_escape. Tag <script> yang diposting bertahan hidup sampai dinding pengumuman, tempat semua role di sekolah membacanya.

Eksekusi script di browser setiap pembaca — admin, guru, siswa. Pencurian cookie diredam HttpOnly, tapi aksi UI atas nama korban, defacement, dan phishing tetap di atas meja.

html_escape() saat output; jika rich text benar-benar diperlukan, sanitasi sisi server dengan HTML purifier alih-alih mempercayai input.

Tiga pengaktif dalam satu temuan. Encryption key di-hardcode di repo publik — nilai yang sama di setiap instalasi, dan kunci langsung untuk memalsukan payload GBT-003. ENVIRONMENT dirilis sebagai development, sehingga db_debug menyajikan error SQL lengkap — nomor error, path file, baris model — langsung ke pengguna. Dan panduan instalasi menginstruksikan chmod 777 pada database.php, membiarkan pintu GBT-002 terbuka lebar di deployment nyata.

Bukan pelanggaran langsung secara sendirian, tapi menggandakan setiap temuan lain: kripto palsu, rekon verbose, dan config yang writable adalah dinding penyangga rantai Critical.

Generate encryption key acak saat instalasi; rilis ENVIRONMENT=production sebagai default; tulis ulang instruksi instalasi dengan permission yang waras.

Temuan review statis yang tidak memerlukan bukti dinamis: utilitas dev Compare yang bisa membuat dan drop tabel tanpa autentikasi (berbahaya di mana pun DB group-nya ada); Dbmanager::hapusBackup() menghapus file tanpa validasi basename(); pola massal input->post(..., false) yang mematikan filter XSS pada field konten di banyak controller; csrf_cookie yang tidak HttpOnly; serta max-size upload yang dikontrol klien.

Masing-masing adalah celah pengerasan alih-alih pelanggaran yang didemonstrasikan — tapi bersama-sama mereka menggambarkan aplikasi yang tidak pernah menjadikan keamanan bagian dari siklus pembuatannya.

Hapus utilitas dev dari rilis produksi; basename() plus whitelist pada penghapusan backup; aktifkan kembali filter di field konten dengan encoding sisi output; batas ukuran upload sisi server.