Kehendak soalan dan skop
Semak seni bina di mana pelayar mengakses aplikasi web berbilang penyewa (multi-tenant). Bagaimanakah anda melukis sempadan dan aliran data, mengenal pasti aset dan sumber ancaman, membezakan ancaman sasaran, pelaksanaan, dan luaran, serta mengubah tindak balas menjadi batas kekal keselamatan yang boleh disahkan?
W3C Security Interest Group telah menerbitkan Threat Model for the Web Group Note Draft pada 26 Mei 2026. Ia bersifat bermaklumat dan bukan normatif, bertujuan untuk menyokong semakan keselamatan bagi spesifikasi Web baharu. Pandangan ringkasnya merangkumi pelayar, DNS, Web Server, pengguna dan pengendali rangkaian. Temu duga ini menguji kaedah dan rantaian bukti, bukannya hafalan draf tersebut.
Perkara yang dinilai oleh penemu duga
Penemu duga ingin melihat gambaran sistem dan aliran data sebelum senarai kerentanan; aset, pihak berkepentingan, dan sumber ancaman yang eksplisit; perbezaan antara ancaman, kerentanan, impak, dan tindak balas; serta matlamat keselamatan yang dinyatakan sebagai batas kekal (invariants) yang boleh diperiksa. Terangkan bagaimana model ini berkembang dan menyumbang kepada dokumen reka bentuk serta semakan. Jawapan yang kukuh menyatakan sempadan abstraksi, andaian penyerang yang tidak dimodelkan, dan bagaimana kebergantungan luar skop diserah milik.
Soalan penjelasan sebelum menjawab
- Adakah kita menyemak platform pelayar, satu aplikasi web, atau Web API baharu antara kedua-duanya?
- Adakah kelayakan, data pengguna, kod, sesi, metadata rangkaian, dan ketersediaan semuanya dalam skop?
- Adakah aliran merangkumi skrip pihak ketiga, CDN, DNS, penyedia identiti, dan permintaan rentas tapak (cross-site)?
- Adakah ini semakan seni bina, semakan keselamatan pra-keluaran, atau semakan perubahan operasi?
- Kebergantungan dan ancaman luaran manakah yang secara eksplisit berada di luar skop, dan siapakah pemilik tindakan susulan tersebut?
Rangka kerja jawapan 30 saat
“Saya bermula dengan rajah aliran data yang mempunyai ID unik untuk komponen, stor simpanan, aliran, dan pihak berkepentingan. Saya menyenaraikan aset dan sumber ancaman, kemudian merekodkan prasyarat, aliran yang terjejas, impak, kawalan sedia ada, dan risiko sisa bagi setiap ancaman. Saya mengelaskannya sebagai ancaman sasaran, ancaman pelaksanaan, atau kebergantungan luaran. Setiap tindak balas menjadi batas kekal keselamatan dengan bukti ujian atau audit, pemilik, dan pencetus kemas kini. Model ini bermula dengan kes penggunaan dan berkembang bersama reka bentuk supaya satu versi sedia ada sebelum semakan keselamatan rasmi.”
Analisis mendalam langkah demi langkah
1. Lukis sempadan sistem terlebih dahulu
Mulakan dengan senario boleh guna yang minimum: proses dan storan pelayar, perkhidmatan DNS, Web Server, pengguna, pentadbir tapak, dan pengendali rangkaian. Berikan setiap komponen ID unik yang pendek dan glosari huraian yang menerangkan tanggungjawab serta sempadan kepercayaannya (trust boundary). Jika menyemak API baharu, letakkan input, output, kebenaran, dan kebergantungannya dalam gambaran ini dan bukannya mencipta rajah yang terasing.
2. Senaraikan aset dan pihak berkepentingan
Aset mungkin termasuk kelayakan, token sesi, kandungan pengguna, skrip, identiti sumber, hasil DNS, ketersediaan, dan metadata privasi. Pihak berkepentingan termasuk pengguna akhir, pengendali tapak, pengendali rangkaian, penyedia aplikasi, dan pegawai awam. Asingkan pihak yang terjejas daripada pihak yang mungkin menyerang; menganggap pengguna hanya sebagai aset akan menyembunyikan keputusan keselamatan yang penting.
3. Rekod sumber ancaman dan ancaman tahap tinggi
Bagi setiap ancaman, nyatakan sumbernya, aset sasaran, laluan serangan, dan impaknya. Penyamaran (spoofing), pengubahan (tampering), pendedahan maklumat, penafian perkhidmatan, dan pintasan pembenaran boleh menyusun senarai tersebut, tetapi setiap entri mesti dipetakan kembali kepada aliran yang konkrit. Kelaskan ancaman sebagai ancaman sasaran yang ditangani oleh spesifikasi, ancaman pelaksanaan yang diketahui oleh pelaksana tetapi tidak sesuai untuk kekangan normatif, atau ancaman luaran daripada kebergantungan dan pelaksanaan.
4. Ubah tindak balas menjadi batas kekal (invariants)
Batas kekal keselamatan ialah syarat yang mesti dipenuhi bagi setiap pelaksanaan yang dibenarkan, seperti "respons cross-origin tidak sekali-kali memberikan kelayakan kepada pemanggil yang tidak dibenarkan" atau "penghalaan semula (redirect) tidak boleh memintas sempadan script-origin dan kebenaran." Ikatkan setiap batas kekal kepada kawalan dan bukti ujian, log, atau audit. Tandakan sama ada ia jaminan spesifikasi, jaminan pelaksanaan, atau andaian penggunaan.
component/flow -> asset -> threat source -> impact
-> invariant -> control -> evidence -> owner5. Kendalikan kebergantungan dan ancaman luaran
Web bergantung pada DNS, TLS, HTTP, sijil, penghalaan, skrip, dan lapisan lain. Jangan berpura-pura bahawa satu model merangkumi setiap kebergantungan. Senaraikan andaian yang diwarisi dan titik serah milik. Pemalsuan DNS, pengubahan sumber, atau pengawasan rangkaian mungkin berada di luar spesifikasi semasa, tetapi rujuk model ancaman teknologi berkaitan dan rekodkan andaian yang anda harapkan.
6. Pastikan model sejajar dengan kitaran hayat
Mulakan model ancaman dengan kes penggunaan, dokumen penerangan (explainers), dan draf reka bentuk pertama, kemudian kemas kini apabila ciri dan aliran berubah. Pencetus kemas kini termasuk titik masuk baharu, perubahan kebenaran, kebergantungan baharu, perubahan sempadan proses pelayar, dan insiden sebenar. Versikan model, nota semakan, dan perbezaan (diffs) supaya pasukan dapat mengetahui sama ada risiko telah ditambah, ditutup, atau diklasifikasikan semula. Versi yang lengkap perlu wujud sebelum semakan keselamatan mendatar rasmi dijalankan.
7. Buktikan bahawa tindak balas berfungsi
Gunakan ujian unit dan integrasi, ujian keselamatan pelayar, simulasi serangan, semakan konfigurasi, dan pertanyaan log. Bagi batas kekal yang tidak dapat diuji secara langsung, sediakan rasional yang boleh diaudit, risiko sisa, dan pemilik yang menerima risiko tersebut. “Tiada kerentanan ditemui” bukan bukti; nyatakan skop pemerhatian, syarat ujian, dan kawasan yang tidak diliputi.
Contoh jawapan berkualiti tinggi
Saya akan mentakrifkan senario akses pelayar yang minimum dengan ID unik untuk proses dan storan pelayar, DNS, Web Server, pengguna, dan pengendali rangkaian, serta menyediakan glosari bagi setiap aliran. Saya akan menyenaraikan kelayakan, sesi, kandungan pengguna, skrip, hasil resolusi, dan metadata privasi sebagai aset. Setiap ancaman akan merangkumi sumber, prasyarat, aliran yang terjejas, dan impak, kemudian diklasifikasikan sebagai ancaman sasaran, pelaksanaan, atau kebergantungan luaran. Setiap tindak balas akan menjadi batas kekal yang boleh diperiksa dan terikat kepada kawalan, ujian, log, atau bukti audit serta pemilik. Model ini akan bermula dengan kes penggunaan dan draf reka bentuk pertama, dikemas kini apabila titik masuk, kebergantungan, atau kebenaran berubah, dan diberi versi sebelum semakan keselamatan. Bagi DNS, TLS, skrip, dan penghalaan, saya akan merujuk model berkaitan dan menyatakan risiko sisa secara eksplisit. Ini menjadikan semakan tersebut berguna untuk pelaksanaan dan perubahan masa hadapan.
Kesilapan lazim
- Hanya menyenaraikan nama kerentanan → tiada sempadan atau aliran → lukis komponen, aliran, dan sempadan kepercayaan terlebih dahulu.
- Mencampuradukkan ancaman, kerentanan, dan impak → tindak balas tidak dapat disahkan → rekodkan sumber, prasyarat, impak, dan kawalan secara berasingan.
- Meletakkan setiap risiko ke dalam spesifikasi semasa → skop menjadi tidak tepat → kelaskan ancaman sasaran, pelaksanaan, dan luaran.
- Mencipta satu model sahaja sebelum pelancaran → perubahan reka bentuk terlepas pandang → mulakan dengan kes penggunaan dan tentukan pencetus kemas kini.
- Menulis matlamat keselamatan sebagai slogan → tiada bukti penerimaan wujud → tulis semula sebagai batas kekal yang terikat kepada ujian, log, atau audit.
- Mengabaikan risiko sisa → keputusan tidak dapat dikesan → nyatakan kawasan yang tidak diliputi, pemilik penerima risiko, dan tindakan susulan.
Soalan susulan dan tindak balas
Mengapa tidak menyenaraikan setiap penyerang terlebih dahulu?
Mendefinisikan komponen, aset, dan aliran terlebih dahulu mengelakkan hanyutan skop (scope drift). Model penyerang boleh ditambah, tetapi tekaan mengenai motif tidak boleh menggantikan analisis sempadan dan kawalan yang boleh disahkan.
Bagaimanakah anda mengendalikan skrip pihak ketiga?
Letakkan sumber skrip, aliran pemuatan, kelayakan yang boleh diakses, dan kebenaran pelaksanaan dalam model. Tentukan sekatan sumber, pengasingan, dan batas kekal pemantauan; jika vendor memiliki kawalan, rekodkan bukti serah milik dan risiko sisa.
Bilakah kebergantungan luaran menjadi risiko projek?
Apabila andaian keselamatannya memberi kesan secara langsung kepada aset atau batas kekal dalam skop, atau projek tidak dapat mengesahkan jaminan kebergantungan tersebut, rekodkannya sebagai risiko semasa dengan mitigasi atau pemilik yang menerima risiko dan bukannya sekadar nota kaki.
Bagaimana jika model semakan keselamatan terlalu kompleks?
Kekalkan rajah minimum yang meliputi risiko utama, bahagikan perincian protokol atau pelaksanaan kepada sub-model yang dipautkan, dan kekalkan kebolehkesanan dengan ID komponen dan aliran. Jangan mengurangkan kerumitan dengan memadam sempadan yang kritikal.
Bagaimanakah anda menerangkan risiko sisa kepada product owner?
Huraikan aset yang terjejas, laluan yang munasabah, kawalan semasa, bukti ujian, dan impak perniagaan. Tawarkan pilihan berserta kos, tarikh akhir, dan pemilik penerima risiko yang jelas; elakkan dakwaan "benar-benar selamat" atau dakwaan kebarangkalian yang tidak disokong.