Temu Duga Backend: Bagaimana Anda Mereka Bentuk API Muat Naik Fail yang Selamat?

Gesaan dan Senario yang Berkenaan

Perkhidmatan dokumen B2B berbilang penyewa membolehkan pengguna yang disahkan memuat naik lampiran PDF, JPEG dan PNG, dengan had 20 MiB bagi setiap fail. Selepas pemprosesan, hanya ahli yang dibenarkan daripada penyewa yang sama boleh memuat turun fail tersebut. Klien mengawal bait, nama fail asal, sambungan fail, Content-Type dan saiz yang diisytiharkan, jadi setiap satu daripada nilai tersebut adalah tidak dipercayai.

Reka bentuk API muat naik, pengimbasan, penerbitan dan muat turun yang selamat. Terangkan cara reka bentuk ini menghalang:

• web shell, jenis yang dipalsukan (spoofed types), sambungan berganda (double extensions), lintasan laluan (path traversal) dan penulisan ganti objek (object overwrite);
• PDF berniat jahat, eksploitasi penghurai imej (image-parser exploits), perisian hasad (malware) dan fail poliglot (polyglot files);
• akses rentas penyewa, kebocoran URL objek awam dan pemaparan sebaris (inline rendering) yang berbahaya;
• permintaan bersaiz besar, kuota storan habis, pertikaian imbasan (scan contention) dan gangguan pengimbas (scanner outages);
• fail diganti selepas melepasi imbasan, serta kerosakan keadaan (state corruption) daripada panggilan pelengkapan pendua.

Had 20 MiB, tiga format yang dibenarkan dan model penyewa B2B merupakan kekangan temu duga dan bukannya cadangan keselamatan universal. Calon mesti menghubungkan identiti, protokol muat naik, storan objek, kerja tak segerak (asynchronous work) dan kebenaran muat turun ke dalam sempadan yang boleh dipertahankan. Kecekapan teras adalah keselamatan API dan perkhidmatan backend, jadi kategorinya ialah backend.

Perkara yang Dinilai oleh Penemu Duga

Pertama, bolehkah calon menetapkan invarian (invariants)? Bait yang belum melepasi keputusan keselamatan kekal dalam kuarantin dan tidak boleh dibaca oleh pengguna perniagaan, dihuraikan oleh aplikasi, atau disampaikan daripada asal (origin) utama aplikasi. Nama fail klien tidak pernah menjadi laluan storan. Setiap bacaan dibenarkan semula.

Kedua, adakah mereka memahami pertahanan mendalam (defense in depth) untuk pengesahan jenis? Sambungan fail, Content-Type permintaan, tandatangan fail (file signature) dan hasil penghurai setiap satunya hanya memberikan bukti separa. Perkhidmatan tersebut harus menggabungkan senarai dibenarkan (allowlist) perniagaan, penormalan, penghuraian struktur, pengimbasan perisian hasad dan, jika sesuai, pengekodan semula atau pelucutan dan pembinaan semula kandungan (content disarm and reconstruction).

Ketiga, bolehkah mereka mereka bentuk mesin keadaan (state machine) tak segerak yang eksplisit? Menerima bait hanya bermakna objek telah sampai ke kuarantin. Ini tidak bermakna fail itu tersedia. API memerlukan keadaan pemprosesan, tersedia, ditolak dan kegagalan teknikal, dengan peraturan percubaan semula, tamat masa dan pembersihan yang tepat.

Keempat, adakah mereka mengesan scanning race? Pengimbas menilai satu jujukan bait yang khusus. Jika kunci objek yang sama boleh ditulis ganti selepas itu, rekod AVAILABLE mungkin merujuk kepada kandungan yang tidak pernah diimbas. Keputusan mesti terikat kepada versi objek atau cincangan kandungan yang tidak boleh diubah (immutable), dan penerbitan mestilah bersyarat.

Kelima, adakah mereka memasukkan pengambilan semula dalam model ancaman? Kunci rawak mengurangkan kebolehtekaan tetapi tidak menggantikan kebenaran penyewa dan objek. Muat turun memerlukan pengendali terkawal atau URL bertandatangan jangka pendek, pengepala respons yang selamat, origin yang diasingkan dan dasar caching yang disengajakan.

Soalan Penjelasan Sebelum Menjawab

• Bagaimanakah fail akan digunakan? Muat turun sahaja, pratonton penyemak imbas, pengekstrakan teks, penjanaan lakaran kecil (thumbnail) dan pemprosesan pihak ketiga mempunyai risiko yang berbeza. Setiap penghurai tambahan menambah permukaan serangan.
• Adakah tiga format tersebut mencukupi? Senario ini boleh menolak ZIP, Office dan setiap format lain. Menyokong arkib memerlukan had pada kedalaman, bilangan ahli, saiz yang dikembangkan dan nisbah pemampatan.
• Bagaimanakah pengguna mengesahkan identiti? Pengesahan kuki memperkenalkan kawalan CSRF. Token pembawa (bearer token) masih memerlukan kawalan CORS, skop dan kebocoran yang betul.
• Adakah muat naik terus ke storan objek diperlukan? API boleh menstrim fail kecil. Pada konkurensi yang lebih tinggi, ia boleh mengeluarkan kelayakan jangka pendek yang diskopkan kepada satu objek kuarantin dan mengesahkan objek sebenar selepas muat naik.
• Siapa yang boleh memuat naik, memeriksa status, memuat turun dan memadam? Tentukan peranan penyewa, pemilikan objek dan keperluan audit secara berasingan; hanya memeriksa sama ada pengguna telah log masuk adalah tidak mencukupi.
• Apakah SLA pengimbasan? Tentukan masa menunggu, bilangan percubaan semula, tingkah laku fail-closed dan keadaan yang ditunjukkan kepada pengguna semasa gangguan.
• Adakah terdapat keperluan pematuhan atau pemastautinan data? Kunci penyulitan, pengekalan, rekod audit, pemadaman dan pembersihan sandaran mungkin dikekang.
• Apakah yang membentuk kejayaan? Bait disimpan, imbasan lulus dan muat turun yang dibenarkan ialah tiga peristiwa penting yang berhak mendapat semantik API yang berasingan.

Rangka Kerja Jawapan 30 Saat

"Saya akan mulakan dengan tiga invarian: fail yang belum diimbas wujud hanya dalam kuarantin; pelayan menjana kunci storan manakala nama fail asal kekal sebagai metadata terhad; dan setiap muat turun melakukan kebenaran penyewa dan objek. Kitaran hayatnya ialah PENDING_UPLOAD → QUARANTINED → SCANNING → AVAILABLE/REJECTED/FAILED.

Semasa membuat muat naik, perkhidmatan menyemak peranan pengguna, kuota, format yang dibenarkan dan had 20 MiB, kemudian menjana kunci objek yang tidak boleh diteka dan tidak boleh ditulis ganti. Bait distrim ke dalam storan kuarantin bukan boleh laku (non-executable) dan bukan awam. Pelayan menyemak saiz sebenar, sambungan fail yang dinormalkan, tandatangan fail dan output penghurai yang dikekang, kemudian pekerja (worker) yang diasingkan mengimbas untuk mengesan perisian hasad. Keputusan itu mengikat kepada versi objek atau SHA-256, dan penerbitan berjaya hanya sementara nilai tersebut masih sepadan.

Untuk muat turun, perkhidmatan menyemak semula kebenaran penyewa dan objek, kemudian mengembalikan URL bertandatangan jangka pendek atau menstrim objek dengan Content-Disposition: attachment, jenis selamat yang tepat dan X-Content-Type-Options: nosniff. Kegagalan pengimbas membiarkan objek tidak tersedia dan mencetuskan percubaan semula terhad. Kuota, had kadar, konkurensi, tamat masa dan pembersihan kitaran hayat mengekang sumber. Saya akan mengesahkan reka bentuk dengan pemalsuan jenis, nama fail yang berniat jahat, sampel perisian hasad ujian, penstriman bersaiz besar, pelengkapan pendua, penggantian objek dan akses rentas penyewa."

Penyelaman Mendalam Langkah Demi Langkah

Langkah 1: Tentukan sempadan kepercayaan dan invarian keselamatan

Klien mengawal setiap bait multipart, nama fail, Content-Type, saiz yang diisytiharkan dan urutan permintaan. Get laluan API, perkhidmatan aplikasi, peristiwa storan objek dan baris gilir imbasan juga boleh menduplikasi, melengahkan atau menyusun semula kerja. Bina reka bentuk di sekitar invarian ini:

1. Objek kuarantin tidak mempunyai akses baca awam dan tidak boleh dilaksanakan oleh pelayan web.
2. Hanya objek AVAILABLE yang dibenarkan boleh dimuat turun.
3. tenant_id rekod perniagaan datang daripada konteks yang disahkan, bukan medan permintaan yang dibekalkan secara bebas.
4. Nama fail asal tidak pernah mengambil bahagian dalam pembinaan laluan atau carian objek.
5. Keputusan keselamatan mengikat kepada bait yang tidak boleh diubah; penerbitan tidak boleh memindahkan keputusan itu kepada versi lain.
6. Pengecualian, tamat masa atau hasil yang tidak pasti sentiasa fail-closed.

Merawakkan nama fail dan merahsiakan objek menyelesaikan masalah yang berasingan. Kunci objek rawak menghalang penulisan ganti, manipulasi laluan dan tekaan mudah. Kebenaran dan storan peribadi memberikan kerahsiaan. Reka bentuk memerlukan kedua-duanya.

Langkah 2: Pisahkan penerimaan daripada ketersediaan dengan mesin keadaan

Mesin keadaan minimum ialah:

PENDING_UPLOAD
  ├─ bytes verified ─> QUARANTINED ─> SCANNING
  │                                      ├─ safe ─> AVAILABLE
  │                                      ├─ malicious/invalid ─> REJECTED
  │                                      └─ scanner unavailable ─> FAILED
  └─ expired/abandoned ─> EXPIRED

POST /uploads mencipta sesi dan mengembalikan upload_id. Untuk muat naik terus, ia juga mengembalikan kelayakan jangka pendek yang hanya boleh menulis objek kuarantin yang ditetapkan. POST /uploads/{id}/complete mencetuskan pengesahan dan pengimbasan yang dipercayai, jadi 202 Accepted adalah sesuai. GET /uploads/{id} melaporkan status. Titik masuk muat turun muncul hanya untuk AVAILABLE.

Setiap peralihan menggunakan syarat pangkalan data. Sebagai contoh, hanya rekod yang sedang berada dalam QUARANTINED boleh memasuki SCANNING. Oleh itu, penghantaran baris gilir pendua atau panggilan complete yang berulang menggunakan peralihan yang sama paling banyak sekali. FAILED bermaksud kegagalan pemprosesan teknikal; REJECTED bermakna fail atau dasar adalah tidak sah. Menggabungkannya ke dalam satu ralat yang samar melemahkan pemulihan dan kebolehaupayaan audit.

Langkah 3: Terima bait dengan selamat dan hadkan sumber

Semasa penciptaan sesi, semak kebenaran muat naik, baki kuota penyewa, kadar pengguna dan format perniagaan yang diminta. Jana upload_id rawak dan kunci objek seperti quarantine/{tenant-id}/{uuid}. Normalkan nama fail asal untuk panjang, aksara kawalan dan Unicode, kemudian simpannya hanya sebagai metadata paparan.

Apabila API memproksikan muat naik, strimkan bait ke dalam kuarantin dan kiranya semasa membaca. Batalkan serta-merta selepas 20 MiB dan bukannya menimbal seluruh fail dalam memori proses. Dengan muat naik terus, skopkan tandatangan seketat yang dibenarkan oleh sistem storan mengikut kaedah, kunci objek, tamat tempoh dan saiz. Selepas itu, perkhidmatan yang dipercayai masih membaca metadata objek dan mengesahkan panjang sebenar, versi dan pemilikan. Ia tidak pernah mempercayai permintaan lengkap klien.

Baldi atau direktori kuarantin adalah peribadi secara lalai, bukan boleh laku, diasingkan daripada origin aplikasi utama dan diakses melalui kelayakan hak istimewa paling rendah (least-privilege). Sesi yang telah tamat tempoh, muat naik yang ditinggalkan dan keadaan imbasan terminal memerlukan pembersihan kitaran hayat supaya objek terbiar (orphaned objects) tidak menggunakan kuota selama-lamanya.

Langkah 4: Gabungkan pengesahan jenis, penghuraian dan pengimbasan kandungan berniat jahat

Pemeriksaan boleh dijalankan dari yang murah ke yang mahal, tetapi tiada satu lapisan pun boleh menghasilkan AVAILABLE:

1. Gunakan senarai dibenarkan PDF, JPEG dan PNG pada sambungan fail yang dinormalkan.
2. Layan Content-Type klien sebagai pembayang. Tolak ketidakpadanan yang jelas, tetapi jangan sekali-kali menggunakannya sebagai bukti.
3. Periksa tandatangan dan struktur lengkap supaya awalan ajaib (magic prefix) yang sah tidak mencukupi dengan sendirinya.
4. Gunakan penghurai yang dikemas kini dan dikekang untuk mengesahkan bahawa keseluruhan fail boleh dihuraikan.
5. Jalankan pengimbasan perisian hasad dalam pekerja yang diasingkan dan rekod versi enjin serta peraturan.
6. Kodkan semula imej yang dinyahkod, dan pertimbangkan pelucutan dan pembinaan semula kandungan untuk PDF apabila model risiko mewajarkannya.

Pengimbas dan penghurai memproses bait yang dikawal oleh penyerang. Jalankannya dalam kotak pasir (sandbox) dengan CPU, memori, cakera sementara, masa dan akses rangkaian yang terhad. Senario ini menolak arkib, yang menghapuskan cabang bom penyahmampatan (decompression-bomb), penyarangan (nesting) dan lintasan laluan arkib. Antivirus tidak membuktikan keselamatan mutlak, jadi pengasingan storan, pengambilan selamat dan penghuraian minimum kekal perlu.

Langkah 5: Ikat keputusan kepada bait yang tidak boleh diubah sebelum menerbitkan

Tugasan imbasan membaca version_id kuarantin yang tidak boleh diubah dan mengira SHA-256. Hasilnya merangkumi sekurang-kurangnya upload_id, versi objek, cincangan, saiz sebenar, jenis yang dikesan, versi enjin pengimbasan dan keputusan.

Penerbitan melaksanakan peralihan pangkalan data bersyarat. Rekod mesti masih SCANNING, dan versi objek serta cincangannya mesti masih sama dengan input imbasan sebelum ia boleh menjadi AVAILABLE. Storan objek juga menghalang versi tersebut daripada ditulis ganti. Jika sistem menyalin fail ke kawasan yang diluluskan, sasaran mendapat kunci rawak baharu dan operasi penyalinan mengenal pasti versi sumber yang tepat. Sebarang ketidakpadanan menyebabkan kuarantin semula atau penolakan dan bukannya menggunakan semula keputusan lama.

Ikatan ini menutup jurang time-of-check-to-time-of-use. Penyerang tidak boleh memuat naik bait yang selamat, mendapatkan hasil yang lulus dan kemudian menggantikan kunci yang sama dengan bait berniat jahat. Tanpa pemversian storan, gunakan kunci objek tulis sekali (write-once) atau storan beralamat kandungan (content-addressed storage), dan biarkan rekod perniagaan menunjuk hanya kepada objek akhir yang tidak boleh diubah.

Langkah 6: Benarkan muat turun dan kawal tafsiran penyemak imbas

GET /files/{id}/download memperoleh penyewa semasa daripada pengesahan, kemudian menyemak pemilikan objek, peranan, keadaan pemadaman dan status AVAILABLE. UUID tidak membuang mana-mana pemeriksaan tersebut. Selepas kebenaran, aplikasi boleh menstrim objek atau mengeluarkan URL bertandatangan jangka pendek yang terikat kepada satu objek dan operasi.

Untuk lampiran yang tidak memerlukan pratonton, kembalikan Content-Disposition: attachment, nama fail paparan yang dikodkan dengan selamat, jenis media yang disahkan oleh pelayan dan X-Content-Type-Options: nosniff. Mengasingkan origin fail daripada domain kuki aplikasi utama mengurangkan kemungkinan kandungan aktif mempengaruhi sesi utama. Pastikan URL bertandatangan berjangka pendek kerana menukar kebenaran pengguna biasanya tidak membatalkan URL yang telah dikeluarkan serta-merta.

Laluan pengambilan juga memerlukan kawalan kadar dan lebar jalur, peristiwa audit kebenaran dan keputusan eksplisit sama ada proksi atau cache boleh mengekalkan respons peribadi. Log mengandungi ID objek, penyewa, pelaku (actor) dan hasil, tetapi bukan kandungan fail atau URL bertandatangan yang boleh digunakan semula.

Langkah 7: Reka bentuk kegagalan, keidempotanan, kuota dan kebolehcerapan

Apabila pengimbasan tamat masa atau tidak tersedia, fail kekal tidak tersedia. Pekerja boleh mencuba semula beberapa kali terhad dengan backoff. Percubaan semula yang habis memasuki FAILED untuk pemulihan manual atau automatik yang terkawal. Hasil berniat jahat atau tidak sah dari segi struktur yang pasti memasuki REJECTED, dan bait kuarantin dipadamkan mengikut dasar pengekalan.

Titik akhir create boleh menerima kunci keidempotanan (idempotency key) supaya tamat masa klien tidak mencipta beberapa sesi. Pelengkapan, penggunaan imbasan dan pemadaman menggunakan peralihan keadaan bersyarat untuk keidempotanan. Had konkurensi meliputi muat naik bagi setiap pengguna, jumlah bait penyewa, saiz bagi setiap fail, kedalaman baris gilir dan slot imbasan bagi setiap penyewa supaya satu penyewa tidak boleh memonopoli kapasiti global.

Metrik yang berguna termasuk masa dalam setiap keadaan, bait kuarantin, sesi tamat tempoh, kadar lulus/tolak/gagal imbasan, percubaan semula, usia baris gilir, tamat masa penghurai, penafian rentas penyewa dan kebenaran muat turun yang gagal. Peristiwa audit merekodkan peralihan, versi objek, cincangan, dasar dan versi pengimbas, membolehkan pengendali menjawab dengan tepat bait mana yang dinilai di bawah peraturan yang mana.

Langkah 8: Sahkan laluan lengkap dengan matriks musuh (adversarial matrix)

Sekurang-kurangnya, uji:

1. .jpg.php, huruf besar-kecil bercampur, bait nol dan nama fail Unicode yang bersaiz besar;
2. Content-Type yang dipalsukan, awalan yang sah dengan bahagian ekor yang berniat jahat, PDF yang rosak dan fail poliglot;
3. fail ujian EICAR dalam persekitaran yang selamat, serta sampel yang mencapai tamat masa penghurai atau had sumber;
4. tepat 20 MiB, lebih satu bait, panjang tiada, penstriman perlahan dan banyak muat naik serentak;
5. kunci keidempotanan yang sama, panggilan complete serentak, mesej baris gilir pendua dan hasil imbasan lapuk;
6. percubaan penggantian objek semasa pengimbasan, membuktikan bahawa ketidakpadanan versi atau cincangan tidak boleh menerbitkan fail;
7. penyewa lain yang membaca status, memuat turun atau memadam objek, dengan setiap permintaan dinafikan;
8. gangguan pengimbas, tamat masa tugasan, permulaan semula aplikasi dan pembersihan objek terbiar;
9. tingkah laku muat turun untuk attachment, jenis media, nosniff, caching dan tamat tempoh URL bertandatangan.

Kelulusan memerlukan keselamatan dan ketepatan perniagaan secara serentak: fail yang ditolak tidak pernah menerima laluan muat turun, fail selamat akhirnya menjadi tersedia, percubaan semula tidak mencipta rekod pendua, permintaan tanpa kebenaran tidak membocorkan data, kegagalan kekal closed, penggunaan sumber kekal terhad dan jejak audit membina semula keseluruhan rantaian keputusan.

Contoh Jawapan Mantap

"Saya akan membahagikan muat naik kepada peringkat kuarantin, keputusan dan penerbitan, dengan invarian bahawa pengguna perniagaan tidak boleh membaca bait yang belum melepasi keputusan. Apabila membuat sesi, saya memperoleh tenant_id daripada pengesahan, menyemak peranan, had 20 MiB, kuota penyewa dan senarai dibenarkan PDF/JPEG/PNG, serta menjana kunci kuarantin rawak yang tidak boleh ditulis ganti. Nama fail asal kekal sebagai metadata paparan yang dinormalkan dan dihadkan panjangnya.

Bait sama ada distrim melalui API atau menggunakan kelayakan jangka pendek yang diskopkan kepada kunci kuarantin tersebut. Semasa pelengkapan, pelayan mengesahkan saiz sebenar, versi objek dan pemilikan, mengalihkan rekod secara bersyarat daripada PENDING_UPLOAD kepada QUARANTINED dan mengimbas secara tak segerak. Pengesahan menggabungkan sambungan fail, jenis yang dikesan oleh pelayan, penghuraian struktur penuh, pengimbasan perisian hasad dan pengekodan semula yang sesuai. Pengimbas berjalan dengan sumber dan akses rangkaian yang terhad.

Pengimbas membaca versi yang tidak boleh diubah dan mengira SHA-256. Rekod boleh menjadi AVAILABLE hanya jika ia masih SCANNING dan kedua-dua versi serta cincangan sepadan dengan input imbasan. Oleh itu, menggantikan fail selamat selepas imbasannya tidak boleh menggunakan semula keputusan lama. Gangguan pengimbas gagal secara closed dengan percubaan semula terhad; kandungan yang pasti berniat jahat atau tidak mematuhi piawaian menjadi REJECTED.

Setiap muat turun menyemak penyewa, kebenaran objek dan status AVAILABLE sebelum menstrim atau mengeluarkan URL jangka pendek. Lampiran menggunakan origin yang diasingkan, Content-Disposition: attachment dan X-Content-Type-Options: nosniff. Saya kemudiannya akan menguji pemalsuan jenis, EICAR, penstriman bersaiz besar, pelengkapan pendua, pertikaian penggantian objek, bacaan rentas penyewa dan gangguan pengimbas sambil memantau tempoh keadaan, bait kuarantin, usia baris gilir dan versi pengimbas."

Kesilapan Biasa

• Hanya menyemak sambungan fail → sambungan berganda, perubahan huruf besar-kecil dan kandungan yang menyamar memintasnya → gabungkan senarai dibenarkan perniagaan, penormalan, tandatangan, penghuraian struktur dan pengimbasan.
• Mempercayai Content-Type → klien boleh memilih pengepala permintaan → gunakannya hanya untuk penapisan awal dan kesan jenis akhir pada pelayan.
• Menggunakan nama fail asal sebagai laluan → lintasan laluan, penulisan ganti dan pepijat penormalan sistem fail menjadi mungkin → jana kunci objek rawak dan simpan nama itu hanya sebagai metadata terhad.
• Menjadikan bait yang disimpan boleh dimuat turun serta-merta → bait berniat jahat terdedah sebelum pengimbasan selesai → gunakan kuarantin dan jadikan AVAILABLE sebagai satu-satunya syarat penerbitan.
• Mendakwa kelulusan antivirus menjamin keselamatan → sampel baharu, pepijat penghurai dan kandungan aktif masih mungkin berlaku → kekalkan pengasingan, penghuraian minimum, pengepala selamat dan kebenaran.
• Mengimbas kunci yang boleh ditulis ganti → hasil yang lulus mungkin terpakai pada bait penggantian yang kemudian → ikat versi atau cincangan kandungan yang tidak boleh diubah dan terbitkan secara bersyarat.
• Memperlakukan UUID sebagai kebenaran → ID objek yang bocor mungkin membolehkan bacaan rentas penyewa → lakukan kebenaran objek untuk status, muat turun dan pemadaman.
• Mempercayai pelengkapan klien selepas muat naik terus → klien boleh berbohong tentang saiz, jenis atau pemilikan → baca metadata objek yang dipercayai dan bukti bait pada pelayan.
• Gagal secara fail-open semasa gangguan pengimbas → kegagalan infrastruktur menjadi pintasan keselamatan → gagal secara fail-closed, cuba semula dalam had dan dedahkan keadaan pemprosesan yang tepat.
• Mengehadkan saiz bagi setiap fail sahaja → banyak fail yang sah secara individu boleh menghabiskan storan dan pengimbasan → kuat kuasakan kuota penyewa, kadar, konkurensi dan tekanan balik (backpressure) baris gilir.
• Memaparkan fail sebaris sewenang-wenangnya pada origin utama → tafsiran penyemak imbas dan kandungan aktif boleh mempengaruhi sesi utama → jadikan muat turun lampiran sebagai lalai dan asingkan origin fail.

Soalan Susulan dan Maklum Balas

Susulan 1: Mengapakah perlu menghuraikan struktur lengkap apabila anda sudah menyemak bait ajaib?

Tandatangan biasanya hanya meliputi beberapa bait terawal. Penyerang boleh meletakkan format lain selepas pengepala yang sah atau membina fail yang diterima oleh berbilang penghurai. Penghuraian struktur penuh menyemak panjang dalaman, perhubungan dan penanda penamat. Penghurai masih memproses input yang tidak dipercayai, jadi ia mesti sentiasa dikemas kini, dihadkan sumber dan diasingkan.

Susulan 2: Adakah muat naik terus ke storan objek memintas keselamatan backend?

Ia hanya mengubah laluan pemindahan bait. Backend masih mencipta sesi jangka pendek yang terikat kepada penyewa dan kunci objek, dan kelayakan hanya menulis ke kuarantin. Backend kemudian mengesahkan objek sebenar, saiz, versi dan cincangan sebelum mengimbas. Objek tidak mempunyai kebenaran baca sebelum AVAILABLE, jadi muat naik terus tidak boleh menerbitkannya secara langsung.

Susulan 3: Apakah pengalaman pengguna yang sepatutnya semasa gangguan pengimbas?

Pelengkapan mengembalikan keadaan pemprosesan, manakala status melaporkan sama ada pemeriksaan keselamatan diteruskan atau pemprosesan gagal dan boleh dicuba semula. Sistem mencuba semula dengan backoff terhad dan memantau usia baris gilir. Selepas ambang tercapai, rekod memasuki FAILED dan kekal tidak tersedia. Pemulihan mencuba semula versi tidak boleh diubah yang sama melalui laluan terkawal; ketersediaan tidak pernah melangkau keputusan keselamatan.

Susulan 4: Mengapakah muat turun masih memerlukan attachment dan nosniff?

Kebenaran menentukan siapa yang menerima bait. Pengepala respons mempengaruhi cara penyemak imbas mentafsirkannya. attachment mengutamakan muat turun, dan nosniff menghalang penyemak imbas daripada mengatasi jenis yang diisytiharkan oleh pelayan melalui content sniffing. Origin fail yang diasingkan seterusnya mengehadkan akses kandungan aktif kepada kuki dan konteks skrip aplikasi utama.

Susulan 5: Apakah kawalan yang diperlukan jika ZIP dibenarkan?

Periksa setiap laluan ahli dalam kotak pasir yang diasingkan, tolak laluan mutlak dan .., serta hadkan kedalaman penyarangan, bilangan ahli, saiz individu, jumlah saiz yang dikembangkan, nisbah pemampatan, CPU dan masa. Jalankan pemeriksaan jenis dan kandungan berniat jahat sekali lagi untuk setiap ahli yang diekstrak. Senario ini tidak mempunyai keperluan ZIP, jadi menolaknya memberikan permukaan serangan yang lebih kecil.

Susulan 6: Bagaimanakah anda membuktikan bahawa race condition tidak mencemari keputusan tersebut?

Rekod versi input dan SHA-256 yang tidak boleh diubah dalam tugasan imbasan. Penerbitan menggunakan kemas kini pangkalan data bersyarat yang memerlukan rekod semasa kekal SCANNING dengan versi dan cincangan yang tepat itu. Ujian menulis ganti objek logik semasa pengimbasan dan memberikan hasil yang lapuk; penerbitan mesti gagal. Peristiwa audit menghubungkan versi input, keputusan dan objek akhir yang diluluskan.