Kullanıcının kendi yerel ağına erişen siteleri kısıtlamaya yönelik öneri

 (github.com/explainers-by-googlers)
1 puan yazan GN⁺ 2025-06-05 | 1 yorum | WhatsApp'ta paylaş
  • Chrome güvenlik ekibi, web sitelerinin yerel ağa erişim sorununu çözmek için yeni bir "yerel ağ erişim izni" sistemi öneriyor
  • Bugün herkese açık web siteleri, kullanıcının yazıcısı gibi yerel ağ cihazlarına izinsiz erişebilir veya saldırı girişiminde bulunabilir; bu öneri ise kullanıcı izni olmadan yerel ağ isteklerini engellemeyi hedefliyor
  • Mevcut Private Network Access(PNA)'den farklı olarak, preflight yerine kullanıcı izin onayı temelinde çalışıyor; böylece kullanıcı denetimini güçlendiriyor ve cihazlarda değişiklik yapmadan yalnızca site güncellemesiyle uyum sağlanabiliyor
  • Somut olarak, genel siteler yerel IP'lere, .local alan adlarına vb. fetch isteği gönderdiğinde, izin yoksa tarayıcı kullanıcıdan açık onay isteyen bir istem gösteriyor
  • Bu politika, güvenlik ve gizliliği güçlendirirken, IoT cihazı kurulumu gibi meşru kullanım senaryolarının da kullanıcı izniyle normal çalışmasını garanti ediyor

Önerinin özeti ve amacı

  • Chrome Secure Web and Network ekibi, genel web sitelerinin yerel ağa izinsiz erişimi sorununu çözmek için 'yerel ağ erişimi' izin modeline ilişkin ilk taslak tasarımı yayımladı
  • Daha önce ziyaret edilen siteler, kullanıcının yazıcısı, yönlendiricisi gibi yerel ağ cihazlarına karşı CSRF ve benzeri saldırılar deneyebiliyordu
  • Bundan sonra genel IP → yerel IP gibi adres alanları arasındaki sınırı aşan isteklerin tarayıcı tarafından engellenmesi ve ancak site bazında açık kullanıcı izni alındığında izin verilmesi öneriliyor

Arka plan ve farkları

  • Mevcut Private Network Access(PNA), preflight (ön istek/yanıt) temelli olduğu için cihaz tarafında da değişiklik gerektiriyor ve bu da benimsenmesini zorlaştırıyordu
  • Bu öneri ise yalnızca kullanıcı izin onayıyla çalışabildiği ve sadece sitenin küçük değişiklikler yapması yeterli olduğu için pratikte uygulanması ve yaygınlaşması daha kolay

Hedefler ve hedef dışı kalanlar

  • Hedefler
    • Drive-by web tabanlı zafiyetli cihaz ve sunucuların kötüye kullanılmasını engellemek
    • Yalnızca kullanıcı istediğinde ve izin verdiğinde, genel web sitelerinin yerel cihazlarla iletişim kurmasına izin vermek
  • Hedef dışı kalanlar
    • Mevcut yerel cihaz kurulum/denetim gibi makul kullanım akışlarını tamamen engellemek amaçlanmıyor
    • Yerel ağda HTTPS sorunları, karmaşık sertifika verme süreçleri gibi konular bu önerinin kapsamı dışında

Kullanım senaryoları

  • 1. senaryo: Kullanıcı istemediğinde, example.com 192.168.0.1 gibi bir adrese istek gönderirse tarayıcı izin isteyip, kullanıcı reddederse isteği engelliyor
  • 2. senaryo: IoT, yönlendirici vb. cihaz üreticisinin resmî web yapılandırma sayfası ilk erişimde kullanıcıdan izin alarak iletişime devam edebiliyor

Ayrıntılı tasarım

  • Adres alanı ayrımı:
    • IP ağ katmanı üç seviyeye ayrılıyor: loopback (yalnızca kendisi), local (yerel ağ içi), public (herkese açık)
    • .local alan adları, RFC1918/4193 özel IP'leri, RFC6762 link-local adları gibi çeşitli yerel ağ tanımlama ölçütleri buna dahil
  • Yerel ağ isteği: public→local, public→loopback, local→loopback gibi daha açık adres alanlarından iç ağa geçişte izin gerekiyor
    • Genel ağdan yerel/loopback ağa yapılan isteklerden, yerelden loopback'e giden isteklere kadar olanlar yerel ağ isteği sayılıyor
    • İstisna: local→local, loopback→herhangi bir adres gibi durumlar kısıtlama kapsamına girmiyor
  • İzin istemi:
    • Bir site yerel ağa istek gönderdiğinde ve izni yoksa, tarayıcı kullanıcıya izin verilip verilmeyeceğini soran bir istem gösteriyor
    • Reddedilirse istek engelleniyor, kabul edilirse istek devam ediyor
  • fetch API entegrasyonu: fetch çağrısında targetAddressSpace: "local" gibi bir seçenek belirtilerek net ayrım yapılabiliyor
    • Fetch spesifikasyonu DNS çözümlemesi olmadan yalnızca bağlantıyı tanımladığı için, bunun yerel ağ isteği olup olmadığı yeni bağlantı kurulduğunda belirleniyor
    • Yerel ağ isteklerine yalnızca güvenli bağlamlarda izin veriliyor; izin alınmamışsa istem gösteriliyor, izin verildiyse istek kabul ediliyor
    • Geliştiricilerin hedef adres alanını açıkça belirtebilmesi için fetch() seçeneklerine targetAddressSpace parametresi ekleniyor
    • Gerçek bağlanılan adres, seçenekle belirtilen alanla uyuşmazsa istek başarısız sayılıyor; böylece mixed content dolaşılması engelleniyor
  • HTML, WebRTC, ServiceWorker vb. için de aynı politika uygulanıyor
    • HTML belgeleri/worker'lara adres alanı değeri eklenerek kökene dayalı alan takibi yapılıyor
    • WebRTC içinde ICE Agent aday eklerken yerel/loopback adresleri için izin istemi kullanılıyor
    • İzinler Permissions API ile entegre ediliyor; böylece site mevcut izin durumunu sorgulayabiliyor
    • Varsayılan olarak yerel ağ erişimi yalnızca üst belgede mümkün; gerekirse Permissions Policy yetki devriyle alt çerçevelere aktarılabiliyor
  • Mixed content (HTTP/HTTPS) sorunu:
    • Güvenli olmayan bağlamda yerel ağa erişim denemeleri, HTTP tabanlı alt kaynak yükleme ve mixed content engellemesinin uygulandığı senaryolar ele alınıyor
    • Özel IP literal'leri, .local alan adları, targetAddressSpace belirtilmiş istekler vb. için mixed content yükseltme ve engelleme adımları atlanıyor; ardından bağlantı kurulduğunda yetkisiz kökenler engelleniyor
  • Çalışma örnekleri
    • Beklenmedik bir yerel ağ erişimi olduğunda kullanıcı izni reddederek yetkisiz isteği engelleyebiliyor
    • Üreticinin işlettiği cihaz denetim sayfası ise uygun özelliklerle (ör. targetAddressSpace="local") çağrı yaptığında, kullanıcı onayı varsa eskisi gibi çalışabiliyor

Alternatifler ve tartışmalar

  • PNA yaklaşımı:
    • Mevcut PNA, CORS preflight gerektiriyordu ancak pratik uygulama ve dağıtım açısından büyük zorluklar vardı
    • Bazı bölümlerde izin istemi ve mixed content istisnası tanıma yaklaşımı da önerildi
    • DNS sorunları ve cihazların ilgili özellikleri desteklememesi gibi nedenlerle pratik sınırlamalar bulunuyor
  • Tüm yerel ağ isteklerini engellemek: Basit olsa da kullanım senaryolarını bozması ve dolaşma maliyetini artırması nedeniyle gerçekçi görülmüyor
  • Mevcut durumu korumak: İşletim sistemleri uygulama bazında yerel ağ izinlerini yönetmeye başladığı için, tarayıcı düzeyinde yönetime duyulan ihtiyaç öne çıkıyor
  • Mixed content için alternatifler:
    • "Yalnızca güvenli yerel ağ alt kaynaklarına izin verme" gibi bağlantı yöntemlerinin güvenlik değerlendirmesi ve uygulama yükü tartışılıyor
    • Yanıt başlığı/meta etiketiyle adres alanı bildirme, HTML öğelerine özellik ekleme gibi seçenekler de değerlendiriliyor

Ek tartışma başlıkları

  • HTML alt kaynaklarında (iframe, img vb.) da adres alanı özelliği ekleme olasılığı tartışılıyor
  • İzin verildiğinde aşırı yetki aktarımı (transitivity) gibi konularda araştırma sonuçları yansıtılıyor
  • Ana çerçeve gezinmesinde yerel ağ erişimini sınırlama veya uyarı amaçlı geçiş ekranı gösterme
  • Yerel/loopback adreslerine giden tüm cross-origin istekleri geniş biçimde yerel ağ isteği sayma seçeneği de değerlendiriliyor
  • Ağ bazında daha ayrıntılı izin verme yöntemi araştırılıyor; farklı bir ağa geçildiğinde (başka bir konumdan bağlanınca) yeniden onay gerekip gerekmediği tartışılıyor

Güvenlik ve gizlilik değerlendirmeleri

  • İzin alan sitelerin kullanıcının ağındaki tüm cihazları keşfetme ve onlara erişme yetkisinin genişlemesi konusunda endişe var
  • Kullanıcının istemi kabul ederken neye izin verdiğini açıkça anlaması gerekiyor; bu model, preflight temelli yaklaşıma göre daha doğrudan bir denetim sunuyor
  • Önceden izin olmadan hiçbir yerel ağ isteğine izin verilmemesi, gizliliğin korunması açısından daha güçlü bir yaklaşım sunuyor

İlgili okumalar

1 yorum

 
GN⁺ 2025-06-05
Hacker News görüşleri

  • Bunu ilk gördüğümde bu özelliği beğendim; web sitelerinin rastgele yerel IP’lere (hatta herhangi bir IP’ye) HTTP isteği gönderebilmesi fikrinin başlı başına akıl almaz bir risk olduğunu düşünüyorum. Bu yüzden bunun bazı kurumsal uygulamaları veya entegrasyonları bozması umurumda değil. Kurumlar yönetim araçlarıyla bu özelliği yeniden etkinleştirebilir, normal kullanıcılar da ayarlardan açabilir. “Bu web sitesi yerel bir cihazı kontrol etmeye çalışıyor - izin ver/reddet” gibi bir açılır pencere yeterli olur.

    • Burada bir yanlış anlama var. Yerel ağ cihazları, keyfi web sitelerine karşı CORS sayesinde korunuyor. Mükemmel değil ama oldukça etkili bir yöntem. Sorun şu ki CORS yalnızca hedef sunucunun rızasına dayanıyor; yani sunucunun belirli başlıklarla o web sitesine erişim izni vermesi gerekiyor. Bu öneri, sunucu ve web sitesi iletişim kurmak istese bile kullanıcı onayı açıkça alınmadan bunun mümkün olmamasını sağlayarak çıtayı yükseltiyor. Eskiden sunucu ile web sitesinin anlaşması yeterli kabul ediliyordu, ama son dönemde Facebook gibi örneklerde web sitelerinin telefondaki uygulamalara gizlice erişmesi bu ilkeyi bozdu. Yani artık web sitesi ile yerel ağdaki sunucu, kullanıcının çıkarlarına aykırı şekilde birlikte hareket edebiliyor.

    • “Normal kullanıcılar açılır pencereden izin verip reddeder” görüşüne karşılık olarak, macOS’un şu anda uygulama bazında benzer izin istemleri yaptığı ama çoğu kullanıcının düşünmeden “izin ver”e bastığı söyleniyor. Site bazında yapılmasının da kullanıcıların dikkatini çok fazla artırmayacağı tahmin ediliyor.

    • Web sitelerinin neden yerel ağa erişmesi gerektiğini anlamıyorum. Bu sadece tamamen yeni bir güvenlik tehdidi modeli yaratıyor. Zaten daha iyi bir çözümün olmadığı gerçek kullanım durumları var mı, ondan da emin değilim.

  • Apple, Microsoft, Google gibi şirketlerin USB ve Bluetooth için de benzer bir yaklaşım benimsemesini isterdim. Son zamanlarda yüklediğim neredeyse her uygulama Bluetooth erişimi istiyor ve bu çok rahatsız edici. Uygulamanın erişebileceği Bluetooth cihaz kimlikleri manifest içinde belirtilse ve OS de erişimi yalnızca o cihazlarla sınırlasa harika olurdu. Örneğin Bose uygulaması sadece Bose cihazlarını görebilmeli. Ben de bir uygulamanın hangi izni istediğini görünce reddetmişliğim var. Kamera ya da GPS izinleri gibi, cihaz kimliği kaydı ve kullanıcı istemi olsa iyi olurdu. Bose örneğinde prefix bose.xxx olarak kaydedilir ve manifestte yalnızca bose.* erişimi istenir, OS de sadece bu kuralı uygular. USB ve yerel ağ cihazları için de benzer bir kimlik sistemi öneriliyor. OS’in uygulamaların ağ, USB ve Bluetooth üzerinde serbestçe tarama yapmasını engellemesi isteniyor.

    • Bir gün Apple’ın uygulamalara “sahte izin verme” seçeneği sunmasını umuyorum. Örneğin bir uygulama kişi listeme mutlaka ihtiyaç duyduğunu söylüyorsa, ona gerçeğinden ayırt edilemeyen rastgele bir liste gösterilebilir. Benzer şey GPS için de uygulanabilir. Hatta WhatsApp’ın kişileri paylaşmazsan kişi adlarını atamana izin vermediğini duymuştum.

    • GitHub üçüncü taraf uygulama entegrasyonlarında olduğu gibi, “ABC repolarımı görmek istiyor. Hangi repoları paylaşmak istiyorsun?” tarzı ayrıntılı seçim modelini tercih ederim.

  • Internet Explorer’ın eskiden zoning sistemiyle bu sorunu çözdüğü söyleniyor; ayrıntılar için MS belgesine bakılabilir.

    • İronik olan şu ki Chrome da Windows üzerinde kısmen IE’nin zone güvenlik yapısını kullanıyordu, ama bununla ilgili neredeyse hiç resmi belge yoktu.

    • Buna modern bir alternatifin olmaması saçma. Yerel ağ erişimi de kamera ve mikrofon gibi yalnızca özel bir izinle mümkün olmalı.

  • Web tarayıcılarının varsayılan olarak buna izin vermiş olmasına inanmak zor. Herhangi bir genel web sitesinin tüm dosya sistemime gizlice erişebilmesi korkunç bir güvenlik açığı olurdu; ama yerel ağ servislerine XHR ile doğrudan erişilebiliyor ve güvenlik yalnızca sunucu ayarlarına bırakılıyor. Bir geliştiriciyseniz, kendi geliştirme PC’nizde test için şirket içi bir web uygulaması çalıştırdığınızda (çok gevşek veya hiç olmayan güvenlik ayarlarıyla), facebook.com ya da google.com gibi siteler oraya doğrudan erişebilir. Evde de birçok insan yönlendirici güvenlik duvarına güvenip kimlik doğrulaması olmayan servisler çalıştırıyor; hepsinin CORS’u doğru yapılandırdığından emin olmak zor.

    • Herkesin CORS ayarlarını düzgün yaptığından gerçekten şüpheliyim. Pratikte yapılandırılmamış olma oranı neredeyse %0 değil, %100’e yakın olur.

  • Bu önerinin, Meta’nın kendi SDK’sını kullanarak yerel uygulamalarla web siteleri arasında localhost tabanlı bir numarayla kimlik kodu paylaşmasını engellemeye yardımcı olabileceği umuluyor. Özellikle Android’deki örnek için daha fazlası burada.

  • Web sitesine yerel ağa erişim izni vermek çok kaba ve gereksiz yere geniş bir yetki. Gerçekte bu izne ihtiyaç duyan sitelerin çoğu yalnızca tek bir yerel sunucuya erişmek istiyor. Tüm yerel ağı açmak en az ayrıcalık ilkesine aykırı. Üstelik çoğu kullanıcı localhost’ta ya da ağında neyin çalıştığını bilmiyor, dolayısıyla riskleri de anlayamıyor.

    • İnsanların çoğu localhost’ta veya ağda bir şeylerin çalıştığını bilmiyor; bu yüzden tarayıcı “http://localhost:3146” ya da “http://localhost:8089” adresine erişime izin verilsin mi?” diye sorsa bunun ne anlama geldiğini tahmin bile edemezler. Teknik terimler yerine “Bu site yerel ağ kaynaklarına erişmek istiyor” gibi daha sezgisel bir mesaj kullanmak daha iyi olur.

    • Bunu düzgün yapmak için aslında tarayıcı içinde bir güvenlik duvarı seviyesinde erişim kontrolü gerekir. Hangi CIDR, hangi port gibi ayrıntılı denetim sunan bir API iyi olurdu. Tarayıcı eklentileri de böyle bir firewall API kullanabilir ya da yerleşik arayüzde belirli makine (ör. router), LAN, VPN, Windows’taki private network gibi kapsamlar açıkça ayrıştırılıp her biri için ayrı erişim izni istenebilir.

  • Geçmişte NPAPI eklentileri ortadan kalktıktan sonra, birçok genel web sitesinin yerel yazılımla entegre olabilmek için localhost üzerinde HTTP sunucusu çalıştırmak zorunda kaldığı belirtiliyor. Eğer bu kullanım da fazla karmaşık hale getirilirse ciddi bir kullanım zorluğu doğar. Tarayıcı geliştiricilerinin NPAPI sonrası alternatif teknolojiler sağlaması gerekiyordu; şimdi ise artık çok geç deniyor.

    • Çoğu yazılım, OS düzeyinde protokol işleyici kaydedip örneğin bir web sitesi zoommtg:// gibi bir bağlantı verdiğinde tarayıcının bunu Zoom’a iletmesini tercih ediyor. Jupyter Notebook gibi çapraz kaynak isteği olmadan yerelde çalışan şeyler etkilenmez. OAuth2 oturum açma sonrası localhost URL’sine dönmek de sadece bir yönlendirme olduğu için sorun yaratmaz.

    • Bu tür bir yöntemin (yerel uygulamayla HTTP sunucusu üzerinden haberleşmenin) tamamen ortadan kalkması aslında daha iyi olabilir; çünkü bu yaklaşım uzun süredir güvenlik açıklarının kaynağı oldu.

    • Mozilla Native messaging gibi teknolojiler zaten var. Eklenti kurulumu gerekiyor ama NPAPI ile kıyaslandığında daha adil bir yaklaşım sayılabilir.

    • Eğer yerel yazılım “pull” modeliyle çalışsa, yani uygulama düzenli aralıklarla dışarıya istek gönderse, sunucu açmaya gerek kalmaz. Böylece web siteleri de başkalarının yerel ağını sağa sola tarayamaz; bu da iyi olur.

  • JavaScript’te cors seçeneği olmadan fetch veya POST isteği gönderildiğinde, CORS yalnızca yanıtın okunmasını engeller; isteğin kendisi yine tarayıcı tarafından gönderilir. Eğer yerel uygulama sunucuda proxy üzerinden CORS başlıkları ekleyebiliyorsa, herhangi bir site JS fetch/XMLHttpRequest ile erişebilir. Eklentiler de başlıkları değiştirerek CORS’u aşabilir. Başlıklarla oynayarak bunu atlatmak çok kolay; oysa CSP (Content Security Policy) pratikte aşılması çok zor, hatta neredeyse imkânsız. Facebook uygulaması da bugün hâlâ kendi CORS proxy sunucusunu çalıştırarak bu yapıyı kullanıyor. WebSocket de var; dolayısıyla Chrome’da localhost erişimini engelleyen bir bayrak olsa bile pek anlamlı olmaz. localhost’u tamamen engellemek ise daha da zararlı olur; çünkü birçok kullanıcı self-hosted yer imi, not, parola yöneticisi gibi araçlar için yerel sunucu kullanıyor. Bu kullanım senaryolarını engellemek mantıksız.

  • IPv6 ortamlarında sorun çıkabileceği söyleniyor. Gerçekten bir IPv6 adresinin kısmen yerel olup olmadığını ayırt etmenin bir yolu var mı diye soruluyor. Yoksa yalnızca IPv6 kullanılan ağlarda bu öneri sorun yaratabilir. IoT uygulamalarında buna benzer bir sorun yaşandığı anlatılıyor; IPv6 adresinin yerel olup olmadığını belirlemek zor olduğu için şimdilik tüm IPv6 trafiğini IPv4 yerel adreslerine yönlendirme yolu seçilmiş. IPv6 link-local adreslerin de normal uygulamalarda pek kullanılamadığı, dolayısıyla çok anlamlı olmadığı söyleniyor. .local alan adlarını yerel sunucu olarak kabul etmek de işletim sistemine göre farklı yorumlandığından tutarsız. Örneğin Raspberry Pi OS’te some_address mDNS ile çözülüyor ama someaddress.local çözülmüyor; Ubuntu 24.04’te ise someaddress.local çalışıyor, someaddress çalışmıyor. someaddress.local. da çalışmıyor. Ayrıca yerel ağ adresleri için private sertifika kullanamamak da sinir bozucu; “yerel adreslerde https kısıtı” meselesinin de mutlaka çözülmesi gerektiği vurgulanıyor.

    • IPv6’da da hâlâ “routable” kavramı var; dolayısıyla mantıksal olarak routing table düzeyinde site-local tanımı yapılabilir deniyor. Eski IPv4’te ikinci oktet site’ı, üçüncü oktet VLAN’ı temsil ederdi; IPv6’da seçenek daha fazla. Tüm IPv6 cihazlarının bir link-local adresi vardır (yerel VLAN). .local ise Apple, DNS vb. ad-adres eşleme terminolojisine ait olup IP adresiyle doğrudan ilgili değil. Yerel ağda https sertifikası almak da Let’s Encrypt’in DNS-01 doğrulaması, CNAME gibi yöntemlerle mümkün; zahmetli olsa da ücretsiz çözümler var ve acme.sh gibi araçlar öneriliyor. IPv4, IPv6, DNS, mDNS, Bonjour gibi kavramların daha net ayrılması gerektiği belirtiliyor. Paket yakalamanın bile ücretli olduğu dönemler hatırlatılarak bugünün çok daha iyi olduğu söyleniyor.

    • Bir endpoint açısından IPv6 adresinin “yerel” olup olmadığını anlamanın bir yolu olmadığı özellikle vurgulanıyor; çünkü IPv6’ın temel mantığı küresel yönlendirme. Yazıda Google’ın da “local” kavramını tartışırken bir noktada “private” tanımına kaydığı, yani orada da kavramsal karışıklık olduğu söyleniyor. HTTP uzantılarıyla standart dışı, CIDR tabanlı güvenlik sınırları üretmek tuhaf bir yaklaşım. Uygulamalar, herkese açık servis varsayımıyla güvenlik modelini kurmalı. .local mDNS standardında yer alsa da pratikte çoğu zaman göz ardı ediliyor.

  • Bunun bir an önce hayata geçmesini gerçekten istiyorum; özellikle HTTPS alan adlarından HTTP yerel sitelere erişim için bir mekanizma olmasını umuyorum. Akıllı ev, medya/eğlence gibi alanlarda çok iyi kullanım örnekleri var.