Gesaan dan konteks
Pasukan memerlukan Templat URI untuk dokumentasi API, pautan penomboran halaman, dan URL pertanyaan kelompok seperti /users{?status,limit}. Templat datang daripada konfigurasi manakala sesetengah nilai pemboleh ubah datang daripada pengguna. Terangkan tahap ungkapan RFC 6570, pengembangan aksara terpelihara dan senarai, serta sempadan keselamatan untuk menghuraikan, mengembangkan, dan mengesahkan hasilnya.
Perkara yang diuji oleh penemu duga
- Mengasingkan sintaks templat, pengekodan pemboleh ubah, serta penghuraian dan pengesahan URI akhir.
- Menerangkan perbezaan antara pengembangan mudah, terpelihara, laluan, parameter matriks, dan pertanyaan.
- Mengendalikan senarai, pemetaan bersekutu, explode, pemotongan awalan, dan pemboleh ubah yang tidak ditakrifkan.
- Mengenal pasti risiko SSRF, perentasan laluan, pengalihan terbuka (open redirects), dan kebocoran data daripada templat yang tidak dipercayai.
Soalan untuk dijelaskan terlebih dahulu
- Adakah templat merupakan kod statik, konfigurasi yang disemak, atau dibekalkan oleh penyewa/pengguna?
- Adakah hasil hanya dipaparkan, atau dihantar terus oleh klien HTTP bahagian pelayan?
- Adakah pemboleh ubah berupa rentetan, senarai, pemetaan bersekutu, atau JSON bersarang?
- Skim, hos, port, dan awalan laluan manakah yang dibenarkan; adakah hasilnya mesti kekal pada asal (origin) API semasa?
- Adakah pelaksanaan mesti menyokong semua tahap RFC 6570, atau hanya subset pengendali yang diluluskan?
Kerangka jawapan 30 saat
Saya akan mengasingkan penghuraian templat, pengekodan pemboleh ubah, dan dasar URI akhir. Mula-mula tentukan pengendali dan jenis nilai RFC 6570 yang disokong, kemudian gunakan pengekodan peratus (percent-encoding), pengembangan senarai, dan pemetaan bersekutu bagi setiap pengendali; pemboleh ubah yang tidak ditakrifkan harus ditinggalkan mengikut spesifikasi. Anggap setiap nilai yang diperluaskan sebagai URI yang tidak dipercayai, huraikan dan sahkan skim, hos, port, dan laluan ternormalnya, serta jangan sekali-kali membiarkan templat memilih sasaran rangkaian bahagian pelayan yang sewenang-wenangnya. Ujian akan merangkumi aksara terpelihara, Unicode, nilai kosong, kunci berulang, awalan, dan laluan berniat jahat.
Jawapan mendalam langkah demi langkah
Langkah 1: Tentukan sempadan Templat URI
Templat URI ialah sintaks untuk menyatakan rujukan URI dengan pemboleh ubah. Ia bukan klien HTTP, senarai dibenarkan URL, atau penghala perniagaan. Pelaksanaan mesti menghuraikan literal dan ungkapan sebelum menghasilkan hasil daripada nilai; ia tidak boleh menggabungkan templat ke dalam permintaan atau menganggap nilai yang diperluaskan sebagai URL yang sudah selamat.
Langkah 2: Laksanakan pengendali mengikut tahap
RFC 6570 bermula dengan pengembangan pemboleh ubah mudah dan menambah bentuk aksara terpelihara, serpihan, label, segmen laluan, parameter matriks, pertanyaan, dan penerusan pertanyaan. Pengendali biasa termasuk +, #, ., /, ;, ?, dan &. Pengendali mentakrifkan pemisah, kelakuan nilai kosong, dan aksara terpelihara yang boleh kekal; satu peraturan penggantian rentetan generik tidak mencukupi.
Langkah 3: Kendalikan pengekodan dan nilai komposit
Aksara terpelihara dalam rentetan mudah dikodkan mengikut peratus mengikut ungkapan tersebut. Senarai boleh digabungkan dengan koma atau di-explode menjadi parameter berulang; pemetaan bersekutu mempunyai pemisah kunci/nilai mereka sendiri. Pengubah suai awalan mengambil awalan rentetan dan tidak boleh disalah anggap sebagai kiraan aksara Unicode, kiraan bait, atau pemotongan selamat. Tentukan kelakuan untuk UTF-8, rentetan kosong, dan pemboleh ubah yang tidak ditakrifkan.
Langkah 4: Asingkan sumber templat dan pemboleh ubah
Templat statik yang disemak kod boleh menyokong lebih banyak pengendali; konfigurasi penyewa harus mengehadkan ungkapan, nama pemboleh ubah, dan komponen output. Nilai mungkin datang daripada permintaan, tetapi templat tidak boleh memanggil fungsi, membaca pemboleh ubah persekitaran, atau menyusun skim sewenang-wenangnya. Pastikan AST templat diasingkan daripada pemetaan nilai supaya nama pemboleh ubah tidak boleh menyuntik sintaks ungkapan baharu.
Langkah 5: Sahkan URI akhir
Selepas pengembangan, gunakan penghurai URI standard untuk skim, autoriti, laluan, pertanyaan, dan serpihan. Untuk permintaan bahagian pelayan, skim, hos, dan port mesti sepadan dengan senarai yang dibenarkan; resolusi DNS juga mesti menyekat alamat loopback, link-local, dan peribadi, dan pengalihan mesti diperiksa semula. Normalkan laluan sebelum memeriksa punca (root) yang dibenarkan supaya .. yang dikodkan tidak dapat memintas peraturan.
Langkah 6: Jadikan pautan API mudah diselenggara
Templat penomboran halaman harus menentukan pemboleh ubah mana yang dijana pelayan, manakala penapis menggunakan nama dan jenis pemboleh ubah yang tetap. Jangan letakkan tandatangan, token akses, atau nama hos dalaman ke dalam templat awam atau hasil. Rekod versi templat, skema pemboleh ubah, dan ralat pengembangan. Jika susunan yang stabil diperlukan, lapisan perniagaan mesti menyediakannya dan bukannya bergantung pada susunan rentetan parameter.
Langkah 7: Bina ujian dan pemantauan
Uji setiap pengendali dengan nilai tunggal, senarai, pemetaan, nilai kosong, dan nilai yang tidak ditakrifkan terhadap contoh spesifikasi. Tambah aksara terpelihara, Unicode, kunci pertanyaan berulang, awalan panjang, pengekodan berganda, %2e%2e, skim alternatif, pengalihan, dan kes resolusi DNS. Pantau kegagalan pengembangan, sebab penolakan, pengedaran asal destinasi, dan panjang yang tidak normal, serta cetuskan semakan apabila konfigurasi templat berubah.
Contoh jawapan berkualiti tinggi
Saya mula-mula akan mengehadkan pengendali RFC 6570 yang disokong dan mengasingkan AST templat, skema pemboleh ubah, pengekodan peratus, dan pengesahan URI akhir. Senarai, pemetaan, explode, dan awalan mengikut peraturan masing-masing, dan pemboleh ubah yang tidak ditakrifkan ditinggalkan; nilai tidak boleh dihuraikan semula sebagai ungkapan. Setiap hasil kekal sebagai URI yang tidak dipercayai: huraikannya, benarkan hanya skim, hos, port, dan laluan ternormal API, sekat alamat peribadi untuk permintaan bahagian pelayan, dan semak semula setiap pengalihan. Ujian merangkumi contoh RFC, Unicode, nilai kosong, kunci berulang, pengekodan berganda, perentasan, dan SSRF, dengan versi templat dan sebab penolakan direkodkan.
Kesilapan biasa
- Menggantikan semantik pengendali dengan penggabungan rentetan dan merosakkan pemisah atau pengekodan peratus.
- Memperlakukan pengembangan terpelihara
+sebagai "tiada pengekodan langsung" dan mengabaikan sempadan komponen. - Memperlakukan senarai, pemetaan, dan explode sebagai satu format gabungan koma.
- Hanya mengesahkan teks templat dan bukannya skim, hos, port, dan laluan ternormal yang diperluaskan.
- Memperlakukan pengekodan URL sebagai perlindungan SSRF dan mengikuti pengalihan tanpa pengesahan semula.
Soalan susulan dan jawapan
Susulan 1: Apakah yang patut berlaku kepada pemboleh ubah yang tidak ditakrifkan?
Tinggalkan pemboleh ubah yang tidak ditakrifkan dan pemisah yang diperlukan mengikut ungkapan tersebut. Jangan paparkan rentetan null. Jika skema perniagaan memerlukan pemboleh ubah tersebut, tolaknya sebelum pengembangan.
Susulan 2: Mengapa tidak memanggil satu fungsi URL-encode sahaja?
Pengekodan bergantung pada ungkapan dan komponen URI. Parameter pertanyaan, segmen laluan, dan pengembangan terpelihara mempunyai pemisah dan peraturan yang berbeza. Satu fungsi tidak boleh menentukan nilai komposit, nilai kosong, awalan, dan pengendali.
Susulan 3: Bagaimanakah anda mengurangkan risiko untuk templat penyewa?
Gunakan subset pengendali yang disemak, skema pemboleh ubah tetap, dan komponen output tetap. Jangan benarkan skim atau autoriti sewenang-wenangnya, kemudian tetap laksanakan senarai dibenarkan asal, penormalan laluan, pemeriksaan DNS/IP, dan pengesahan semula pengalihan selepas pengembangan.
Susulan 4: Bolehkah pengubah suai awalan memotong rahsia?
Ia adalah semantik awalan rentetan Templat URI, bukan penutupan privasi atau pemotongan selamat Unicode. Tutup data sensitif dalam lapisan perniagaan, di mana panjang dan sempadan aksara merupakan dasar yang eksplisit.
Susulan 5: Bagaimanakah anda membuktikan keserasian RFC 6570?
Jalankan contoh spesifikasi RFC 6570 dan ujian peringkat pengendali, bandingkan pengembangan yang dijangkakan untuk setiap jenis pemboleh ubah, kemudian tambah kes penolakan khusus projek dan dokumentasikan tahap yang tidak disokong serta perbezaannya.