Gesaan dan skop
Soalan temuduga umum ini menguji sama ada anda boleh meletakkan fail awam yang kecil di dalam aliran kerja operasi keselamatan yang lengkap. Tujuannya bukan sekadar menghafal medan; ia adalah untuk menghubungkan titik masuk pelaporan, sempadan kebenaran, pemilikan tindak balas, dan janji dasar.
Perkara yang dinilai oleh penemuduga
- Sama ada anda mengetahui lokasi
/.well-known/security.txtdan medan yang diperlukan mengikut RFC 9116. - Sama ada anda boleh membezakan antara penemuan, pengesahan, pendedahan terkoordinasi (coordinated disclosure), dan tindak balas kecemasan.
- Sama ada anda mengelak daripada menerbitkan peti mel yang tidak dijaga, kunci peribadi, atau janji masa tindak balas tanpa pemilik yang jelas.
- Sama ada anda boleh mereka bentuk pemilikan on-call, tiket, penyahduplikasian (deduplication), dan kemas kini status yang membolehkan titik masuk berfungsi.
Soalan penjelasan untuk ditanya
Mula-mula sahkan domain dan produk mana yang berada dalam skop, sama ada beberapa pasukan memiliki aset tersebut, sama ada aset yang dihoskan oleh pihak ketiga diterima, siapa yang bertugas on-call untuk setiap saluran, ujian mana yang dibenarkan, dan sama ada dasar pendedahan kerentanan sudah wujud. Jelaskan juga sama ada matlamatnya hanyalah kebolehcarian (discoverability) semata-mata atau turut merangkumi ganjaran, penyerahan disulitkan, dan tarikh pendedahan terkoordinasi.
Rangka jawapan 30 saat
Saya akan menerbitkan fail teks biasa UTF-8 di /.well-known/security.txt melalui HTTPS untuk setiap aset awam. Saya akan mengekalkan Contact yang sah dan Expires pada masa hadapan, kemudian menambah Policy, Canonical, Encryption, atau Acknowledgments hanya apabila proses tersebut benar-benar wujud. Fail ini hanya membantu penyelidik mencari titik masuk; bahagian belakang masih memerlukan skop kebenaran, pemilikan on-call, tiket, penyahduplikasian, penilaian keterukan, dan komunikasi status yang selamat. Sebelum pelancaran, saya akan mengesahkan HTTPS, tempoh tamat, kebenaran pautan, dan giliran pihak yang bertanggungjawab.
Penyelesaian langkah demi langkah
1. Tentukan aset dan sempadan titik masuk
Senaraikan domain utama, domain produk, dan API berisiko tinggi yang memerlukan liputan berbanding meletakkan satu fail sahaja di laman utama pemasaran. Contact harus menghala ke peti mel atau borang HTTPS yang benar-benar boleh memproses laporan; peti mel peribadi yang tidak dijaga tidak seharusnya menjadi satu-satunya laluan. Jika pasukan berbeza memiliki aset tersebut, dokumentasikan cara laporan dihalakan.
2. Isi dan sahkan medan RFC 9116 secara berterusan
Contact dan Expires adalah wajib; Expires mesti menyatakan masa tamat tempoh pada masa hadapan. Policy boleh dipautkan kepada peraturan ujian dan pendedahan yang dibenarkan, Canonical boleh mengenal pasti fail kanonikal, Encryption hanya disertakan apabila kunci awam yang diselenggara wujud, dan Acknowledgments atau Hiring adalah pilihan. Hidangkan fail di HTTPS /.well-known/security.txt sebagai text/plain, tanpa bergantung pada persembahan HTML.
3. Sambungkan fail kepada aliran kerja tindak balas
Apabila laporan tiba, cipta pengecam tiket yang tidak boleh diramal dan catat masa penerimaan, aset, langkah pembiakan semula (reproduction steps), dan keutamaan komunikasi penyelidik. Petugas on-call terlebih dahulu menyemak skop kebenaran, kemudian melakukan penyahduplikasian, menilai impak, dan menetapkan pemilik. Laporan berisiko tinggi memasuki laluan kecemasan; laporan biasa menggunakan barisan giliran biasa, dengan jejak audit untuk kedua-duanya.
4. Tulis dasar pendedahan dan bukannya mereka-reka SLA
Dasar tersebut harus menerangkan penyelidikan yang dibenarkan, tingkah laku yang dilarang, pemindahan bahan sensitif yang selamat, ganjaran jika ada, masa pendedahan awam dibenarkan, dan cara pengendalian ujian niat baik (good-faith testing). Nyatakan secara bertulis hanya masa akuan penerimaan dan ritma kemas kini yang mampan. Jangan tafsirkan medan RFC sebagai janji bahawa setiap laporan akan dibetulkan dalam tempoh bilangan jam tertentu.
5. Lindungi titik masuk dan data laporan
Fail awam tidak boleh mengandungi kunci peribadi, nama hos dalaman, nombor telefon peribadi, atau butiran insiden yang belum diterbitkan. Hadkan jenis dan saiz lampiran, sekat akses kepada sistem mel dan tiket, serta anggap skrip dan pautan dalam laporan mentah sebagai input yang tidak dipercayai. Pasukan keselamatan boleh menyimpan konteks dalaman yang lebih terperinci, manakala balasan kepada pelapor hanya mendedahkan fakta yang diluluskan.
6. Buktikan bahawa titik masuk berfungsi dengan kebolehcerapan (observability)
Pantau respons 200 fail, sijil HTTPS, masa ke Expires, giliran bertugas on-call, dan penukaran borang ke tiket. Gunakan laporan ujian yang tidak berbahaya untuk mengesahkan makluman, penyahduplikasian, dan eskalasi; jangan sekali-kali menggunakan kerentanan sebenar untuk latihan simulasi. Periksa bahawa CDN, pengalihan (redirect), dan penggunaan pelbagai wilayah tidak menghidangkan salinan yang lama atau tamat tempoh.
Contoh jawapan berkualiti tinggi
Mula-mula saya akan menyenaraikan domain awam yang memerlukan liputan dan menerbitkan fail teks biasa UTF-8 di HTTPS /.well-known/security.txt untuk setiap satu. Contact akan menghala ke peti mel atau borang yang dikendalikan oleh kakitangan, manakala Expires akan ditetapkan pada masa hadapan dan dilindungi oleh amaran tamat tempoh. Saya akan menambah Policy, Canonical, atau Encryption hanya apabila proses dan kunci tersebut diselenggara. Fail tersebut tidak akan menjanjikan tarikh akhir pembaikan; dasar akan menyatakan skop yang dibenarkan, tingkah laku yang dilarang, pemindahan bahan sensitif, ganjaran, dan pendedahan terkoordinasi. Laporan akan memasuki sistem tiket terhad untuk pemeriksaan skop, penyahduplikasian, penilaian keterukan, dan pemilikan, dengan laluan kecemasan untuk kes berisiko tinggi. Saya akan mengesahkan HTTPS, penimbalan (caching), kebenaran, liputan on-call, dan pembaharuan sebelum pelancaran, kemudian memantau kebolehcapaian, penukaran tiket, dan status tindak balas. Fail tersebut menjadikan saluran mudah ditemui; aliran kerja dan pemilikan menyediakan keupayaan keselamatan.
Kesilapan biasa
- Mencipta fail tanpa pemilik on-call, barisan giliran tiket, atau laluan eskalasi.
- Meninggalkan
Expires, menyebabkan penyelidik mendapat maklumat hubungan yang mungkin tidak lagi berfungsi. - Menerbitkan kunci peribadi, alamat dalaman, atau nombor telefon peribadi.
- Menjanjikan SLA pembaikan, jumlah ganjaran, atau tarikh pendedahan yang tidak dapat dikekalkan oleh pasukan.
- Menggantikan titik masuk HTTPS yang stabil dengan HTTP, pengalihan log masuk, atau salinan CDN yang lapuk.
- Menerbitkan butiran pembiakan semula sebelum kebenaran dan impak disemak.
Soalan susulan dan jawapan
Bolehkah security.txt menggantikan dasar pendedahan kerentanan?
Tidak. Ia membantu penyelidik menemui pautan Contact dan Policy; skop kebenaran, ujian niat baik, ganjaran, penyelarasan pendedahan, dan peraturan kecemasan masih berada di bawah dasar.
Mengapakah Expires diperlukan?
Maklumat hubungan dan proses boleh berubah. Expires membolehkan semakan automatik mengenal pasti fail yang mungkin telah lapuk supaya pasukan mengemas kininya daripada membiarkan peti mel lama kelihatan sah selama-lamanya.
Bagaimana jika sesuatu kumpulan mempunyai banyak domain produk?
Terbitkan fail yang sepadan untuk setiap domain milik bebas dan gunakan pautan Canonical atau dasar untuk menerangkan sumber berwibawa. Setiap titik masuk masih perlu sampai kepada pasukan yang boleh menghalakan laporan; menyalin alamat yang tidak dijaga adalah tidak mencukupi.
Apakah langkah pertama selepas penyelidik melaporkan disyaki zero-day?
Sekat akses kepada laporan tersebut, sahkan sumber dan skop aset, catatkan masa dan bukti, serta maklumkan pemilik keselamatan untuk penilaian impak kecemasan. Jangan majukan butiran yang belum disahkan ke saluran awam atau meminta penyelidik meluaskan ujian hanya untuk menjadikan laporan lebih lengkap.