Sebuah dokumen berhasil diunggah ke portal perusahaan. Aplikasi langsung menampilkan tombol unduh, sementara layanan keamanan memeriksa berkas tersebut di latar belakang.

Pengguna lain mengunduhnya. Beberapa saat kemudian, hasil pemindaian menyatakan bahwa berkas mengandung ancaman.

Aplikasi segera menghapus dokumen dan menampilkan peringatan. Namun, salinannya sudah berada di perangkat penerima.

Dalam ilustrasi tersebut, pemindai mungkin menjalankan tugasnya dengan benar. Kegagalan terjadi pada urutan kepercayaan: aplikasi mengizinkan berkas beredar sebelum memperoleh hasil pemeriksaan yang diperlukan.

Keberadaan pemindaian malware belum membuktikan keamanan fitur unggah dokumen. Hasil pemeriksaan harus menentukan kapan berkas boleh diakses dan digunakan.

Jika keputusan itu datang setelah unduhan terjadi, perlindungan bergeser menjadi penanganan setelah paparan.

Pemindai Bekerja, tetapi Aplikasi Terlambat Membatasi Akses

Pemindaian asinkron membantu aplikasi menangani unggahan tanpa menahan koneksi pengguna sampai pemeriksaan selesai. Berkas diterima lebih dahulu, kemudian diproses melalui antrean atau layanan terpisah.

Pendekatan tersebut dapat digunakan dengan aman apabila berkas tetap dibatasi selama pemeriksaan. Persoalan muncul ketika penerimaan unggahan sekaligus membuatnya tersedia bagi pengguna atau proses berikutnya.

Dokumentasi Microsoft Defender for Storage menjelaskan bahwa durasi pemindaian dapat bervariasi berdasarkan ukuran, jenis berkas, beban layanan, dan latensi penyimpanan. Dokumentasi itu juga menyebutkan bahwa akses baca atau tulis pada penyimpanan tetap tersedia selama pemindaian.

Artinya, layanan pemindaian dan pembatasan akses merupakan kemampuan yang perlu dihubungkan oleh rancangan aplikasi. Mengaktifkan pemindai tidak boleh diasumsikan otomatis menahan seluruh unduhan.

Perusahaan perlu mengetahui apa yang terjadi sejak unggahan diterima sampai hasil pemeriksaan tersedia. Pada rentang waktu itulah berkas dapat lolos ke pengguna, layanan pratinjau, atau integrasi lain apabila tidak ada pembatasan yang efektif.

Status “Berhasil Diunggah” Terlalu Cepat Dianggap Siap Digunakan

Pemberitahuan unggahan berhasil sering mencampurkan dua keadaan yang berbeda: berkas telah diterima dan berkas telah disetujui untuk digunakan.

Berkas yang selesai ditransfer masih dapat menunggu pemeriksaan. Pemindaian juga dapat gagal, tertunda, atau tidak mampu memeriksa isinya secara memadai.

Karena itu, aplikasi membutuhkan status yang mewakili keadaan tersebut secara jelas. Sebagai rancangan awal, perusahaan dapat membedakan:

• Diterima dan menunggu pemeriksaan.
• Sedang diperiksa.
• Disetujui untuk penggunaan sesuai kebijakan.
• Ditolak karena ditemukan ancaman.
• Belum dapat diputuskan karena pemeriksaan tidak selesai.

Nama status dapat disesuaikan dengan kebutuhan aplikasi. Hal yang lebih penting adalah konsekuensinya terhadap akses.

Berkas yang masih menunggu keputusan tidak seharusnya diperlakukan sama dengan berkas yang telah melewati pemeriksaan wajib. Antarmuka dapat menampilkan bahwa unggahan berhasil diterima, sementara unduhan dan distribusinya tetap ditahan.

Pemisahan ini membantu pengguna memahami proses sekaligus memberi dasar yang jelas bagi pengendalian di sisi server.

Karantina Harus Berlaku pada Seluruh Jalur Akses

Menyembunyikan tombol unduh belum membuktikan bahwa berkas berada dalam karantina.

Pengguna mungkin masih dapat mengambilnya melalui alamat penyimpanan langsung, API, tautan berbagi, atau tautan bertanda tangan yang diterbitkan ketika unggahan selesai.

Pembatasan perlu berlaku pada komponen yang benar-benar menyerahkan isi berkas.

Dokumentasi Amazon GuardDuty menunjukkan contoh penggunaan kebijakan penyimpanan berbasis tag hasil pemindaian untuk mengendalikan pembacaan objek. Dokumentasi tersebut juga menekankan perlunya melindungi tag agar tidak dapat diubah oleh pihak yang tidak berwenang.

Prinsip yang dapat diambil adalah bahwa status pemeriksaan harus menjadi bagian dari keputusan akses dan memiliki sumber yang dapat dipercaya.

Karantina juga harus mencakup pemrosesan lanjutan. Berkas yang belum disetujui sebaiknya tidak otomatis dikirim melalui surel, diindeks, atau diteruskan ke sistem bisnis.

Pembuatan pratinjau dan ekstraksi teks memerlukan perhatian tersendiri. Komponen tersebut membaca konten yang belum dipercaya sehingga perlu dibatasi kewenangan dan sumber dayanya. Layanan pemeriksa tentu memerlukan akses untuk menjalankan tugasnya, tetapi akses itu harus diberikan secara khusus.

Hasil Pemindaian Harus Melekat pada Versi yang Tepat

Ada persoalan lain setelah mekanisme karantina diterapkan: apakah berkas yang diunduh benar-benar sama dengan berkas yang diperiksa?

Bayangkan sebuah objek telah memperoleh hasil pemeriksaan yang memenuhi kebijakan. Setelah itu, isinya diganti menggunakan lokasi atau identitas yang sama, sementara aplikasi masih mempertahankan status persetujuan sebelumnya.

Dalam keadaan tersebut, hasil pemeriksaan lama dapat digunakan untuk melepas konten baru.

Rancangan yang lebih kuat perlu mengikat keputusan pada versi objek atau identitas konten yang sesuai. Setiap penggantian isi harus memicu evaluasi baru sebelum versi tersebut tersedia.

Mekanisme pemberitahuan hasil juga perlu memverifikasi bahwa hasil berasal dari layanan yang sah dan cocok dengan pekerjaan pemeriksaan yang dimaksud.

Hal ini penting ketika pesan terlambat atau diterima berulang. Hasil untuk versi sebelumnya tidak boleh mengubah status versi terbaru secara keliru.

Pemindahan berkas dari area karantina ke area distribusi pun harus menjaga hubungan tersebut. Jangan sampai aplikasi memeriksa satu versi, lalu menyalin atau menyajikan versi lain karena objek berubah di tengah proses.

Pemindaian Gagal Tidak Sama dengan Tidak Ditemukan Ancaman

Logika yang hanya mengenali status “berbahaya” dan “selainnya” dapat menciptakan celah serius.

Hasil selain berbahaya mungkin berarti belum diperiksa, pemeriksaan melewati batas waktu, atau layanan tidak dapat membaca isinya. Keadaan tersebut belum memberikan dasar untuk menyetujui distribusi.

Dokumentasi layanan pemindaian cloud mencantumkan berbagai keterbatasan, termasuk kondisi terkait enkripsi, kata sandi, kompleksitas arsip, dan batas pemrosesan. Perilakunya berbeda menurut produk dan format.

Perusahaan perlu menetapkan penanganan untuk setiap hasil yang relevan. Berkas dapat tetap dikarantina, diminta untuk diunggah ulang dalam format yang didukung, atau dialihkan ke pemeriksaan tambahan yang terkendali.

Tetapkan pula batas waktu penanganan agar dokumen tidak tertahan tanpa kejelasan. Pengguna memerlukan pemberitahuan yang dapat ditindaklanjuti, sedangkan pengelola membutuhkan pemantauan atas antrean dan kegagalan pemeriksaan.

Jika terdapat pengecualian bisnis, pelepasannya harus melalui kewenangan khusus dan pencatatan yang jelas. Gangguan pemindai tidak semestinya secara otomatis mengubah seluruh berkas tertunda menjadi tersedia.

Pemindaian Tetap Memerlukan Perlindungan Berlapis

Hasil pemeriksaan yang tidak menemukan ancaman bukan jaminan mutlak bahwa berkas tidak memiliki risiko.

OWASP merekomendasikan perlindungan unggahan yang menggabungkan pembatasan jenis dan ukuran berkas, validasi konten, pengaturan penyimpanan, pemeriksaan antimalware, serta pembatasan kewenangan. Tidak ada satu teknik yang menyelesaikan seluruh ancaman unggahan.

Relevansi pengujian juga terlihat dalam penelitian “FUSE: Finding File Upload Bugs via Penetration Testing” yang dipublikasikan pada NDSS Symposium 2020. Penelitian tersebut menunjukkan kelemahan unggahan pada aplikasi web yang diteliti dapat berujung pada eksekusi kode.

Fokus FUSE berbeda dari persoalan distribusi sebelum pemindaian selesai. Temuannya memperkuat kebutuhan mengevaluasi keseluruhan penanganan berkas, termasuk bagaimana konten disimpan dan diproses.

Bagi perusahaan, pemindaian harus ditempatkan dalam rangkaian perlindungan yang saling melengkapi. Berkas yang boleh disimpan belum tentu boleh dieksekusi, ditampilkan langsung di peramban, atau diproses tanpa pembatasan.

Uji Jeda Sebelum Pemindaian Selesai

Pengujian fitur unggah tidak cukup dilakukan dengan menunggu hasil akhir, lalu memastikan berkas yang ditolak sudah dihapus.

Tim perlu memeriksa apakah isi berkas sempat tersedia sebelum keputusan tersebut.

Analisis ini sering kami temukan saat melakukan penetration testing pada perusahaan di Indonesia.

Pengujian dapat menggunakan berkas aman dengan penanda unik dan mekanisme penundaan pemindaian yang dikendalikan pada lingkungan uji. Tujuannya membuktikan perilaku akses selama berkas masih menunggu keputusan.

Skenario yang perlu dievaluasi meliputi:

• Unduhan segera setelah transfer unggahan selesai.
• Akses melalui API dan alamat penyimpanan langsung.
• Penggunaan tautan berbagi atau tautan bertanda tangan sebelum persetujuan.
• Pemanggilan layanan pratinjau ketika status masih tertunda.
• Gangguan atau batas waktu pemeriksaan.
• Penggantian isi setelah versi sebelumnya disetujui.
• Penerimaan hasil pemindaian yang terlambat atau berulang.
• Pengiriman otomatis ke sistem lain sebelum pemeriksaan selesai.

Bukti pengujian perlu menunjukkan waktu penerimaan berkas, hasil permintaan akses, versi objek, waktu keputusan pemeriksaan, dan waktu pelepasan.

Pesan pada antarmuka saja belum cukup. Tim harus memverifikasi apakah isi berkas benar-benar dapat diterima oleh pengguna atau komponen yang seharusnya belum memperoleh akses.

Periksa pula cache distribusi. Penghapusan di penyimpanan utama belum membuktikan bahwa seluruh salinan yang sempat diterbitkan sudah tidak tersedia.

Ukur Kapan Berkas Mulai Dipercaya

Ukuran keamanan unggahan perlu mencakup urutan penerimaan, pemeriksaan, dan distribusi.

Perusahaan harus dapat membuktikan bahwa hanya berkas dengan keputusan yang memenuhi kebijakan yang dilepas kepada pengguna. Hak pengguna untuk mengakses dokumen juga tetap perlu diperiksa setelah persyaratan pemindaian terpenuhi.

Tanggung jawab tersebut membutuhkan koordinasi antara pengembang aplikasi, pengelola penyimpanan, tim keamanan, dan pemilik proses bisnis.

Pemindai bertugas memberikan hasil pemeriksaan. Aplikasi dan kebijakan penyimpanan harus memastikan hasil tersebut diterapkan sebelum konten tersedia.

Keberhasilan perlindungan ditentukan oleh hubungan antarkomponen itu. Peringatan yang akurat tetap datang terlambat apabila berkas sudah telanjur beredar.

Evaluasi Keamanan Unggah Dokumen Bersama Fourtrezz

Fourtrezz menyediakan layanan Penetration Testing dan Vulnerability Assessment untuk aplikasi web, API, jaringan, serta server.

Diskusikan kerja sama dengan Fourtrezz untuk menyusun pengujian fitur unggah yang sesuai dengan arsitektur perusahaan Anda. Ruang lingkup dapat mencakup validasi berkas, kontrol akses unduhan, penyimpanan, integrasi pemindai, serta perilaku aplikasi ketika pemeriksaan tertunda atau gagal.

Pengujian yang terarah membantu perusahaan memperoleh bukti teknis untuk menentukan prioritas perbaikan sebelum dokumen yang belum diperiksa mencapai pengguna.

Hubungi Fourtrezz:

Website: www.fourtrezz.co.id
Telepon/WhatsApp: +62 857-7771-7243
Email: [email protected]