Proxy şifresinin curl, libsoup ve requests ile sızdırılması: kontrol

Proxy şifresi genellikle insanlardan saklanır: ekran görüntülerinde gösterilmez, git'e gönderilmez, ortam değişkenlerinde tutulur. Ancak 2026 yılında, bunu HTTP istemcisinin kendisinin verebileceği ortaya çıktı. Nisan–Temmuz arasında curl, libcurl ve libsoup'da birkaç güvenlik açığı ortaya çıktı; bu açılardan biri Proxy-Authorization başlığının yanlış proxy'e gitmesi ya da doğrudan hedef siteye gitmesidir. Aşağıda bu durumların hangi koşullarda gerçekleştiği ve kendi yığınınızı adım adım kontrol etme yöntemleri açıklanmaktadır.

Ne oldu: dört ayda dört sızıntı

Tüm bu hatalar benzer şekilde çalışıyor: istemci bir proxy'nin kullanıcı adı ve şifresini hatırlıyor ve yanlışlıkla bunları zincir boyunca gönderiyor.

CVE-2026-6253 (curl ve libcurl 7.14.1–8.19.0). Eğer http:// ve https:// için farklı proxy'ler ayarlandıysa, ilki şifre isterken, ikincisi istemiyorsa, curl şemayı değiştirdiğinde ilk proxy'nin kimlik bilgilerini ikinci proxy'ye gönderir. Veriler base64 formatında, yani aslında açık metin olarak gider. 29 Nisan 2026'da yayınlanan curl 8.20.0 ile düzeltildi. Konsol curl'ü de etkilenmektedir, sadece kütüphane değil.
CVE-2026-8927 (libcurl 7.12.0–8.20.0). Uygulama, birden fazla istek için tek bir handle kullanıyor, proxy'ler ortam değişkenlerinden alınıyor ve yetkilendirme Digest üzerinden yapılıyor. Bu durumda, Proxy-Authorization başlığı proxy A'dan proxy B'ye gidiyor ve bu da kendisini sizin yerinize koyabiliyor. 24 Haziran 2026'da yayınlanan curl 8.21.0 ile düzeltildi. Konsol curl etkilenmedi. CVE-2026-7168'de benzer bir hata tanımlanmıştır, tek fark proxy'nin nasıl seçildiğidir.
CVE-2026-12547 (libsoup, SoupAuthManager). libsoup, proxy kimlik bilgilerini host:port adresine bağlamadan önbelleğe alır. Proxy ayarları değiştiğinde (sistem parametreleri, WPAD), eski başlık yeni proxy'ye gider. 21 Temmuz 2026'da yayınlandı, düşük bir değerlendirme almıştır.
CVE-2026-66339 (libsoup, CONNECT tünelleri). HTTP proxy üzerinden CONNECT tüneli kurulduktan sonra libsoup, tünel içindeki sonraki HTTPS isteklerine Proxy-Authorization ekler. Bu başlık artık hedef sunucu tarafından görülmektedir. CVSS 6.5, 24 Temmuz 2026'da yayınlandı.

Tarih yeni değil. Python kütüphanesi requests versiyon 2.3.0'dan 2.31.0'a kadar (CVE-2023-32681) HTTPS'e yönlendirme sırasında Proxy-Authorization başlığı hedef sunucuya gidiyordu, eğer kullanıcı adı ve şifre doğrudan proxy URL'sine yazılmışsa. urllib3 versiyon 1.26.19 ve 2.2.2'de (CVE-2024-37891) manuel olarak ayarlanan başlık, yerleşik proxy desteği üzerinden değilse, başka bir alan adına yönlendirme sırasında kesilmiyordu.

Bunun proxy ile çalışmak için neden önemli olduğu

Ücretli bir proxy'de şifre, paraya eşittir. Kim bu şifreyi aldıysa, siz erişiminizi değiştirmeden önce trafiğinizi tüketir. Gigabayt başına ödeme yapıyorsanız, bu doğrudan bir maliyet, ve tüm ekip için ortak erişim varsa, sizin IP'niz üzerinden başkalarının eylemleri de söz konusu olur.

En savunmasız senaryolar şöyle görünmektedir:

Otomatik yönlendirmelerle çalışan parser'lar ve izleme araçları. Hedef site veya ara yönlendirme, isteği başlıkları toplayan bir alan adına yönlendirebilir.
Birden fazla proxy kullanan scriptler: farklı şemalar için farklı proxy'ler, tek bir bağlantıda istekler arasında proxy değiştirme, "şifreli proxy" ve "şifresiz proxy" karışımı.
Linux sunucularında uzun ömürlü süreçler, burada libcurl ve libsoup sistem paketleri ile gelir ve dağıtım ile birlikte güncellenir, sizin kodunuzla değil.
WPAD ve PAC dosyaları olan kurumsal ağlar: proxy uygulama müdahalesi olmadan değişir ve bu durum CVE-2026-12547'de tanımlanmıştır.

Yığınınızı nasıl kontrol edersiniz: adım adım

Gerçek libcurl sürümünü öğrenin, sadece konsol curl değil. curl -V komutu her ikisini de gösterir, ancak uygulama kendi kütüphane kopyası ile derlenmiş olabilir. Python için pycurl ile python -c "import pycurl; print(pycurl.version)" komutunu çalıştırın, PHP için curl_version() çağırın. Güvenli sınır: 8.21.0 ve üzeri ya da düzeltme yapılmış 8.20.1+, 8.16.1+ ve 8.14.2+ sürümleri.
Python bağımlılıklarını kontrol edin. pip show requests urllib3 komutunu çalıştırın. requests en az 2.31.0 ve urllib3 en az 1.26.19 (1.x dalı) veya 2.2.2 (2.x dalı) olmalıdır. Eğer bağımlılık transitif olarak geliyorsa, parser'ın çalıştığı aynı ortamda pip list komutuna bakın.
Linux'ta libsoup'u kontrol edin. Bu, GNOME uygulamaları, WebKitGTK ve bu yığın üzerinde derlenmiş her şey için geçerlidir. Paketi dağıtım yöneticisi üzerinden güncelleyin ve dağıtımınızın güvenlik bülteni ile karşılaştırın: Red Hat'teki bu CVE kartlarında etkilenenler RHEL 6–10 olarak belirtilmiştir.
Kodda başlık manuel ayarını bulun. Tüm depo içinde Proxy-Authorization ile arama yapın. Eğer başlık elle ayarlanıyorsa ve istemci proxy mekanizması üzerinden değilse (proxies= requests'te, ProxyManager urllib3'te, CURLOPT_PROXYUSERPWD libcurl'de), bu yönlendirme sırasında sızıntı adayıdır.
Proxy değiştirirken bağlantıların yeniden kullanılmasını bulun. Tek bir libcurl handle, bir requests oturumu veya bir HTTP ajanı üzerinden sırayla farklı proxy'ler ile giden istekler. En basit düzeltme: her proxy için ayrı bir oturum.
Gerekmediği yerlerde otomatik yönlendirmeleri kapatın. Requests'te bu allow_redirects=False, urllib3'te redirect=False, curl'de -L ve CURLOPT_FOLLOWLOCATION kullanmayın. Böylece 3xx'ler manuel olarak işlenir ve nereye gideceğinize kendiniz karar verirsiniz. İşte bu dolambaçlı yolu requests ve urllib3 yazarları sunmaktadır.
Canlı bir tuzak testi yapın. Tüm gelen başlıkları yazdıran basit bir HTTP sunucusu kurun ve onu ikinci bir benzer sunucuya yönlendirin. Gerçek bir senaryoyu, http'den https'ye şema değişikliği dahil olmak üzere, proxy ile parser'ınızdan geçirin. Eğer sunuculardan biri Proxy-Authorization'ı gördüyse, sızıntı sizin kodunuzda doğrulanmıştır, teoride değil.

Tuzağa düşme noktaları

Docker imajları kendi hayatlarını yaşar. Host'ta curl'ü güncellediniz, ancak parser eski temel imajla konteynerde çalışıyor. Kontrolü konteyner içinde yapmalısınız: docker exec <konteyner> curl -V.
Konsol curl ve libcurl farklı şekillerde güncellenir. CVE-2026-8927 konsol curl'ü etkilemez, ancak CVE-2026-6253 onu etkiler. Terminaldeki yeni curl -V komutu, PHP veya Python'unuzun hangi kütüphane ile derlendiği hakkında hiçbir şey söylemez.
Digest kurtarmaz. Evet, Digest ile şifre açık metin olarak gitmez. Ancak CVE-2026-8927'de saldırganın şifreye ihtiyacı yoktur: yakalanan başlık, nonce geçerli olduğu sürece tekrarlanır.
URL'de şifre kullanmak kolaydır, ancak tehlikelidir. requests'teki sızıntı, kimlik bilgileri user:pass@host:port formatında proxy adresine yazıldığında ortaya çıkıyordu. Bu formatı bırakmak için bir neden değil, ancak kütüphaneleri güncel tutmak için bir neden.
Yönlendirme hedeften gelmeyebilir. Captcha sayfaları, onay banner'ları, bağlantı kısaltıcıları ve CDN'ler de 3xx yanıtı verebilir. Crawl'ınızda "bağlantıları takip etme" ne kadar fazlaysa, saldırı yüzeyi o kadar genişler.

Eğer şifre sızarsa zararı nasıl sınırlarsınız

Sızıntıyı tamamen ortadan kaldırmak mümkün değildir: yarın bir başka CVE çıkabilir. Bu nedenle, bir sızıntının ne kadar maliyetli olduğu önemlidir.

Bir proje, bir erişim. Tüm parser'lar için ortak bir kullanıcı adı tutmayın. ProxyCove'da her satın alınan proxy ayrı bir kullanıcı adı ve şifre çiftine sahiptir, bu nedenle bir scriptin sızan erişimi diğerlerinin trafiğini açmaz.
Bir erişimde ihtiyaç duyduğunuzdan fazla trafik tutmayın. Görev için az az doldurun, altı ay önceden değil.
Tüketimi izleyin. Görev sayısında bir artış olmadan trafik artışı, erişiminizin başkaları tarafından kullanıldığının ilk işareti olabilir.
Şüphe durumunda hemen şifreyi değiştirin ve bir takvim oluşturun. Bunu duraksama olmadan nasıl yapacağınızı proxy şifre rotasyonu rehberinde ele aldık.

Hangi tür proxy seçilmeli ve bununla ne ilgisi var

Sızıntı, proxy türüne bağlı değildir: hata istemcide bulunur. Ancak sızıntının maliyeti değişir. Veri merkezi proxy'leri gigabayt başına daha ucuzdur ve sık yönlendirmeleri olan basit siteleri taramak için bunları pahalı trafikten ayrı tutmak mantıklıdır. Konut proxy'leri gerçekten ihtiyaç duyulan görevlere verilmelidir ve bunlar için ayrı erişimler oluşturulmalı ve otomatik yönlendirmeler kapatılmalıdır. Gigabayt başına en pahalı olan mobil proxy'leri, minimum dış bağımlılıkla kodda tutmak ve her derlemede kütüphane sürümlerini kontrol etmek önemlidir.

Sonuç

Proxy şifresi, bir hack olmadan, virüs olmadan ve insan hatası olmadan sızabilir: eski bir libcurl, başka bir alan adına yönlendirme ve yeniden kullanılan bir bağlantı yeterlidir. Kontrol listesi kısadır: curl ve libcurl 8.21.0 ve üzeri, requests 2.31.0 ve üzeri, urllib3 1.26.19 veya 2.2.2, güncel libsoup, her proxy için ayrı bir oturum, yönlendirmeler kontrol altında ve bir canlı tuzak testi. Ayrıca her proje için ayrı bir erişim, böylece bir sızıntı bir scriptin maliyetine mal olur, tüm bakiyeye değil.