4 Ağustos 2026'da Mysk araştırmacıları, trafiği ayarlanmış proxy'yi atlayarak doğrudan cihazdan gönderen üç WebKit mekanizmasının analizini yayımladı. Etkilenmiş olan tüm iOS tarayıcıları, proxy moduyla birlikte Tor tarayıcıları ve Apple'ın kendi hizmeti olan iCloud Private Relay de dahil. Proxy etkin, arayüz başka bir ülke gösteriyor, ancak site sizin gerçek IP'nizi ve ev DNS çözümleyicinizi görüyor.
Bu, paranoyaklar için egzotik bir güvenlik açığı değil. Proxy üzerinden çalışan herkesin öğrenmesi gereken mimari bir kuralın açık bir gösterimi: uygulama düzeyindeki proxy, yalnızca bu uygulamanın ağ yığını üzerinden geçen trafiği korur. İşletim sistemi veya ayrı bir sistem hizmeti tarafından üretilen her şey, bu korumayı atlar.
Ne tür bir sızıntı var
Araştırma, sıradan bir durumla başladı: Psylo proxy tarayıcısının bir kullanıcısı, geliştiriciye DNS sızıntısı hakkında şikayette bulundu. Şikayet incelemesi, hepsi WebKit içinde bulunan üç bağımsız sızıntı kanalını ortaya çıkardı, bu nedenle sorun belirli bir uygulamada değil.
1. DNS önceden alma — en basit ve en rahatsız edici
Mekanizma: <link rel="dns-prefetch"> etiketi, tarayıcıdan bir ana bilgisayar adını önceden çözmesini isteyerek gelecekteki yüklemeyi hızlandırır. Sorun şu ki, WebKit iOS'ta bu tür adları cihazın normal DNS yolu üzerinden çözüyor, proxy üzerinden değil.
Masaüstü Safari, Safari 5'ten beri dns-prefetch desteği sunuyor, ancak iOS bu etiketi göz ardı ediyordu — iOS 26.0'a kadar (Eylül 2025). O zaman WebKit, eski örtük spekülatif DNS önceden alma (hata 285744) kaldırıldığı değişiklikle birlikte bunu etkinleştirdi.
Bunun nasıl istismar edildiği: Sayfa, her ziyaretçi için benzersiz ana bilgisayar adlarını bu etiketlere yerleştiriyor ve ardından isteklerin kendi yetkili DNS sunucusuna nasıl geldiğini izliyor — ziyaretçinin gerçek ağ adresinden. Hiçbir JavaScript, kullanıcı etkileşimi yok. Sayfayı açmak yeterli.
2. WebAuthn İlgili Kaynak İstekleri — passkey üzerinden sızıntı
Bu kanal, iOS 18.0'da ortaya çıktı. Bir site WebAuthn kimlik bilgilerini (yani passkey) talep ettiğinde, sistem https://<rpId>/.well-known/webauthn dosyasını kontrol eder — böylece alan adının gerçekten belirtilen relying party ile ilişkili olduğunu doğrular.
Anahtar detay: bu doğrulama isteği tarayıcının ağ yığından çıkmaz. Bunu, cihazdan doğrudan HTTPS isteği gönderen işletim sistemi kimlik bilgileri hizmeti gerçekleştirir. Tarayıcı içinde ayarlanan proxy, bunun varlığından haberdar değildir (hata 268426).
Yani, sayfanın bir passkey isteği başlatması yeterlidir — ve saldırganın sunucusu sizin gerçek IP'nizle bağlantı alır.
3. WebTransport — doğrudan cihazdan QUIC
En yeni kanal. new WebTransport(url) çağrısı, proxy yapılandırmasını atlayarak doğrudan cihazdan QUIC bağlantısı açar. WebTransport, WebKit'te uzun süre kapalıydı ve Mart 2026'da iOS 26.4'te halka açık olarak geldi (hatalar 260810 ve 303453).
Bu kiminle ilgili
Apple, iPhone'daki tüm tarayıcıların WebKit kullanmasını gerektiriyor. Dolayısıyla, WebKit'in proxy API'sine güvenen her iOS tarayıcısı etkileniyor — tüm iOS Tor tarayıcı sürümleri ve araştırmanın başladığı Psylo dahil. Ayrıca Safari ve iCloud Private Relay de etkileniyor.
Etki alanı dışında kalanlar — VPN uygulamaları. Bunlar sistem düzeyinde çalışır ve cihazın tüm trafiğini, sistem hizmetlerinin ürettiği trafiği de dahil olmak üzere, kapsar. Fark burada: sistem tünelinin "atlama" durumu yok. Ayrı bir istisna — Lockdown Modu etkin olan Silver güvenlik seviyesindeki Onion Browser: WebTransport üzerinden sızıntıya karşı duyarsızdır.
Geliştiriciler tarafından yanıtlar gelmeye başladı. Psylo 1.3.1'de tüm üç kanal kapatıldı: uygulama dns-prefetch ipuçlarını engelliyor (sayfa artık cihazın saldırganın kontrolündeki adları çözmesini sağlayamaz), WebTransport ve WebAuthn varsayılan olarak kapalı — bunları belirli anahtarlarla açmak mümkün. Yayınlandığı tarihte Apple, gelecekteki bir güncellemeyle sorunları gidermeyi planlıyordu; şirketin belirttiği kesin tarihler yoktu.
Bu neden şimdi gündeme geldi
Buradaki zaman çizelgesi dikkat çekici ve ayrı bir şekilde incelenmesi gereken bir konu — sorunun neden daha önce fark edilmediğini açıklıyor.
- Eylül 2024, iOS 18.0 — WebAuthn İlgili Kaynak İstekleri mekanizması ortaya çıkıyor. Sızıntı kanalı neredeyse iki yıldır mevcut ve bu süre zarfında kimse tarafından tartışılmıyor: passkey için alan adı kontrolü, bir güvenlik unsuru gibi görünüyor, bir adresi açığa çıkarma yöntemi olarak değil.
- Eylül 2025, iOS 26.0 — WebKit, mobil cihazlarda dns-prefetch desteğini etkinleştiriyor. Resmi olarak bu, yükleme hızını optimize etmek; gerçekte ise sayfa, cihazın proxy'yi atlayarak rastgele bir DNS adına başvurmasına olanak tanıyor.
- Mart 2026, iOS 26.4 — WebTransport halka açık olarak etkinleştiriliyor. Üçüncü kanal.
- Ağustos 2026 — Bir kullanıcının DNS sızıntısı hakkında yaptığı şikayet, hepsini birden ortaya çıkaran bir incelemeye yol açıyor.
Ortak nokta: Bu işlevlerin hiçbiri, de-anonimleştirme kanalı olarak düşünülmemiştir. Üçü de, çözümleme hızını artırma, passkey kontrolü, modern taşıma gibi platformun sıradan yetenekleridir. Sızıntı, yalnızca uygulama düzeyindeki proxy moduyla birleştiğinde ortaya çıkar ve bu nedenle yıllarca kimse bu niteliği test etmedi.
Pratikteki sonuç basit ve rahatsız edici: sızıntılar hakkında haber olmaması, onların olmadığı anlamına gelmez. Kendiniz düzenli olarak kontrol etmelisiniz, birinin inceleme yayımlamasını beklememelisiniz.
Kendinizi nasıl kontrol edebilirsiniz
Araştırmacılar, kamuya açık bir stand yayımladı — leaks.psylo.app. Bu, üç şeyi kontrol eder: normal HTTPS trafiği (sunucu hangi IP'yi ve hangi DNS çözümleyicilerini görüyor), WebTransport ve WebAuthn + dns-prefetch bağlantısı. Proxy etkinken açın ve sonucu beklediğiniz adresle karşılaştırın.
Ayrıca temel hijyeni kontrol etmek önemlidir — IP, DNS ve WebRTC adresinizin çalışma bağlantınızda eşleşip eşleşmediğini kontrol edin. Daha önce bunu sistematik olarak yapmadıysanız, incelememizle başlayın: proxy'yi DNS sızıntısı için nasıl kontrol edebilirsiniz.
Pratik sonuç: katman önemlidir
WebKit ile ilgili hikaye, herhangi bir proxy üzerinden çalışırken akılda tutulması gereken genel bir kuralın özel bir örneğidir, her platformda.
- Tarayıcıdaki proxy ≠ cihazdaki proxy. Uygulama içindeki yapılandırma, yalnızca uygulamanın kendisinin gönderdiği trafiği kapsar. Sistem hizmetleri, arka plan süreçleri, güncellemeler, push bağlantıları ve anlaşıldığı üzere, entegre passkey hizmeti — bunların hepsi kendi yollarını izler.
- Sızıntılar yalnızca "bilinen" yerlerde olmaz. WebRTC uzun zamandır gündemde ve bunun üstü kapatılmayı öğrendi. Ancak DNS önceden alma ve WebAuthn kontrolü — bunlar, de-anonimleştirme kanalı olarak hiç düşünülmemiş performans ve güvenlik işlevleridir. Tarayıcıların yeni özellikleri, düzenli olarak yeni geçiş yolları oluşturur.
- Platform güncellemesi, korumanızı sessizce bozabilir. Burada tarihlere bakıldığında bu açıkça görülüyor: DNS önceden alma, iOS 26.0'da "etkinleşti", WebTransport ise iOS 26.4'te. Kullanıcı hiçbir şey değiştirmedi, ancak sızıntı yüzeyi kendiliğinden büyüdü.
Bu, çoklu hesap yönetimi ve otomasyon için ne anlama geliyor
Birden fazla hesap yöneten veya veri toplayanlar için, buradaki risk soyut bir mahremiyet değil, oldukça finansaldır. Platformların dolandırıcılık önleme sistemleri sinyalleri karşılaştırır: eğer bir oturum bir IP bildiriyorsa, ancak ilişkili istek başka bir adresten ve ev çözümleyicisinden geliyorsa, bu hesapları birbirine bağlamak veya oturumu şüpheli olarak işaretlemek için yeterli bir sebep olur.
Pratik sonuçlar:
- Çalışma çoklu hesap oturumlarınızı proxy moduna sahip mobil tarayıcılarda yürütmeyin. Platform açıkları kapatmadığı sürece, iOS'taki uygulama katmanı tanım gereği güvenilir değildir.
- Trafiği sistematik olarak yönlendirin. Eğer görev mobil bir ortam ise, cihaz düzeyinde proxy kurmak veya ayrı bir geçit üzerinden yönlendirmek daha mantıklıdır, tarayıcı içindeki ayara güvenmek yerine.
- Her büyük işletim sistemi ve tarayıcı güncellemesinden sonra bağlantınızı kontrol edin. En azından çeyrek dönemlerde. Bunu kontrol listenize ekleyin, "bir şeyler ters gittiğinde" değil.
- Kullanmadığınız şeyleri kapatın. WebTransport ve WebAuthn, parsing veya SMM için çalışma profilinde neredeyse kesinlikle gerekli değildir — bunların kapatılması, üç sızıntı kanalından ikisini ortadan kaldırır.
IP'nin kalitesi ayrı bir değişken olarak kalır: hatta kapalı bir veri merkezi yapılandırmasında bile, veri merkezi adresi ASN ile kendini belli eder. Normal bir kullanıcı gibi görünmenin önemli olduğu senaryolar için konut proxy'leri çalışır, en sert dolandırıcılık önleme sistemlerine sahip mobil uygulamalar ve platformlar için ise mobil proxy'ler gerçek mobil operatörlerin IP'leri ile çalışır. Ancak, bir kısmı fiziksel olarak onun dışından giden trafik varsa, hiçbir proxy sınıfı sizi kurtaramaz — önce sızdırmazlık, sonra adres kalitesi.
Sonuç
Üç WebKit hatası — DNS önceden alma, WebAuthn İlgili Kaynak İstekleri ve WebTransport — "proxy etkin" ve "tüm trafik proxy üzerinden gidiyor" ifadelerinin iki farklı şey olduğunu gösterdi. iOS'ta bunlar arasındaki boşluk, sıradan bir web sayfasının tek bir JavaScript satırı olmadan bir Tor tarayıcısının ziyaretçisinin gerçek adresini öğrenebilecek kadar genişti.
Apple bir düzeltme hazırlarken, tek çalışan strateji — kontrol etmek, varsaymak değil. Test standını açın, adresleri karşılaştırın, gereksiz API'leri kapatın. Ve her büyük işletim sistemi güncellemesini, konfigürasyonun yeniden kontrol edilmesi gereken bir olay olarak değerlendirin. Mahremiyet ile onun yanılsaması arasındaki fark genellikle zamanında sorulmayan tek bir soruda yatmaktadır: "tüm trafik kesinlikle mi?". Ayrıca, adres dışında hangi sinyallerin sizi ifşa ettiğini anlamak da faydalıdır — bunu tarayıcı parmak izi koruma konusundaki makalemizde ele almıştık.