Prompt dan konteks
Sebuah produk SaaS sedang menambah teks kaya karangan pengguna pada ulasan, pangkalan pengetahuan dan templat. Pasukan ini mahukan HTML Sanitizer API natif pelayar untuk mengurangkan peraturan penapisan tersuai, tetapi API tersebut tidak tersedia dalam beberapa pelayar utama. Buat keputusan sama ada perlu menggunakannya dan jelaskan kompromi keselamatan, pengalaman, keserasian dan operasi.
Perkara yang dinilai oleh penemu duga
- Sama ada anda mentakrifkan model ancaman, kandungan yang dibenarkan dan sempadan kepercayaan pelayan terlebih dahulu.
- Sama ada anda membezakan
setHTML(), konfigurasi Sanitizer tersuai,setHTMLUnsafe()dan Trusted Types. - Sama ada liputan pelayar, pelaksanaan sandaran (fallback), ketekalan kandungan dan kos migrasi dikira secara kuantitatif.
- Sama ada metrik berperingkat mengesahkan risiko XSS, kejayaan penyuntingan, prestasi dan kesediaan pengunduran (rollback).
Soalan penjelasan untuk ditanya
Sahkan sama ada teks kaya memerlukan pautan, imej, jadual, benaman (embeds), gaya atau atribut tersuai; sama ada kandungan dirender di sisi pelayan, dieksport ke e-mel, diindeks untuk carian atau digunakan semula pada klien lain. Sahkan pelayar yang disokong, pensanitasi sedia ada, keperluan pematuhan, permukaan serangan dan penurunan kualiti ciri yang boleh diterima.
Jawapan 30 saat
Saya akan menggunakan sandaran bertingkat keupayaan, diutamakan natif dan disahkan oleh pelayan daripada menggantikan pensanitasi sedia ada secara serentak. setHTML() natif mengikuti laluan sanitasi yang selamat, tetapi liputannya terhad, jadi pelayar yang tidak disokong menggunakan dasar setara yang telah diaudit. Mulakan dengan permukaan berkerumitan rendah seperti ulasan dan ukur sekatan muatan berbahaya, ketepatan kandungan, kejayaan penyuntingan, pendam (latency) dan pengedaran pelayar. Pelayan masih mensanitasi dan mengekod pada sempadan output; Trusted Types menambah kekangan di sekitar sink suntikan.
Perbincangan mendalam langkah demi langkah
1. Takrifkan nilai pengguna dan model ancaman
Nilai pengguna ialah kandungan berformat yang boleh dipercayai; risiko utama ialah menghantar HTML yang tidak dipercayai ke DOM atau sink pemaparan lain. Takrifkan elemen, atribut, skema URL dan sumber media yang dibenarkan sebelum memutuskan keupayaan mana yang mewajarkan kos penyelenggaraan.
2. Asingkan keupayaan API natif
Element.setHTML() dan Document.parseHTML() menggunakan lalai sanitasi yang selamat; konfigurasi tersuai boleh mengetatkan senarai kebenaran (allowlist). setHTMLUnsafe() adalah untuk kes yang memerlukan struktur khas, tetapi memerlukan konfigurasi dan semakan yang ketat. Spesifikasi memerlukan kaedah selamat untuk membuang penanda yang mampu menjalankan skrip, jadi API ini bukanlah kebenaran untuk sebarang HTML sewenang-wenangnya.
3. Nilaikan liputan dan sandaran (fallback)
MDN melabelkan HTML Sanitizer API sebagai Ketersediaan terhad (Limited availability). Kesan ciri pada laluan natif dan pilih laluan pelayan atau perpustakaan yang diaudit apabila tidak disokong. Kongsi senarai kebenaran, lekapan ujian (test fixtures) dan rekod versi merentasi kedua-dua laluan. Sandaran harus menggugurkan keupayaan berisiko tinggi dan bukannya melonggarkan dasar demi kesamaan visual.
4. Reka kontrak kandungan rentas klien
Simpan input asal dan perwakilan selamat yang dinormalkan, mentakrifkan perwakilan mana yang berfungsi untuk penyuntingan, pratonton, e-mel, carian dan eksport. Sahkan semula pada setiap sempadan output pelayan. Sanitasi sisi klien mengurangkan risiko suntikan DOM; ia tidak menggantikan kebenaran, penyimpanan atau dasar pemaparan pelayan.
5. Reka pelancaran berperingkat dan metrik
Dayakan satu jenis kandungan untuk kohort penyewa yang kecil dan bandingkan penemuan natif dan sandaran. Jejaki sekatan muatan berbahaya, rayuan penyingkiran yang tidak diingini, kejayaan penghantaran suntingan, kependaman paparan pertama dan input, liputan pelayar, ketekalan versi dasar dan peristiwa keselamatan.
6. Kendalikan Trusted Types dan operasi
Dayakan pelaporan atau penguatkuasaan Trusted Types untuk sink berisiko tinggi, memerlukan fungsi dasar mengembalikan jenis yang disahkan. Wujudkan kelulusan perubahan peraturan, regresi lekapan berniat jahat, pemprosesan semula kandungan dan pengunduran kecemasan. Jangan biarkan kemas kini pelayar mengubah dasar keselamatan secara senyap.
Contoh jawapan berkualiti tinggi
Saya akan meletakkan keupayaan kandungan, model ancaman dan persekitaran masa larian dalam tiga jadual keputusan. HTML Sanitizer API berguna untuk pembersihan sisi klien yang tersusun sebelum HTML yang tidak dipercayai memasuki DOM; setHTML() mempunyai tetapan lalai yang selamat dan spesifikasi WHATWG mengurangkan kemungkinan penanda yang mampu menjalankan skrip dikekalkan, tetapi MDN masih menandakan liputan sebagai terhad. Pelan produk adalah mengutamakan natif dengan sandaran perpustakaan matang atau dasar pelayan, berkongsi elemen, atribut, skema dan lekapan yang dibenarkan. Pelayan menyimpan perwakilan asal dan selamat serta mengesahkan secara berasingan untuk halaman, e-mel, carian dan eksport; pembersihan klien tidak menyediakan kebenaran atau perlindungan XSS yang lengkap. Lancarkan ulasan terlebih dahulu dan ukur sekatan, ketepatan, kejayaan penghantaran, prestasi, pengedaran pelayar dan peristiwa keselamatan. Gunakan setHTMLUnsafe() hanya untuk keperluan struktur yang wajar dengan konfigurasi ketat, Trusted Types dan semakan. Mainkan semula lekapan berniat jahat yang lalu selepas kemas kini dasar dan undurkan serta-merta sekiranya berlaku regresi.
Kesilapan lazim
- Menganggap API pelayar natif menyingkirkan keperluan untuk sanitasi sisi pelayan.
- Menguji demo sahaja dan mengabaikan pelayar yang tidak disokong serta ketekalan sandaran.
- Melonggarkan konfigurasi
setHTMLUnsafe()untuk mengekalkan benaman sewenang-wenangnya. - Menggantikan metrik ketepatan, penyingkiran yang tidak diingini dan keselamatan dengan satu nombor kejayaan penapis.
- Menganggap Trusted Types sebagai pensanitasi, atau pensanitasi sebagai kebenaran (authorization).
Soalan susulan dan respons
Mengapa tidak menukar setiap permukaan kepada API natif dengan serta-merta?
Liputan, keupayaan kandungan dan migrasi data legasi masih tidak pasti. Pelancaran boleh balik dengan sandaran mengesahkan pengedaran pelayar dan kandungan sebenar terlebih dahulu.
Bagaimana jika dasar natif dan pelayan berbeza?
Kongsi senarai kebenaran dan lekapan berniat jahat yang berversi, dengan pelayan sebagai sempadan akhir. Rekod versi dasar dan sampel apabila klien mendapati perbezaan; jangan sesekali melonggarkan peraturan secara senyap.
Bilakah penguatkuasaan Trusted Types berbaloi untuk didayakan?
Selepas sink utama diinventori, fungsi dasar dan komponen pihak ketiga dimigrasikan, dan mod laporan sahaja menunjukkan positif palsu yang rendah, dayakan penguatkuasaan secara berperingkat.