Upload Vulnerabilities - Filtering


Pertama, mari kita bahas perbedaan antara penyaringan client-side filtering dan server-side filtering
. client-side dalam konteks aplikasi web, yang kita maksud adalah skrip tersebut berjalan di peramban pengguna dan bukan di server web itu sendiri. JavaScript cukup umum sebagai bahasa skrip client-side, meskipun ada alternatifnya. Terlepas dari bahasa yang digunakan, skrip sisi klien akan berjalan di peramban web Anda. Dalam konteks unggahan berkas, ini berarti penyaringan terjadi bahkan sebelum berkas diunggah ke server. Secara teori, ini tampak seperti hal yang baik, bukan? Dalam dunia yang ideal, memang demikian; namun, karena penyaringan terjadi di komputer kita , penyaringan tersebut dapat dengan mudah dilewati. Dengan demikian, penyaringan client-side itu sendiri merupakan metode yang sangat tidak aman untuk memverifikasi bahwa berkas yang diunggah tidak berbahaya.

. skrip server-side akan dijalankan di server. Secara tradisional, PHP adalah bahasa sisi server yang dominan (dengan ASP for IIS Microsoft di urutan kedua); namun, dalam beberapa tahun terakhir, opsi lain (C#, Node.js, Python, Ruby on Rails, dan berbagai lainnya) telah digunakan secara lebih luas. Pemfilteran server-side cenderung lebih sulit untuk dilewati, karena Anda tidak memiliki kode di depan Anda. Karena kode dieksekusi di server, dalam kebanyakan kasus, tidak mungkin untuk melewati filter sepenuhnya; sebaliknya, kita harus membentuk payload yang sesuai dengan filter yang ada, tetapi masih memungkinkan kita untuk mengeksekusi kode kita.

Dengan mengingat hal itu, mari kita lihat beberapa jenis penyaringan.


Extension Validation:

Extension berkas digunakan (secara teori) untuk mengidentifikasi isi berkas. Dalam praktiknya, Extension berkas sangat mudah diubah, jadi sebenarnya tidak terlalu berarti; namun, MS Windows masih menggunakannya untuk mengidentifikasi jenis berkas, meskipun sistem berbasis Unix cenderung mengandalkan metode lain, yang akan kita bahas sebentar lagi. Filter yang memeriksa Extension berfungsi dengan salah satu dari dua cara. Filter tersebut memasukkan Extension ke daftar hitam (yaitu memiliki daftar Extension yang tidak diizinkan) atau memasukkan Extension ke daftar putih (yaitu memiliki daftar Extension yang diizinkan , dan menolak semua ekstensi lainnya).


File Type Filtering:

Mirip dengan Extension Validation, tetapi lebih intensif, penyaringan jenis berkas bertujuan, sekali lagi, untuk memverifikasi bahwa konten berkas dapat diterima untuk diunggah. Kita akan melihat dua jenis validasi jenis berkas:

. MIME validation: MIME (Multipurpose Internet Mail Extension) digunakan sebagai pengenal untuk file -- awalnya saat ditransfer sebagai lampiran melalui email, tetapi sekarang juga saat file ditransfer melalui HTTP(S). Tipe MIME untuk unggahan file dilampirkan di header permintaan, dan terlihat seperti ini:
Content-type: image/jpeg
MIME mengikuti format '<tipe>/<subtipe>". Dalam permintaan di atas, Anda dapat melihat bahwa gambar "spaniel.jpg" diunggah ke server. Sebagai gambar JPEG yang sah, tipe MIME untuk unggahan ini adalah "image/jpeg". Tipe MIME untuk file dapat diperiksa di sisi klien dan/atau sisi server; namun, karena MIME didasarkan pada ekstensi file, ini sangat mudah untuk dilewati.

. Magic Number validation: adalah cara yang lebih akurat untuk menentukan isi berkas; meskipun, Magic Number sama sekali tidak mungkin dipalsukan. "Magic Number" berkas adalah serangkaian byte di awal konten berkas yang mengidentifikasi konten tersebut. Misalnya, berkas PNG akan memiliki byte berikut di bagian paling atas berkas: 89 50 4E 47 0D 0A 1A 0A.
Tidak seperti Windows, sistem Unix menggunakan angka ajaib untuk mengidentifikasi berkas; namun, saat menangani unggahan berkas, Anda dapat memeriksa Magic Number berkas yang diunggah untuk memastikan bahwa berkas tersebut aman untuk diterima. Ini sama sekali bukan solusi yang terjamin, tetapi lebih efektif daripada memeriksa ekstensi berkas.

. File Length Filtering: File Length Filtering digunakan untuk mencegah berkas berukuran besar diunggah ke server melalui formulir unggah (karena hal ini berpotensi menguras sumber daya server). Dalam sebagian besar kasus, hal ini tidak akan menimbulkan masalah apa pun saat mengunggah shell; namun, perlu diingat bahwa jika formulir unggah hanya mengharapkan berkas yang sangat kecil untuk diunggah, mungkin ada filter panjang yang diterapkan untuk memastikan bahwa persyaratan panjang berkas dipatuhi. Sebagai contoh, reverse shell PHP lengkap dari tugas sebelumnya berukuran 5,4 Kb -- relatif kecil, tetapi jika formulir mengharapkan maksimal 2 Kb, maka kita perlu mencari shell alternatif untuk diunggah.

. File Name Filtering: Seperti yang telah disinggung sebelumnya, file yang diunggah ke server harus unik. Biasanya ini berarti menambahkan aspek acak ke nama file, namun, strategi alternatifnya adalah memeriksa apakah file dengan nama yang sama sudah ada di server, dan memberikan kesalahan kepada pengguna jika sudah ada. Selain itu, nama file harus disanitasi saat diunggah untuk memastikan bahwa file tersebut tidak mengandung "karakter buruk", yang berpotensi menyebabkan masalah pada sistem file saat diunggah (misalnya null byte atau garis miring di Linux , serta karakter kontrol seperti ; dan mungkin karakter unicode). Artinya bagi kita adalah, pada sistem yang dikelola dengan baik, file yang kita unggah tidak mungkin memiliki nama yang sama dengan yang kita berikan sebelum diunggah, jadi ketahuilah bahwa Anda mungkin harus mencari shell Anda jika Anda berhasil melewati penyaringan konten.

. File Content Filtering: Sistem penyaringan yang lebih rumit dapat memindai seluruh isi berkas yang diunggah untuk memastikan bahwa berkas tersebut tidak memalsukan ekstensi, tipe MIME , dan Magic Number. Ini adalah proses yang jauh lebih rumit daripada yang digunakan sebagian besar sistem penyaringan dasar.

Perlu dicatat bahwa tidak satu pun dari filter ini yang sempurna jika berdiri sendiri -- filter-filter ini biasanya akan digunakan bersama-sama, menyediakan filter berlapis-lapis, sehingga meningkatkan keamanan unggahan secara signifikan. Semua filter ini dapat diterapkan di client-side, server-side, atau keduanya.
Demikian pula, berbagai kerangka kerja dan bahasa memiliki metode bawaannya sendiri untuk memfilter dan memvalidasi berkas yang diunggah. Akibatnya, eksploitasi khusus bahasa dapat muncul; misalnya, hingga PHP versi lima, dimungkinkan untuk melewati filter ekstensi dengan menambahkan byte nol, diikuti oleh ekstensi yang valid, ke .phpberkas berbahaya. Baru-baru ini, dimungkinkan juga untuk menyuntikkan kode PHP ke dalam data exif dari berkas gambar yang valid, lalu memaksa server untuk mengeksekusinya.


tags