Temu duga Go 1.26: Bagaimana anda berhijrah selepas net/url mengetatkan pengesahan tanda titik bertindih pada hos?

Soalan dan konteks

Satu perkhidmatan HTTP Go dinaik taraf daripada 1.25 ke 1.26 dan mendapati bahawa nilai sejarah http://localhost:80:80/ dan http://::1/ kini gagal, manakala http://[::1]/ masih berjaya. Terangkan perubahan net/url.Parse, kesannya terhadap proksi dan pertahanan SSRF, serta proses penghijrahan yang tidak bergantung pada suis keserasian kekal.

Go 1.26 menetapkan urlstrictcolons kepada 1 secara lalai, menolak tanda titik bertindih tambahan dalam subkomponen hos yang tidak boleh ditafsirkan sebagai hos:port; tingkah laku ini telah dibawa balik (backported) ke Go 1.25.2 dan 1.24.8. RFC 3986 mentakrifkan hos sebagai IP-literal, alamat IPv4, atau nama berdaftar, dengan port dipisahkan oleh satu tanda titik bertindih, jadi IPv6 tekstual perlu berada di dalam tanda kurung siku.

Perkara yang diuji oleh penemu duga

• Bolehkah anda menerangkan daripada sintaks URI mengapa tanda titik bertindih tambahan adalah samar-samar atau tidak sah?
• Bolehkah anda membezakan IPv6 tanpa kurung siku, [IPv6]:port yang sah, nama hos, dan port yang tidak sah?
• Bolehkah anda mengendalikan penghijrahan konfigurasi, URL pihak ketiga, penulisan semula proksi, dan log berbanding melumpuhkan pengesahan?
• Bolehkah anda menerangkan bahawa GODEBUG=urlstrictcolons=0 ialah alat keserasian sementara, bukan dasar pengesahan input?
• Bolehkah anda membuktikan tingkah laku penghuraian, sambungan, pengalihan semula, dan SSRF dengan ujian regresi selepas peningkatan?

Soalan untuk dijelaskan terlebih dahulu

• Adakah URL yang gagal berasal daripada konfigurasi manusia, pangkalan data, input pengguna, atau panggilan balik pihak ketiga? Tahap kepercayaan masing-masing berbeza.
• Adakah aplikasi menggabungkan url.Parse, url.Hostname, dan url.Port? API penghuraian yang berbeza mengubah tingkah laku.
• Adakah IPv6 dalaman mesti disokong, adakah port diperlukan, dan bolehkah proksi menulis semula Hos?
• Bolehkah nilai lama diperbetulkan secara dalam talian, atau bolehkah ia disahkan dan ditolak dalam kelompok pra-keluaran?
• Adakah perkhidmatan menggunakan penghuraian URL untuk kawalan capaian, penghalaan penyewa (tenant routing), atau pertahanan SSRF?

Jawapan 30 saat

"Saya akan mengklasifikasikan kegagalan mengikut sumber dan bentuk hos. Go 1.26 mendayakan urlstrictcolons secara lalai, jadi IPv6 tanpa kurung siku dan rentetan dengan beberapa tanda titik bertindih pada hos ditolak; bentuk eksplisit ialah [::1], dengan port ditulis sebagai [::1]:8080. Saya akan membaiki dan menolak nilai tidak sah pada sempadan konfigurasi, menambah ujian regresi penghuraian dan rangkaian, serta memerhatikan kadar kegagalan dalam kenari. GODEBUG=urlstrictcolons=0 hanyalah alat pengembalian semula dan pembersihan jangka pendek, bukan dasar kekal untuk input yang tidak dipercayai."

Analisis mendalam langkah demi langkah

1. Wujudkan garis dasar. Kumpul sampel yang gagal pada versi lama dan Go 1.26, merekodkan ralat huraian, nilai mentah, sumber, dan kegunaan akhir. "Boleh dihuraikan" tidak bermakna "selamat untuk disambungkan"; periksa juga skema, nama hos, port, dan pengalihan semula.

1. Klasifikasikan mengikut sintaks URI. http://[::1]/ ialah IP-literal bertanda kurung siku; http://[::1]:8080/ meletakkan port selepas tanda kurung siku. http://::1/ menggunakan tanda titik bertindih kedua-duanya sebagai data hos dan pemisah port, manakala http://localhost:80:80/ mengandungi berbilang pemisah port; kedua-duanya merupakan nilai yang perlu dibaiki.

1. Baiki sempadan data terlebih dahulu. Tambahkan pengesahan pada fail konfigurasi, migrasi pangkalan data, dan API pentadbir: normalkan IPv6 dengan kurung siku, huraikan port sebagai integer dalam julat, dan tolak hos yang tidak dapat ditafsirkan. Semasa pembersihan kelompok, kekalkan nilai asal, nilai yang diperbetulkan, dan sumber pemilik; asingkan rekod yang tidak dapat diputuskan secara automatik.

1. Semak laluan keselamatan. Kawalan capaian harus menggunakan Hostname() yang telah dihuraikan, port, dan hasil IP, dengan sempadan yang jelas untuk DNS, pengalihan semula, dan penulisan semula proksi. Jangan sesekali mengklasifikasikan destinasi dalaman berbanding awam daripada awalan rentetan atau satu hasil Parse sahaja. Jalankan semula kes SSRF, proksi, dan pengalihan semula selepas peningkatan.

1. Reka bentuk pengembalian semula sementara. GODEBUG=urlstrictcolons=0 boleh memulihkan tingkah laku lama dalam persekitaran terkawal, tetapi ia memerlukan tarikh luput, metrik, dan amaran, serta tidak boleh membenarkan input pengguna baharu memintas pengesahan. Pilihan yang lebih selamat adalah mendayakannya hanya untuk set konfigurasi legasi yang diinventori dalam proses terasing, kemudian melumpuhkannya selepas pembersihan.

1. Laksanakan kenari dan sahkan. Jalankan trafik bayangan (shadow traffic) dan set contoh (instance) kecil, membandingkan ralat huraian, ralat sambungan, padanan proksi, dan hasil pengalihan semula. Pintu sempadan harus merangkumi IPv4 yang sah, IPv6 bertanda kurung siku, IPv6 yang tidak sah, tanda titik bertindih tambahan, port kosong, dan pengalihan semula berniat jahat. Kembangkan hanya selepas pembersihan legasi selesai.

func validateEndpoint(raw string) (*url.URL, error) {
    u, err := url.Parse(raw)
    if err != nil {
        return nil, err
    }
    if u.Scheme != "http" && u.Scheme != "https" {
        return nil, fmt.Errorf("unsupported scheme")
    }
    host := u.Hostname()
    if host == "" {
        return nil, fmt.Errorf("missing host")
    }
    if p := u.Port(); p != "" {
        n, err := strconv.Atoi(p)
        if err != nil || n < 1 || n > 65535 {
            return nil, fmt.Errorf("invalid port")
        }
    }
    return u, nil
}

Jawapan model

Saya akan mengenal pasti sumber setiap nilai yang tidak sah terlebih dahulu dan mengasingkan ralat sintaks daripada kegagalan sambungan. Go 1.26 menetapkan urlstrictcolons=1 secara lalai, menolak http://::1/ dan http://localhost:80:80/ kerana tanda titik bertindih tidak dapat ditafsirkan secara jelas sebagai IPv6 yang sah atau satu port tunggal; http://[::1]:8080/ adalah eksplisit.

Pada sempadan konfigurasi dan pentadbir, saya akan menolak nilai yang tidak sah (malformed), membaiki secara automatik rekod yang terbukti sebagai IPv6, dan mengasingkan rekod yang samar-samar untuk pemiliknya. Setiap laluan yang menggunakan URL untuk penghalaan, pelaksanaan proksi, atau pertahanan SSRF mesti menguji semula nama hos, port, DNS, pengalihan semula, dan penulisan semula proksi. GODEBUG=urlstrictcolons=0 ialah pengembalian semula keserasian yang terhad masa dengan metrik dan amaran, bukan cara untuk membiarkan input tidak dipercayai memintas pemeriksaan baharu. Kenari membandingkan ralat huraian, ralat sambungan, dan kes keselamatan sebelum pengembalian semula dialih keluar.

Kesilapan biasa

• Gejala: Menganggap setiap rentetan IPv6 tanpa kurung siku sebagai sah → Sebab ia gagal: Sempadan hos dan port adalah samar-samar → Penyelesaian: Gunakan [IPv6] dan letakkan port selepas ].
• Gejala: Menetapkan GODEBUG=urlstrictcolons=0 secara kekal → Sebab ia gagal: Input tidak sah dan kesamaran legasi kekal wujud → Penyelesaian: Tetapkan tarikh luput dan baiki data serta sempadan terlebih dahulu.
• Gejala: Hanya menguji sama ada url.Parse mengembalikan ralat → Sebab ia gagal: Nama hos, port, DNS, pengalihan semula, dan proksi boleh mengubah hasil keselamatan → Penyelesaian: Uji keseluruhan laluan rangkaian.
• Gejala: Mengklasifikasikan alamat peribadi daripada rentetan mentah → Sebab ia gagal: Pengekodan, penghuraian, DNS, dan pengalihan semula boleh memintas peraturan rentetan → Penyelesaian: Huraikan secara konsisten, selesaikan IP, dan guna semula dasar selepas setiap pengalihan semula.

Soalan susulan dan jawapan

Konfigurasi legasi mesti dipulihkan hari ini. Bagaimanakah anda mengawal risiko?

Dayakan urlstrictcolons=0 hanya untuk proses terasing atau set legasi yang diinventori secara eksplisit, dengan tarikh luput, sekatan sumber dan sasaran, serta metrik bagi setiap capaian. Nilai baharu tetap menggunakan pengesahan ketat; tutup pengembalian semula selepas pembersihan selesai.

Mengapa [::1] sah manakala ::1 tidak digalakkan?

Entiti berkuasa URI (URI authority) menggunakan tanda titik bertindih untuk memisahkan hos dan port. Tanda kurung siku menjadikan sempadan antara IP-literal IPv6 dan port jelas. Meletakkan ::1 secara langsung dalam hostport adalah samar-samar, jadi Go 1.26 menolaknya.

Di manakah proksi mesti mengesahkan semula?

Penghuraian pada bahagian masuk (ingress) tidak mencukupi. Selepas menulis semula Hos, mengikut pengalihan semula, atau menyelesaikan DNS sekali lagi, guna semula dasar skema, nama hos, IP, port, dan rangkaian pada destinasi baharu; jangan bawa keputusan URL awal merentasi lompatan (hop).

Bagaimanakah anda membuktikan bahawa peningkatan tidak meluaskan penolakan secara tidak wajar?

Kekalkan korpus tetap bagi IPv4 yang sah, IPv6 bertanda kurung siku, URL dengan port, hos dengan tanda titik bertindih tambahan yang tidak sah, hos kosong, port tidak sah, dan pengalihan semula. Jalankannya pada Go 1.24.8, 1.25.2, dan 1.26, kemudian bandingkan kadar kegagalan konfigurasi sebenar semasa kenari.

Rujukan

• Nota Keluaran Go 1.26
• Go, Keserasian Ke Belakang, dan GODEBUG
• RFC 3986 Pengecam Sumber Seragam: Sintaks Generik
• Sumber Go net/url

Senarai semak temu duga

Terangkan hos, kurung siku IPv6, dan sempadan port terlebih dahulu. Kemudian bincangkan pembersihan data, pengesahan sempadan yang ketat, pengujian semula laluan SSRF, dan pengembalian semula GODEBUG yang bertarikh luput. Asingkan keserasian penghuraian daripada keselamatan capaian.

Kesimpulan satu ayat

Go 1.26 memerlukan perkhidmatan untuk menukar URL yang samar-samar kepada URI yang eksplisit dan menggunakan ujian, kenari, serta pengembalian semula terhad masa untuk penghijrahan yang selamat.