Kebocoran Kata Sandi Proxy Melalui Klien HTTP: CVE di curl, libsoup, dan requests

Kata sandi untuk proxy biasanya dijaga dari orang: tidak ditampilkan dalam tangkapan layar, tidak dikomit ke git, disimpan dalam variabel lingkungan. Namun, pada tahun 2026, terungkap bahwa kata sandi tersebut dapat diberikan oleh klien HTTP itu sendiri. Dari April hingga Juli, muncul beberapa kerentanan di curl, libcurl, dan libsoup, di mana header Proxy-Authorization dikirimkan bukan kepada proxy yang seharusnya, tetapi langsung ke situs target. Di bawah ini adalah analisis tentang dalam kondisi apa ini terjadi, dan langkah-langkah untuk memeriksa tumpukan Anda.

Apa yang terjadi: empat kebocoran dalam empat bulan

Semua bug ini berfungsi dengan cara yang sama: klien mengingat login dan kata sandi satu proxy dan secara tidak sengaja mengirimkannya lebih jauh dalam rantai.

• CVE-2026-6253 (curl dan libcurl 7.14.1–8.19.0). Jika untuk http:// dan https:// diatur proxy yang berbeda, yang pertama memerlukan kata sandi, sedangkan yang kedua tidak, maka saat pengalihan dari perubahan skema, curl akan mengirimkan kredensial proxy pertama ke yang kedua. Data dikirim dalam base64, yaitu sebenarnya dalam teks terbuka. Diperbaiki di curl 8.20.0, yang dirilis pada 29 April 2026. Konsol curl juga rentan, bukan hanya perpustakaan.
• CVE-2026-8927 (libcurl 7.12.0–8.20.0). Aplikasi menggunakan satu handle untuk beberapa permintaan, proxy diambil dari variabel lingkungan, dan otorisasi dilakukan melalui Digest. Dalam hal ini, header Proxy-Authorization untuk proxy A dikirim ke proxy B, dan yang terakhir dapat mengulanginya untuk mengaku sebagai Anda. Diperbaiki di curl 8.21.0 pada 24 Juni 2026. Konsol curl tidak terpengaruh. Bug hampir sama dijelaskan dalam CVE-2026-7168, perbedaannya hanya pada cara pemilihan proxy.
• CVE-2026-12547 (libsoup, SoupAuthManager). libsoup menyimpan kredensial proxy dalam cache, tanpa mengaitkannya dengan alamat host:port. Ketika pengaturan proxy berubah (parameter sistem, WPAD), header lama dikirim ke proxy baru. Dipublikasikan pada 21 Juli 2026, penilaian rendah.
• CVE-2026-66339 (libsoup, terowongan CONNECT). Setelah mengatur terowongan CONNECT melalui proxy HTTP, libsoup melampirkan Proxy-Authorization ke permintaan HTTPS berikutnya di dalam terowongan. Header ini dilihat oleh server target. CVSS 6.5, dipublikasikan pada 24 Juli 2026.

Sejarah ini bukan hal baru. Dalam pustaka Python requests dari versi 2.3.0 hingga 2.31.0 (CVE-2023-32681), header Proxy-Authorization saat pengalihan ke HTTPS dikirim ke server target, jika login dan kata sandi ditulis langsung dalam URL proxy. Dalam urllib3 hingga 1.26.19 dan 2.2.2 (CVE-2024-37891), header yang ditetapkan secara manual, bukan melalui dukungan proxy bawaan, tidak dihapus saat pengalihan ke domain lain.

Kenapa ini penting khususnya untuk bekerja dengan proxy

Untuk proxy berbayar, kata sandi sama dengan uang. Siapa pun yang mendapatkannya akan menggunakan trafik Anda, sampai Anda mengganti akses. Saat membayar untuk gigabyte, ini adalah biaya langsung, dan saat akses dibagikan untuk seluruh tim, tindakan orang lain juga dilakukan melalui IP Anda.

Skenario yang paling rentan terlihat seperti ini:

• Parser dan pemantauan, yang secara otomatis mengikuti pengalihan. Situs target atau pengalihan sementara dapat mengarahkan permintaan ke domain yang mengumpulkan header.
• Skrip dengan beberapa proxy: proxy yang berbeda untuk skema yang berbeda, beralih proxy antara permintaan dalam satu koneksi, mencampurkan "proxy dengan kata sandi" dan "proxy tanpa kata sandi".
• Proses jangka panjang di server Linux, di mana libcurl dan libsoup datang dengan paket sistem dan diperbarui bersama dengan distribusi, bukan dengan kode Anda.
• Jaringan korporat dengan WPAD dan file PAC: proxy berubah tanpa keterlibatan aplikasi, dan inilah kasus yang dijelaskan dalam CVE-2026-12547.

Bagaimana memeriksa tumpukan Anda: langkah demi langkah

1. Ketahui versi libcurl yang sebenarnya, bukan hanya curl konsol. Perintah curl -V menunjukkan keduanya, tetapi aplikasi mungkin dibangun dengan salinan perpustakaan sendiri. Untuk Python dengan pycurl, jalankan python -c "import pycurl; print(pycurl.version)", untuk PHP panggil curl_version(). Batas aman: 8.21.0 dan yang lebih baru atau cabang yang diperbaiki 8.20.1+, 8.16.1+, dan 8.14.2+.
2. Periksa ketergantungan Python. Jalankan pip show requests urllib3. Dibutuhkan requests tidak lebih rendah dari 2.31.0 dan urllib3 tidak lebih rendah dari 1.26.19 (cabang 1.x) atau 2.2.2 (cabang 2.x). Jika ketergantungan datang secara transitif, lihat pip list di dalam lingkungan yang sama di mana parser berjalan.
3. Periksa libsoup di Linux. Ini berlaku untuk aplikasi GNOME, WebKitGTK, dan semua yang dibangun di atas tumpukan ini. Perbarui paket melalui manajer distribusi dan periksa buletin keamanan distribusi Anda: dalam kartu CVE ini, Red Hat mencantumkan RHEL 6–10 sebagai yang terpengaruh.
4. Cari di kode pengaturan header secara manual. Cari Proxy-Authorization di seluruh repositori. Jika header diatur secara manual, bukan melalui mekanisme proxy klien yang standar (proxies= di requests, ProxyManager di urllib3, CURLOPT_PROXYUSERPWD di libcurl), ini adalah kandidat untuk kebocoran saat pengalihan.
5. Cari penggunaan kembali koneksi saat mengganti proxy. Satu handle libcurl, satu sesi requests atau satu agen HTTP, melalui mana permintaan dengan proxy yang berbeda dilakukan secara bergantian. Cara paling sederhana untuk memperbaiki: sesi terpisah untuk setiap proxy.
6. Matikan pengalihan otomatis di tempat yang tidak diperlukan. Di requests ini allow_redirects=False, di urllib3 redirect=False, di curl jangan menggunakan -L dan CURLOPT_FOLLOWLOCATION. Maka 3xx akan diproses secara manual, dan Anda sendiri yang memutuskan ke mana harus pergi selanjutnya. Inilah jalan alternatif yang diberikan oleh penulis requests dan urllib3.
7. Lakukan tes langsung untuk jebakan. Jalankan server HTTP sederhana yang mencetak semua header yang diterima, dan buat pengalihan ke server kedua yang sama. Jalankan melalui parser Anda dengan proxy skenario nyata, termasuk perubahan skema dari http ke https. Jika salah satu server melihat Proxy-Authorization, kebocoran terkonfirmasi pada kode Anda, bukan dalam teori.

Perangkap

• Gambar Docker hidup dengan kehidupannya sendiri. Anda memperbarui curl di host, tetapi parser berjalan di dalam kontainer dengan gambar dasar yang lama. Periksa di dalam kontainer: docker exec <kontainer> curl -V.
• curl konsol dan libcurl diperbarui dengan cara yang berbeda. CVE-2026-8927 tidak mempengaruhi curl konsol, sementara CVE-2026-6253 mempengaruhi keduanya. curl -V yang baru di terminal tidak memberikan informasi tentang perpustakaan yang digunakan untuk membangun PHP atau Python Anda.
• Digest tidak menyelamatkan. Ya, dalam Digest kata sandi tidak dikirim dalam teks terbuka. Namun, dalam CVE-2026-8927, penyerang tidak memerlukan kata sandi: header yang ditangkap diulang selama nonce masih berlaku.
• Kata sandi dalam URL nyaman, tetapi berbahaya. Kebocoran dalam requests muncul tepat ketika kredensial ditulis dalam alamat proxy seperti user:pass@host:port. Ini bukan alasan untuk meninggalkan format, tetapi alasan untuk menjaga perpustakaan tetap terbaru.
• Pengalihan mungkin tidak datang dari tujuan. Halaman captcha, banner persetujuan, pemendek tautan, dan CDN juga merespons 3xx. Semakin banyak "mengikuti tautan" di crawler, semakin luas permukaan serangan.

Bagaimana membatasi kerugian jika kata sandi tetap bocor

Sepenuhnya mengecualikan kebocoran tidak mungkin: besok akan ada CVE berikutnya. Oleh karena itu, penting untuk mengetahui berapa biaya satu kebocoran.

• Satu proyek, satu akses. Jangan simpan login umum untuk semua parser. Di ProxyCove, setiap proxy yang dibeli mendapatkan pasangan login dan kata sandi yang terpisah, sehingga akses yang bocor dari satu skrip tidak membuka trafik yang lainnya.
• Jangan simpan lebih banyak trafik pada satu akses daripada yang diperlukan. Isi sedikit demi sedikit sesuai kebutuhan, bukan untuk enam bulan ke depan.
• Awasi pengeluaran. Lonjakan trafik yang tajam tanpa peningkatan jumlah tugas adalah tanda pertama bahwa akses Anda digunakan oleh orang lain.
• Ganti kata sandi segera saat ada kecurigaan dan sesuai jadwal. Cara mengatur ini tanpa downtime, dijelaskan dalam panduan tentang rotasi kata sandi proxy.

Jenis proxy apa yang harus dipilih dan apa hubungannya dengan ini

Kebocoran tidak tergantung pada jenis proxy: bug ada di klien. Namun, biaya kebocoran tergantung. Proxy pusat data lebih murah per gigabyte, dan untuk parsing situs sederhana dengan pengalihan yang sering, masuk akal untuk menyimpannya terpisah dari trafik yang mahal. Proxy residensial harus diberikan untuk tugas di mana mereka benar-benar diperlukan, dan untuk itu membuat akses terpisah dengan pengalihan otomatis dimatikan. Proxy seluler, yang paling mahal per gigabyte, sebaiknya disimpan dalam kode dengan sedikit ketergantungan eksternal dan selalu dengan pemeriksaan versi perpustakaan pada setiap build.

Kesimpulan

Kata sandi untuk proxy dapat bocor tanpa peretasan, tanpa virus, dan tanpa kesalahan manusia: cukup dengan libcurl yang usang, pengalihan ke domain asing, dan penggunaan kembali koneksi. Daftar periksa singkat: curl dan libcurl dari 8.21.0, requests dari 2.31.0, urllib3 dari 1.26.19 atau 2.2.2, libsoup yang terbaru, sesi terpisah untuk setiap proxy, pengalihan di bawah kontrol, dan satu tes langsung untuk jebakan. Plus akses terpisah untuk setiap proyek, sehingga satu kebocoran hanya mengorbankan satu skrip, bukan seluruh saldo.