Muat Naik Fail dengan Selamat dalam CFML

Muat Naik Fail dengan Selamat dalam CFML

Muat naik fail ialah salah satu laluan serangan paling mudah jika tidak dikawal, kerana ia membolehkan penyerang menghantar kod boleh laksana atau kandungan berniat jahat terus ke pelayan anda. Dalam CFML, cffile dengan tindakan upload mengendalikan pemindahan fail, tetapi keselamatan sebenar datang daripada semakan jenis, had saiz, lokasi penyimpanan dan pemprosesan selepas muat naik. Artikel ini memandu anda menyusun kesemua kawalan itu supaya borang muat naik anda tidak menjadi pintu masuk.

Semak Jenis Fail Sebenar, Bukan Sambungan Sahaja

Sambungan fail mudah dipalsukan. Penyerang boleh menamakan semula fail boleh laksana sebagai .jpg dan menyemaknya sebagai imej. Oleh sebab itu, keselamatan tidak boleh bergantung pada sambungan sahaja. cffile menyokong atribut accept untuk mengehadkan jenis MIME atau sambungan yang dibenarkan, dan atribut blockedExtensions untuk menolak sambungan berbahaya. Namun pengesahan jenis MIME juga boleh dipalsukan oleh pelayar, jadi semak kandungan sebenar dengan FileGetMimeType() selepas fail diterima:

<cffile
    action="upload"
    destination="#expandPath('/uploads/pending')#"
    fileField="form.fileData"
    nameConflict="makeunique"
    accept="image/jpeg,image/png,image/gif"
    result="upload">

<cfif upload.fileWasSaved AND listFindNoCase("image/jpeg,image/png", FileGetMimeType(upload.serverDirectory & "/" & upload.serverFile)) EQ 0>
    <cffile action="delete" file="#upload.serverDirectory#/#upload.serverFile#">
    <cfthrow message="Jenis fail tidak dibenarkan">
</cfif>

FileGetMimeType() memulangkan jenis MIME fail yang diberikan, dan gabungan accept dengan semakan selepas muat naik memberikan dua lapisan pengesahan. Ingat bahawa fail yang tidak dikenali boleh diperiksa oleh pengesanan MIME berasaskan Tika dalam Lucee, tetapi anda tetap perlu menyenarai putihkan jenis yang anda terima dan menolak yang lain.

Had Saiz di Kedua-dua Lapisan

Fail yang besar boleh memenuhi cakera dan melemahkan pelayan. Had saiz mesti dikuatkuasakan di dua tempat kerana setiap satu menutup kelemahan yang lain. Di lapisan aplikasi, semak saiz dalam struktur hasil yang dipulangkan oleh cffile, yang mengandungi kunci fileSize:

<cffile
    action="upload"
    destination="#expandPath('/uploads/pending')#"
    fileField="form.fileData"
    nameConflict="makeunique"
    result="upload">

<cfif upload.fileSize GT 5242880>
    <cffile action="delete" file="#upload.serverDirectory#/#upload.serverFile#">
    <cfthrow message="Fail melebihi had 5 MB">
</cfif>

Di lapisan pelayan hadapan, tetapkan had pada pelayan web supaya permintaan yang terlalu besar ditolak sebelum sampai ke Lucee. Sebagai contoh, nginx menggunakan client_max_body_size untuk tujuan ini. Had di pelayan hadapan melindungi aplikasi daripada menerima muatan gergasi, manakala had aplikasi memberikan mesej yang lebih mesra pengguna. Butiran menyediakan pelayan hadapan ada dalam panduan nginx di hadapan Lucee.

Simpan di Luar Webroot atau dengan Nama Rawak

Fail yang dimuat naik tidak boleh diakses terus melalui URL, kerana penyerang boleh memuat naik skrip dan kemudian memanggilnya. Dua cara untuk mencegahnya ialah menyimpan fail di luar webroot sepenuhnya, atau menyimpan di dalam webroot dengan nama rawak yang tidak boleh diteka. Nama rawak juga menghalang perlanggaran nama dan menutup maklumat tentang fail asal. Gunakan createUUID() untuk menjana nama yang unik dan sukar diteka:

var ext = listLast(upload.clientFileExt, ".");
var newName = createUUID() & "." & ext;
fileMove(upload.serverDirectory & "/" & upload.serverFile, expandPath("/uploads") & "/" & newName);

Apabila anda menyimpan fail, rekodkan nama asal dalam pangkalan data secara berasingan dan hanya paparkan nama itu selepas enkod output, supaya nama asal yang berniat jahat tidak menjadi vektor suntikan skrip. Prinsip enkod ini sama seperti yang diterangkan dalam panduan keselamatan aplikasi web CFML.

Elak Nama Fail yang Boleh Dilaksanakan

Sambungan tertentu membawa risiko pelaksanaan pada pelayan, contohnya .cfm, .jsp, .php atau .exe. Jika fail sedemikian disimpan dalam webroot, ia boleh dijalankan dan memberi penyerang kawalan penuh. cffile menyediakan blockedExtensions untuk menolak senarai ini, dan Lucee turut menyediakan senarai blok lalai melalui sifat sistem LUCEE_UPLOAD_BLOCKLIST. Jangan hanya menyekat beberapa sambungan, kerana pelayan yang berbeza melayan sambungan yang berbeza, jadi lebih selamat menggunakan pendekatan senarai putih dengan accept dan menyimpan fail di tempat yang tidak boleh dilaksanakan.

Memproses Imej dengan Selamat

Imej yang dimuat naik boleh membawa kod berniat jahat yang tersembunyi dalam metadata atau struktur fail. Cara paling berkesan untuk meneutralkannya ialah membaca semula imej dengan imageRead() dan menulisnya semula dengan imageWrite(), yang membuang kebanyakan data tersembunyi dan menghasilkan fail yang bersih:

// Baca imej dan tulis semula untuk membuang data tersembunyi
var img = imageRead(upload.serverDirectory & "/" & upload.serverFile);
imageWrite(img, expandPath("/uploads") & "/" & newName, 0.9, true);

Langkah ini juga menukar imej kepada format yang anda kawal dan boleh mengecilkan saiznya. Sebelum ini, pastikan fail itu benar-benar imej dan bukan skrip yang dinamakan semula, kerana imageRead() akan gagal pada fail yang bukan imej, dan kegagalan itu sendiri ialah pengesahan yang berguna.

Memadam Metadata

Imej daripada kamera dan telefon sering membawa metadata EXIF seperti koordinat GPS dan model peranti, yang boleh mendedahkan lokasi dan identiti pengguna. Tulis semula imej seperti di atas membuang sebahagian metadata, tetapi anda boleh menyemak apa yang tinggal dengan ImageGetEXIFMetadata(), yang memulangkan struktur metadata EXIF imej. Untuk aplikasi yang mementingkan privasi, periksa metadata ini sebelum memaparkan atau berkongsi imej, dan buang nilai yang tidak diperlukan. Amalan ini penting apabila imej pengguna boleh dilihat oleh orang lain.

Risiko Reputasi Muat Naik Terbuka kepada Awam

Jika aplikasi anda membenarkan orang awam memuat naik kandungan tanpa pendaftaran atau semakan, anda memikul risiko reputasi dan undang-undang. Pelayan anda boleh dijadikan tempat menyimpan kandungan haram, perisian hasad atau bahan yang melanggar hak cipta, dan domain anda akan dikaitkan dengannya. Kawalan yang diterangkan di atas mengurangkan risiko teknikal, tetapi risiko reputasi memerlukan dasar: hadkan muat naik kepada pengguna berdaftar, sederhanakan kandungan, dan sediakan mekanisme laporan. Cheat Sheet Muat Naik Fail OWASP menekankan bahawa pengesahan dan penyimpanan yang betul adalah keperluan minimum, bukan pilihan. Sekali domain anda disenaraihitamkan kerana kandungan tidak wajar, memulihkan reputasi memakan masa yang jauh lebih lama daripada membina kawalan ini dari awal.

Amalan Menyimpan di Storan Luar

Untuk aplikasi yang lebih besar, menyimpan fail pada pelayan aplikasi menjadi sukar diurus kerana sandaran, penskalaan dan had cakera. Storan objek luaran seperti S3 atau perkhidmatan serupa memisahkan fail daripada kod dan memudahkan penskalaan mendatar. Dalam kes ini, cffile masih menerima fail ke lokasi sementara, tetapi kemudian anda memindahkannya ke storan luaran dan menyimpan penunjuk dalam pangkalan data. Akses kepada storan luaran pula memerlukan kelayakan yang diuruskan dengan selamat seperti yang diterangkan dalam panduan mengurus rahsia CFML. Apabila anda perlu menghantar fail kepada pengguna, gunakan URL bertandatangan dengan tempoh sah yang singkat supaya akses terkawal dan boleh ditarik balik, dan bukannya mendedahkan storan secara umum.

Jadual Ringkasan Kawalan

Jadual berikut merumuskan setiap kawalan dan apa yang dilindunginya:

Apabila anda menyimpan rujukan fail dalam pangkalan data, gunakan pertanyaan berparameter seperti yang diterangkan dalam panduan cfquery dan cfqueryparam, supaya nama fail tidak menjadi laluan suntikan SQL.

Soalan Lazim (FAQ)

Adakah menyemak sambungan fail mencukupi?

Tidak. Sambungan mudah dipalsukan, jadi semak jenis MIME dengan accept dan sahkan kandungan sebenar dengan FileGetMimeType() selepas fail diterima.

Mengapa had saiz perlu di kedua-dua lapisan?

Had di pelayan hadapan menolak permintaan gergasi sebelum sampai ke Lucee, manakala had aplikasi memberikan mesej ralat yang mesra pengguna. Kedua-duanya melengkapi antara satu sama lain.

Di mana fail yang dimuat naik patut disimpan?

Di luar webroot, atau di dalam webroot dengan nama rawak yang sukar diteka. Ini menghalang fail boleh laksana daripada dipanggil terus melalui URL.

Bagaimana saya membuang metadata daripada imej?

Tulis semula imej dengan imageRead() dan imageWrite(), kemudian semak apa yang tinggal dengan ImageGetEXIFMetadata() untuk mengesahkan metadata sensitif telah dibuang.

Apa risiko membenarkan muat naik terbuka kepada awam?

Pelayan anda boleh dijadikan tempat menyimpan kandungan haram atau perisian hasad, mendedahkan anda kepada risiko reputasi dan undang-undang. Hadkan muat naik kepada pengguna berdaftar dan sederhanakan kandungan.

Sumber

• File Upload Cheat Sheet - OWASP
• cffile - Lucee Documentation
• FileGetMimeType() - Lucee Documentation
• ImageGetEXIFMetadata() - Lucee Documentation
• File Upload Operation Result - Lucee Documentation