Photo by Cecep Rahmat on Unsplash
Introduction
Di tengah hiruk pikuk tren lari yang semakin masif, terutama di kalangan Gen Z, ada satu pertanyaan krusial yang sering terlupakan: apakah data pribadi kita aman?
Popularitas lari memang tak bisa dimungkiri. Selain murah dan mudah, lari menawarkan segudang manfaat kesehatan dan membentuk komunitas yang suportif. Ditambah lagi, kehadiran media sosial menjadikan lari sebagai tren yang “Instagram-able”. Berbagai event lari yang menarik pun menjamur, dari fun run sampai maraton internasional, semuanya kini bisa didaftarkan secara digital hanya dengan sentuhan jari. Cukup isi data diri, bayar, sudah dapat BIB (nomor peserta).
Kemudahan itu ternyata menyimpan bahaya tersembunyi. Pernahkah kamu berpikir, seaman apa sih situs web pendaftaran event lari yang kamu gunakan? Di negara kita, berita kebocoran data seolah jadi santapan harian, menimpa berbagai platform mulai dari e-commerce, logistik, perbankan, hingga instansi pemerintah. Data yang bocor ini sering kali berakhir di forum-forum hacker dan dijual bebas.
Sebagai pengguna, kita sering merasa pasrah. Tapi, tahukah kamu dampak dari kebocoran data itu? Dampak paling nyata adalah menjadi target penipuan. Para penipu kini lebih canggih karena mereka sudah punya informasi pribadi kita. Mungkin kamu pernah mengalami, atau setidaknya mendengar cerita, di mana ada penipu yang menelepon atau mengirim pesan dan tahu nama lengkapmu.
Bagi kita yang awam dengan dunia IT, situasi seperti ini bisa sangat meyakinkan. Kita akan mudah percaya bahwa panggilan atau pesan itu datang dari pihak yang kita kenal atau bahkan instansi resmi. Kita baru sadar ketika saldo di rekening tiba-tiba lenyap, uang ditransfer ke orang tak dikenal, atau menjadi korban pemerasan.
Selain platform yang sudah saya sebutkan di atas, data kamu juga bisa bocor melalui website pendaftaran event lari yang tidak aman. Lalu, kalau sudah begini, apa yang dapat diambil? pelajaran? hikmahnya?
Daripada bingung, artikel ini ditujukan untuk dua pihak: pemilik/pengembang situs web event lari dan para pelari itu sendiri.
Bagi pemilik dan pengembang, sudah saatnya meningkatkan kewaspadaan terhadap keamanan data pengguna. Melindungi data bukan hanya soal etika, tetapi juga dapat membangun reputasi dan kepercayaan. Di tengah kompetisi yang ketat, situs web yang aman akan lebih dipilih oleh calon peserta.
Sementara itu, bagi kalian para pelari, tetaplah berhati-hati. Jangan mudah percaya dengan tautan atau pesan yang mencurigakan, meskipun tampaknya berasal dari pihak yang sah. Selalu cek kembali keaslian situs web pendaftaran dan pastikan koneksinya aman.
Euforia lari memang menyehatkan, tapi jangan sampai kelalaian digital merugikan kita. Semoga artikel ini bisa menjadi pengingat bagi kita semua agar tetap aman dan waspada di dunia digital.
Study Case
Apa maksudnya?
Developer mungkin memiliki kebijakan untuk menampilkan data peserta secara publik, seperti nama, nomor BIB, jenis kelamin, dan asal kota, di sebuah API dengan alamat
/event-peserta-terdaftar?param-blablabla. Tujuannya baik, yaitu untuk memudahkan pengguna lain melihat siapa saja yang sudah mendaftar.
Namun, implementasinya justru bertentangan dengan prinsip keamanan data. Meskipun yang ditampilkan di halaman web hanya data dasar, respons dari API itu sendiri malah memuat informasi sensitif dan lengkap, seperti nomor kontak, email, alamat lengkap, bahkan identitas diri (KTP). Data ini seharusnya tidak pernah diekspos secara publik.
Inilah yang membuat data bocor. Celah desain yang buruk ini membuat informasi sensitif terpapar, berpotensi disalahgunakan, dan merugikan semua pihak.
Data yang bocor tidak hanya terbatas pada peserta lari. Ternyata, informasi event organizer pun ikut terekspos. Seperti yang terlihat, data tersebut mencakup kata sandi beruntung bentuk nya hash (bcrypt). Di situs pertama ini tidak saya lanjutkan untuk mencari celah lebih dalam.
Tapi apakah bcrypt bisa dicrack? Ya, Secara teori, Bcrypt dapat dibobol melalui serangan brute force, namun prosesnya membutuhkan waktu yang sangat lama.
Meskipun demikian, kecepatan pembobolan sangat bergantung pada kompleksitas kata sandi. Kata sandi yang hanya terdiri dari angka bisa dibobol dalam hitungan jam, sedangkan kata sandi dengan kombinasi karakter dan panjang lebih dari delapan akan membuat serangan brute force menjadi tidak mungkin. Hal ini menyoroti bahaya besar ketika pengguna membuat kata sandi yang umum dan lemah, seperti “password” atau “123456”, karena kata sandi tersebut tetap rentan meskipun dilindungi oleh Bcrypt.
Case 2 – Upaya Bypass
Selain itu, saya juga memeriksa XSS Hunter dan menemukan bahwa situs ini rentan terhadap Stored XSS. Celah ini sangat berbahaya karena kode berbahaya yang disisipkan bisa tersimpan di server dan dieksekusi setiap kali halaman yang terinfeksi diakses oleh pengguna lain, termasuk admin.
Berikut halaman yang terdampak:
- (Unauth) Terdapat di halaman yang menampilkan daftar peserta. Artinya, setiap pengunjung yang melihat daftar tersebut bisa menjadi korban.
- (Authenticated) Celah ini juga ditemukan di beberapa menu admin seperti “Kelola Peserta”, “Rekap Event”, dll. Hal ini sangat krusial karena bisa memberikan penyerang akses ke akun admin dan kendali penuh atas sistem (tergantung situasi).
Tunggu dulu, screenshot dasbor admin yang saya tunjukkan di atas bukan berarti saya sudah berhasil masuk ke akun admin. Halaman itu adalah hasil kloning (cloning) dari XSS Hunter, yang kemudian saya akses secara lokal. Saya belum mendapatkan akses penuh ke halaman admin karena cookie-nya terlindungi oleh HttpOnly. Meskipun begitu, saya memiliki beberapa skenario lain untuk mengeksploitasi celah ini lebih jauh.
Saya pun memodifikasi payload tersebut agar pop-up hanya muncul di halaman admin (dengan kondisi jika URL mengandung kata kunci ‘kelola’). Setelah menunggu beberapa jam, admin masih belum terpancing, meskipun laporan dari XSS Hunter menunjukkan bahwa mereka telah mengakses halaman yang rentan.
Saya mulai bertanya-tanya, apakah overlay yang saya buat tidak berhasil? Apakah terjadi tabrakan dengan elemen HTML asli, atau jangan-jangan admin langsung menutup halaman begitu melihat form login yang mencurigakan?
Tanpa berpikir panjang, saya beralih ke skenario lain. Saya mulai membaca kode dari hasil kloningan halaman admin dan menemukan beberapa baris kode yang menarik, seperti img src yang menampilkan bukti pembayaran, endpoint upload, dan endpoint menu pengguna. Kode-kode ini berpotensi untuk dieksploitasi lebih lanjut.
Dari kode di atas, kita tahu bahwa ketika admin mengklik detail salah satu peserta, ada endpoint yang di-fetch melalui AJAX. URL dari endpoint ini diambil dari data-url dan responsnya menampilkan beberapa data penting, seperti id_registrasi, nama_peserta, email, tgl_bayar, dan yang paling menarik, reg_file (bukti pembayaran).
Ada juga blok kode yang berfungsi untuk mengunggah gambar. Respons dari endpoint ini adalah URL file yang berhasil diunggah. ini akan kita coba juga nanti.
Saya memutuskan untuk menggunakan metode fetch get-data-registrasi terlebih dahulu. Tujuannya adalah untuk mendapatkan nama file dari bukti transfer yang diunggah secara blind. Saya bisa mengunggah file, tetapi tidak tahu di mana file itu tersimpan.
Saya pun mencoba mengunggah sebuah file bukti payment, lalu menunggu admin mengakses halaman yang rentan tersebut. Saya menanti respons dari listener Beeceptor, tapi sepertinya saya kurang beruntung. Fungsi unggah file ini tampaknya tidak terpakai atau tidak dikelola. Mungkin karena mereka sudah menggunakan sistem payment gateway yang secara otomatis memverifikasi peserta, jadi fitur unggah manual tidak lagi digunakan. Namun sejauh ini data yang dibocorkan dari endpoint tersebut cukup krusial.
Kembali ke blok kode kelola/upload_image yang saya temukan di halaman admin, saya mencoba membuat file HTML sendiri untuk mengunggah berkas. Saya mencoba mengirim data POST langsung ke endpoint kelola/upload_image.
Namun, percobaan saya gagal karena terkena eror CORS Origin. Ini terjadi karena kebijakan keamanan browser membatasi permintaan dari origin yang berbeda. Dengan kata lain, browser mencegah skrip yang saya buat di luar domain situs untuk mengirim data ke endpoint tersebut.
Dari kondisi tersebut, muncul ide untuk menyuntikkan form upload file langsung ke situs web melalui celah XSS tersebut. Upaya ini berhasil mengunggah berkas, sekaligus melewati batasan CORS karena formulir tersebut seolah-olah berasal dari domain yang sah. Agar payload berfungsi, penyerang menambahkan parameter khusus ?kelola pada URL, yang sebelumnya telah disesuaikan agar hanya dapat dipicu di halaman admin. Dengan cara ini, meskipun berada di halaman depan (daftar peserta), penyerang dapat mentriger payload xss tersebut untuk menampilkan form upload.
Meski yakin bahwa form upload telah aman dari berkas berbahaya dengan memblokir ekstensi seperti PHP, PHTML, DLL , saya menemukan celah serius. Endpoint kelola/upload_image yang seharusnya hanya dapat diakses oleh administrator, ternyata dapat diakses secara tidak terautentikasi (unauthenticated access).
Inilah yang menjadi celah Broken Access Control (BAC). Meskipun saya harus melewati pembatasan CORS Origin, fakta bahwa endpoint kritis ini dapat dijangkau tanpa otentikasi menjadikannya kerentanan yang serius (attacker dapat melakukan spamming file upload).
POV Developer
Setelah menganalisis bagaimana situs saya dieksploitasi, saya menyadari pentingnya fokus pada keamanan pengguna dan sistem secara keseluruhan. Dari studi kasus ini, ada beberapa poin krusial yang harus segera saya perbaiki.
1. Keamanan Data di API Saya harus membatasi data yang dikirim dalam setiap respons API. Mengembalikan semua data, meskipun tidak digunakan di tampilan publik, adalah praktik yang berbahaya. Ke depannya, saya akan memastikan respons hanya berisi data yang benar-benar dibutuhkan.
2. Perbaikan Berbagai Kerentanan Kasus ini menunjukkan perlunya perbaikan menyeluruh pada berbagai sisi:
- Stored XSS, Untuk mencegah serangan ini, saya akan menerapkan sanitasi input dan output secara ketat. Menambahkan Web Application Firewall (WAF) juga bisa menjadi lapisan pertahanan tambahan untuk memblokir payload berbahaya. Atau terapkan CSP (Content Security Policy).
- Access Control, Saya perlu memperkuat kontrol akses agar endpoint administratif tidak bisa diakses dari luar. Endpoint sensitif harus dilindungi dengan otentikasi yang kuat.
- Parameter Tampering, Validasi harga harus dilakukan di sisi server untuk mencegah manipulasi. Daripada mengambil harga langsung dari endpoint, saya akan memanggil data harga dari backend dan menggunakannya untuk membuat pembayaran.
- CSRF, Saya harus memperketat mekanisme Cross-Site Request Forgery (CSRF) untuk melindungi permintaan penting dari penyerang.
Dengan menerapkan langkah-langkah ini, saya berharap dapat membangun sistem yang jauh lebih aman dan tidak merugikan user.
