Soalan dan skop
Papan pemuka dihidangkan dari asal (origin) HTTPS awam. Ia kadangkala memanggil pencetak pada alamat peribadi dan pembantu (helper) pada localhost; ia juga membenamkan iframe vendor yang tidak sepatutnya mencapai rangkaian tempatan. Terangkan cara pelayar membezakan ruang alamat awam, tempatan dan loopback, bila kebenaran pengguna diperlukan, dan cara halaman harus pulih daripada penolakan.
Kekalkan pengesahan aplikasi, CORS dan pengesahan peranti dalam skop sebagai lapisan yang berasingan. Kebenaran pelayar ialah sempadan persetujuan pengguna, bukan bukti bahawa pencetak adalah milik akaun semasa. Andaikan produk boleh menawarkan laluan konfigurasi manual apabila pelayar tidak melaksanakan Local Network Access.
Perkara yang sedang diuji oleh penemu duga
Isyarat utama ialah sama ada anda mengiktiraf halaman awam yang memanggil titik akhir peribadi sebagai sempadan keselamatan. Jawapan yang kukuh menamakan serangan gaya CSRF terhadap penghala dan pencetak, kemudian mengekang aliran dengan konteks selamat (secure context), pengelasan address-space, keadaan kebenaran dan senarai kebenaran (allowlist) untuk kandungan terbenam.
Penemu duga juga akan menyiasat sama ada anda mengelirukan local-network dengan loopback-network, atau menganggap bahawa pra-pemeriksaan (preflight) CORS yang berjaya memberikan akses. Jawapan yang baik mengekalkan dasar, kebenaran, kandungan bercampur (mixed content), CORS dan pengesahan peranti sebagai pintu pagar yang berasingan.
Soalan untuk dijelaskan sebelum menjawab
- Adakah semua sasaran diketahui lebih awal, atau pengguna boleh memasukkan alamat IP sewenang-wenangnya? Pengimbasan sewenang-wenangnya memerlukan sempadan produk yang berbeza dan tidak seharusnya disembunyikan di sebalik butang "sambung" generik.
- Adakah pembantu hanya pada
localhost, atau bolehkah ia dicapai melalui subnet peribadi? Ini mengubah sama ada kebenaran loopback atau rangkaian tempatan diperlukan. - Bolehkah iframe vendor atau bingkai bersarang membuat permintaan? Jika ya, setiap sempadan bingkai mesti mewakilkan ciri dan kemungkinan asal navigasinya secara eksplisit.
- Pelayar dan dasar perusahaan yang manakah disokong? Masa pelancaran berbeza-beza, jadi laluan keserasian mesti boleh diperhatikan dan bukannya melemahkan keselamatan secara senyap.
Rangka kerja jawapan 30 saat
"Saya akan mengekalkan papan pemuka pada HTTPS, mengelaskan setiap destinasi sebagai awam, tempatan atau loopback, dan meminta hanya kebenaran pelayar yang sepadan apabila diperlukan. Dasar respons akan menolak akses tempatan kepada iframe vendor; jika iframe mesti disambungkan, senarai allow-nya akan menamakan asal yang tepat dan semua sasaran navigasi. Saya akan menyemak keadaan kebenaran sebelum tindakan diambil, menunjukkan sebab akses diperlukan, mengendalikan kegagalan mixed-content dan CORS secara berasingan, dan menyediakan laluan persediaan manual untuk pelayar yang tidak disokong. Ujian akan menegaskan bahawa hos sewenang-wenangnya dan bingkai iklan pengeluaran tidak sekali-kali mencetuskan permintaan rangkaian tempatan."
Jawapan mendalam langkah demi langkah
Langkah 1: Tentukan sempadan kepercayaan dan ruang alamat
Tapak web awam tidak boleh menghantar permintaan yang mengubah keadaan secara senyap ke penghala, pencetak atau perkhidmatan pembangunan pengguna. Modelkan tiga kelas destinasi: alamat awam boleh dicapai secara global, alamat tempatan hanya boleh dicapai pada rangkaian pengguna, dan alamat loopback menyasarkan peranti yang sama. localhost tidak setara dengan setiap subnet peribadi.
Inventori permintaan harus merangkumi fetch, muatan sub-sumber, WebSockets, WebTransport, WebRTC, permintaan service-worker dan navigasi bingkai. Pustaka yang membuka soket boleh melintasi sempadan yang sama walaupun kod aplikasi tidak mengandungi panggilan fetch langsung.
Langkah 2: Memerlukan konteks selamat dan kebenaran eksplisit
Gunakan halaman peringkat atas HTTPS. Dalam pelayar yang menyokong, buat pertanyaan bagi kebenaran yang berkaitan sebelum mencuba tindakan peranti:
const localState = await navigator.permissions.query({ name: "local-network" });
const loopbackState = await navigator.permissions.query({ name: "loopback-network" });Layan granted, prompt, dan denied sebagai keadaan produk. Terangkan tujuannya sebelum mencetuskan gesaan; sekiranya ditolak, tunjukkan pautan pembaikan atau persediaan manual dan bukannya mencuba semula dalam gelung (loop). Halaman HTTP mesti dianggap tidak disokong untuk aliran ini walaupun sasaran kebetulan menjawab.
Langkah 3: Kekang dokumen terbenam
Respons peringkat atas hanya boleh mewakilkan ciri dan asal yang memerlukannya. Bingkai vendor tidak mendapat keupayaan rangkaian tempatan:
Permissions-Policy: local-network=(self "https://dashboard.example"), loopback-network=(self "https://dashboard.example")Jika bingkai persediaan yang dipercayai mesti menyambung, wakilkan secara sempit:
<iframe src="https://setup.example" allow="local-network https://setup.example; loopback-network https://setup.example"></iframe>Pengepala dan dasar iframe bersilang. Bingkai tidak boleh meluaskan penolakan induk. Jika bingkai menavigasi ke asal lain yang turut membuat permintaan tempatan, senaraikan asal tersebut secara eksplisit atau tolak akses selepas navigasi. Bingkai bersarang memerlukan dasar pada setiap sempadan.
Langkah 4: Asingkan kebenaran daripada mixed content dan CORS
Kebenaran tidak menjadikan permintaan yang tidak selamat sah secara universal. Sesetengah pelaksanaan pelayar membenarkan titik akhir HTTP tempatan terpilih selepas persetujuan, manakala pemeriksaan mixed-content yang lain masih terpakai. Gunakan metadata ruang alamat sasaran permintaan hanya apabila pelayar dan kontrak titik akhir menyokongnya; jangan gunakannya sebagai pintasan untuk destinasi awam.
CORS menjawab sama ada sasaran membenarkan asal web membaca respons. Ia tidak membenarkan halaman awam mencapai pencetak, dan ia tidak boleh menggantikan pengesahan peranti. Untuk arahan yang mengubah keadaan, gunakan cabaran khusus peranti atau kod penggandingan dan jadikan arahan tersebut idempoten.
Langkah 5: Reka bentuk sandaran dan telemetri
Pelayar yang tidak disokong harus mendedahkan IP manual, pembantu natif atau laluan penggandingan berpandukan pengguna. Rekod kelas destinasi, keadaan kebenaran, hasil dasar, keupayaan pelayar, hasil CORS dan hasil pengesahan peranti tanpa mencatat kelayakan atau respons tempatan mentah. Penggera pengeluaran harus diaktifkan jika sesuatu keluaran menyebabkan kelas hos baharu meminta akses tempatan atau jika bingkai iklan mencubanya.
Langkah 6: Uji matriks negatif
Uji localhost, IP peribadi, nama hos awam yang menyelesaikan secara awam, nama hos awam yang menyelesaikan secara tempatan, halaman HTTP, kebenaran yang hilang, kebenaran yang ditolak, perwakilan iframe yang hilang, bingkai bersarang, navigasi ke asal yang tidak disenaraikan, respons CORS yang disekat, kegagalan pengesahan peranti dan alamat yang mengubah kelas semasa penyelesaian DNS. Sahkan bahawa hanya tindakan pengguna yang dimaksudkan boleh mencetuskan gesaan dan tiada percubaan semula latar belakang yang mengimbas julat.
Contoh jawapan berkualiti tinggi
"Saya akan menganggap permintaan awam-ke-tempatan sebagai keupayaan yang mesti diminta dan diskopkan. Papan pemuka kekal HTTPS, mengelaskan destinasi pencetak dan pembantu secara berasingan, menyemak keadaan local-network atau loopback-network, dan menerangkan gesaan sebelum membuat satu permintaan yang terhad. Dasar respons menafikan kedua-dua ciri kepada iframe vendor. Jika iframe persediaan yang dipercayai diperlukan, senarai allow-nya hanya mengandungi asal persediaan dan setiap asal yang mungkin dinavigasinya.
Saya akan mengekalkan kebenaran pelayar, pemeriksaan mixed-content, CORS dan pengesahan peranti sebagai pintu pagar yang berasingan. Pelayar yang ditolak atau tidak disokong mendapat penggandingan manual dan bukannya permintaan berulang. Ujian meliputi tempatan, loopback, awam, pengelasan semula DNS, bingkai bersarang, perwakilan yang hilang, kebenaran yang ditolak, kegagalan CORS dan kegagalan pengesahan peranti. Keluaran dihentikan jika iklan atau hos sewenang-wenangnya boleh mencetuskan permintaan atau gesaan."
Kesilapan biasa
- Menganggap setiap IP peribadi sebagai loopback → loopback dan rangkaian tempatan mempunyai semantik kebenaran yang berbeza → kelaskan destinasi sebelum memilih kebenaran.
- Mencuba semula selepas penolakan sehingga gesaan muncul → ini menimbulkan kejutan dan tingkah laku seperti imbasan → tunjukkan konteks sekali dan sediakan pemulihan.
- Mengandaikan CORS menjadikan pencetak boleh dipercayai → CORS mengawal perkongsian respons, bukan identiti peranti → gandingkan peranti dan sahkan arahan.
- Memberikan
local-network *kepada bingkai vendor → ubah hala dan dokumen bersarang boleh meluaskan set kepercayaan → senaraikan asal yang tepat atau tolak perwakilan. - Bergantung pada ujian localhost sahaja → ia mungkin tidak menguji sempadan awam-ke-tempatan → uji daripada asal HTTPS awam terhadap setiap kelas alamat.
Soalan susulan dan respons
Susulan 1: Mengapakah localhost berfungsi dalam pembangunan tetapi gagal dalam pengeluaran?
Pembangunan mungkin berjalan dari asal loopback atau pelayar tanpa sekatan baharu. Pengeluaran ialah asal awam yang melintasi ruang loopback atau tempatan, jadi konteks selamat, kebenaran, dasar, mixed-content dan pintu pagar CORS semuanya menjadi relevan. Hasilkan semula daripada asal ujian HTTPS awam.
Susulan 2: Bolehkah iframe mewarisi kebenaran peringkat atas secara automatik?
Hanya dalam peraturan dasar dan perwakilan. Bingkai silang asal (cross-origin) memerlukan pemberian ciri yang eksplisit, dan bingkai bersarang memerlukan perwakilan mereka sendiri. Keputusan pengguna terikat pada konteks pembenaman, tetapi ia tidak memintas allow yang tiada atau asal navigasi yang tidak disenaraikan.
Susulan 3: Bagaimana jika DNS untuk agent.example bertukar daripada awam kepada peribadi?
Kelaskan semula alamat yang diselesaikan dan perlukan kebenaran yang sesuai serta laluan konteks selamat. Jangan simpan cache pengelasan awam selama-lamanya. Log peralihan pengelasan dan lakukan fail closed jika destinasi tiada dalam set sasaran yang diluluskan oleh produk.
Susulan 4: Mengapakah gesaan kebenaran tidak mencukupi untuk arahan pencetak?
Gesaan itu menyatakan bahawa pengguna membenarkan akses rangkaian dari tapak; ia tidak mengesahkan peranti atau membenarkan operasi yang diminta. Gandingkan peranti, ikat arahan pada akaun dan nonce, dan jadikan percubaan semula sebagai idempoten.