Güncellemeler
23 Mart 2023: Zaman çizelgesi güncellendi ve desteğin sonlandırılması Chrome 117'ye kadar gerçekleşmeyecek.
19 Ocak 2023: Zaman çizelgesi güncellendi ve desteğin sonlandırılması Chrome 114'e kadar gerçekleşmeyecek.
12 Ağustos 2022: Zaman çizelgesi güncellendi ve desteğin sonlandırılması Chrome 109'a kadar gerçekleşmeyecek.
10 Şubat 2022: Private Network Access: introducing preflights (Özel Ağ Erişimi: ön uçları tanıtıyoruz) başlıklı güncellenmiş makale yayınlandı.
25 Ağustos 2021: Zaman çizelgesi duyurusu güncellendi ve desteğin sonlandırılmasına yönelik bir deneme sürümü kullanıma sunuldu.
Chrome, Özel Ağ Erişimi spesifikasyonu kapsamında güvenli olmayan web sitelerinden özel ağ uç noktalarına erişimi kullanımdan kaldırıyor. Amaç, kullanıcıları özel ağlardaki yönlendiricileri ve diğer cihazları hedefleyen siteler arası istek sahteciliği (CSRF) saldırılarından korumaktır. Bu saldırıların yüz binlerce kullanıcıyı etkilediği ve saldırganların kullanıcıları kötü amaçlı sunuculara yönlendirmesine olanak tanıdığı tespit edildi.
Chrome'da aşağıdaki değişiklikler yapılacak:
- Chrome 94'ten itibaren, güvenli olmayan herkese açık web sitelerinden özel ağlara gönderilen istekler engellenecek.
- Chrome'da sonlandırılacak destek sonlandırma denemesi kullanıma sunuluyor
- Bu sayede geliştiriciler, kullanımdan kaldırma denemesi sırasında etkilenmeyecek seçili kaynaklar için ek süre isteyebilir.
- Yönetilen Chrome dağıtımlarının desteğin sonlandırılmasını kalıcı olarak atlamasına olanak tanıyacak bir Chrome politikası kullanıma sunuldu. Chrome 92'de kullanılabilir.
Destek sonu deneme sürümüne kaydolarak desteğin sonlandırılmasının etkisini azaltmak için daha fazla zamana ihtiyacınız varsa.
Kullanıcılarınız üzerinde yönetici denetimine sahipseniz Chrome politikalarını kullanarak bu özelliği yeniden etkinleştirebilirsiniz.
Yeni kısıtlamaların etkisini azaltmak için aşağıdaki stratejilerden birini kullanın:
- Web sitenizi ve gerekirse hedef sunucuyu HTTPS'ye yükseltin.
- Web sitenizi HTTPS'ye yükseltin ve WebTransport'ı kullanın.
- Yerleştirme ilişkisini tersine çevirin.
Zaman çizelgesi
- Kasım 2020: Yaklaşan değişiklikler hakkında geri bildirim çağrısı.
- Mart 2021: Geri bildirimler incelendikten ve iletişim kurulduktan sonra yapılacak değişiklikler duyuruldu. Spesifikasyonun adı CORS-RFC1918 yerine Özel Ağ Erişimi olarak değiştirildi.
- Nisan 2021: Chrome 90, kararlı sürüme kullanımdan kaldırılma uyarıları göstererek kullanıma sunuldu.
- Haziran 2021: Chrome 92, güvenli olmayan bağlamlardan özel ağ isteklerinin yapılmasını yasaklayarak Beta'ya kullanıma sunuldu. Geliştiricilerden, uyum sağlamak için daha fazla zaman isteğinde bulunan geri bildirimler aldıktan sonra desteğin sonlandırılması, Chrome 93'e ertelendi ve Desteğin Sonlandırılması Deneme sürümü ile birlikte sunuldu.
- Temmuz 2021: Geliştiricilerden gelen daha fazla geri bildirim sonrasında, desteğin sonlandırılması ve buna eşlik eden deneme Chrome 94'e ertelendi. Ayrıca, gizli web siteleri artık bu kullanımdan kaldırma işleminden etkilenmeyecek.
- Ağustos 2021: Chrome 94 Beta sürümünde kullanıma sunuldu. Web geliştiricileri, desteğin sonlandırılmasına yönelik deneme sürümüne kaydolmayı başlatabilir.
- Eylül 2021: Chrome 94 kararlı sürüme dağıtıldı. Web geliştiricileri, desteğin sonlandırılması denemesine kaydolmuş ve deneme jetonlarını üretime dağıtmış olmalıdır.
- Aralık 2022: Origin deneme anketi gönderildi ve geri bildirim alındı. Kullanımdan kaldırma denemesi Chrome 113'e kadar uzatıldı.
- Mart 2023: Kullanımdan kaldırma denemesi Chrome 116'ya kadar uzatıldı ve Chrome 117'de sona erecek şekilde ayarlandı. Chrome 114'te ilk kez kullanıma sunulması planlanan izin tabanlı alternatif bir mekanizma geliştirilmektedir.
- Mayıs 2023 (kesin olmamakla birlikte): İzin tabanlı mekanizma Chrome 114'te kullanıma sunulur. Web siteleri, desteği sonlandırma denemesinden çıkmak için bu özelliği kullanabilir.
- Eylül 2023: Chrome 117 kararlı sürüme dağıtılır ve desteği sonlandırma denemesi sona erer. Chrome, herkese açık ve güvenli olmayan bağlamlardan gelen tüm özel ağ isteklerini engeller.
Özel Ağ Erişimi nedir?
Özel Ağ Erişimi (eski adıyla CORS-RFC1918), web sitelerinin özel ağlardaki sunuculara istek gönderme özelliğini kısıtlar. Bu tür isteklere yalnızca güvenli bağlamlardan izin verilir. Spesifikasyon, Kaynaklar Arası Paylaşım (CORS) protokolünü de genişleterek web sitelerinin artık keyfi istek göndermesine izin verilmeden önce özel ağlardaki sunuculardan açıkça izin istemesi gerektiğini belirtir.
Özel ağ istekleri, hedef sunucunun IP adresinin, istek başlatıcının getirildiği IP adresinden daha özel olduğu isteklerdir. Örneğin, herkese açık bir web sitesinden (https://example.com) gizli bir web sitesine (http://router.local) veya gizli bir web sitesinden localhost'e yapılan bir istek.
Geri bildirim istiyoruz: Özel ağlar için CORS (RFC1918) başlıklı makalede daha fazla bilgi edinebilirsiniz.
Sonlanan özellik denemesi nedir?
Destek sonlandırma denemeleri (eski adıyla ters kaynak denemeleri), web özelliklerinin desteğinin sonlandırılmasını kolaylaştırmak için kullanılan bir kaynak denemesi türüdür. Destek sonlandırma denemeleri, Chrome'un belirli web özelliklerinin desteğini sonlandırmasına ve web sitelerinin bu özelliklere yeni bağımlılıklar oluşturmasını engellemesine olanak tanır. Aynı zamanda, mevcut bağımlı web sitelerine bu özelliklerden geçiş için ek süre tanır.
Desteği sonlandırılan özellikler, desteği sonlandırılma denemesi sırasında varsayılan olarak tüm web siteleri tarafından kullanılamaz. Etkilenen özellikleri kullanmaya devam etmesi gereken geliştiricilerin, desteğin sonlandırılması deneme sürümüne kaydolup belirtilen web kaynakları için jeton alması ve ardından web sitelerini bu jetonları HTTP üstbilgilerinde veya meta etiketlerde yayınlayacak şekilde değiştirmesi gerekir (bu durum hariç). Bir web sitesi, kaynağıyla eşleşen geçerli jetonlar sunuyorsa Chrome, desteği sonlandırılan özelliğin sınırlı bir süre boyunca kullanılmasına izin verir.
Daha fazla bilgi için Chrome'un kaynak denemelerini kullanmaya başlama başlıklı makaleyi inceleyin ve talimatlar için kaynak denemeleri ile ilgili web geliştirici kılavuzuna göz atın.
Chrome'da neler değişiyor?
Chrome 94
Chrome 94'ten itibaren, herkese açık güvenli olmayan bağlamların (genel olarak HTTPS üzerinden veya özel IP adresinden yayınlanmayan web siteleri) özel ağa istekte bulunması yasaktır. Bu özellik daha önce Chrome 92 için planlandığından, desteğin sonlandırılmasıyla ilgili mesajlarda hâlâ önceki aşamadan bahsediliyor olabilir.
Bu desteği sonlandırma işlemi, desteği sonlandırma denemesiyle birlikte gerçekleşir. Bu deneme, web sitelerinde desteği sonlandırılan özelliği kullanan web geliştiricilerine, jetonlara kaydolarak Chrome 116'ya kadar bu özelliği kullanmaya devam etme olanağı tanır. Web sitenizde deneme sürümünü kaydetme ve etkinleştirme talimatları için aşağıya bakın.
Kullanımdan kaldırma işlemini tamamen veya belirli kaynaklarda süresiz olarak devre dışı bırakmak için bir çift Chrome politikasından yararlanabilirsiniz. Bu sayede, kurumsal ayarlarda olanlar gibi yönetilen Chrome yüklemelerinde kesinti yaşanmaz.
Chrome 117
Desteği sonlandırılan sürüm denemesi sona erer. Tüm web siteleri, desteği sonlandırılan özellikten taşınmalı veya kullanıcılarının politikaları, özelliği etkinleştirmeye devam edecek şekilde yapılandırılmalıdır.
Geliştiriciler için önerilen işlemler
Etkilenen web siteleri için ilk adım, muhtemelen uygun bir düzeltme uygulanana kadar biraz zaman kazanmak olacaktır: Desteklenen sürümün kullanımdan kaldırılmasına ilişkin deneme sürümüne kaydolarak veya politikaları kullanarak. Ardından, önerilen işlem şekli, etkilenen her web sitesinin koşullarına bağlı olarak değişir.
Sonlanan özellik denemesine kaydolma
- Katılımcı kaynak için deneme jetonu almak üzere Güvenli olmayan bağlamlardan özel ağ erişimi kaynağı denemesi için Kaydol'u tıklayın.
- Yanıt başlığınıza kaynağa özgü
Origin-Trial: $tokendeğerini ekleyin. Bu yanıt başlığının yalnızca, oluşturulan doküman desteği sonlandırılan özelliği kullandığında ana kaynak ve gezinme yanıtlarında ayarlanması gerekir. Bu üstbilginin alt kaynak yanıtlarına eklenmesi işe yaramaz (zararlı olmasa da).
Bir dokümanın istek göndermesine izin verilmeden önce bu deneme etkinleştirilmesi veya devre dışı bırakılması gerektiğinden, <meta> etiketi aracılığıyla etkinleştirilemez. Bu tür etiketler yalnızca alt kaynak istekleri gönderildikten sonra yanıt gövdesinden ayrıştırılır. Bu durum, üçüncü taraf tarafından sunulan statik web siteleri (ör. github.io) gibi yanıt üstbilgilerinin kontrolünü elinde bulundurmayan web siteleri için bir sorun teşkil eder.
Daha fazla bilgi için Kaynak denemeleriyle ilgili web geliştirici kılavuzu başlıklı makaleyi inceleyin.
Politikaları etkinleştirme
Kullanıcılarınız üzerinde yönetici denetiminiz varsa aşağıdaki politikalardan birini kullanarak desteği sonlandırılan özelliği yeniden etkinleştirebilirsiniz:
Kullanıcılarınız için politikaları yönetme hakkında daha fazla bilgi için bu Yardım Merkezi makalesini inceleyin.
Yerel ana makineye erişme
Web sitenizin localhost'e istek göndermesi gerekiyorsa web sitenizi HTTPS'ye geçirmeniz yeterlidir.
http://localhost (veya http://127.*.*.*, http://[::1]) hedefleyen istekler, güvenli bağlamlardan gönderilse bile karma içerik tarafından engellenmez.
WebKit motorunun ve bu motoru temel alan tarayıcıların (özellikle Safari) buradaki W3C Karma İçerik spesifikasyonundan saptığını ve bu talepleri Karma İçerik olarak yasakladığını unutmayın. Ayrıca, özel ağ erişimini de uygulamazlar. Bu nedenle, web siteleri bu tür tarayıcıları kullanan istemcileri web sitesinin düz metin HTTP sürümüne yönlendirmek isteyebilir. Bu durumda, bu tür tarayıcılar localhost'a istek göndermeye devam edebilir.
Özel IP adreslerine erişme
Web sitenizin özel IP adresindeki bir hedef sunucuya istek göndermesi gerekiyorsa başlatıcı web sitesini HTTPS'ye yükseltmek yeterli olmaz. Karma içerik, güvenli bağlamların düz metin HTTP üzerinden istek göndermesini engeller. Bu nedenle, yeni güvenli hale getirilen web sitesi istek gönderemez. Bu sorunu çözmenin birkaç yolu vardır:
- Her iki ucu da HTTPS'ye yükseltin.
- Hedef sunucuya güvenli bir şekilde bağlanmak için WebTransport'ı kullanın.
- Yerleştirme ilişkisini tersine çevirin.
Her iki ucu da HTTPS'ye yükseltin
Bu çözüm, kullanıcıların DNS çözümü üzerinde kontrol sahibi olmayı gerektirir. Örneğin, intranet bağlamlarında veya kullanıcıların alan adı sunucularının adreslerini kontrolünüzdeki bir DHCP sunucusundan alması durumunda bu çözüm kullanılabilir. Ayrıca herkese açık bir alan adına sahip olmanız gerekir.
Özel web sitelerini HTTPS üzerinden yayınlamayla ilgili temel sorun, ortak anahtar altyapısı sertifika yetkililerinin (PKI CA) yalnızca herkese açık alan adlarına sahip web sitelerine TLS sertifikası sağlamasıdır. Bu sorunu gidermek için:
- Herkese açık bir alan adı (ör.
intranet.example) kaydedin ve bu alan adını seçtiğiniz herkese açık bir sunucuya yönlendiren DNS kayıtları yayınlayın. intranet.exampleiçin bir TLS sertifikası alın.- Özel ağınız içinde, DNS'yi
intranet.exampleadresini hedef sunucunun özel IP adresiyle çözecek şekilde yapılandırın. - Özel sunucunuzu
intranet.exampleiçin TLS sertifikasını kullanacak şekilde yapılandırın. Bu sayede kullanıcılarınızhttps://intranet.exampleadresindeki özel sunucuya erişebilir.
Ardından, istekleri başlatan web sitesini HTTPS'ye yükseltebilir ve istekleri eskisi gibi yapmaya devam edebilirsiniz.
Geleceğin koşullarına uyum sağlayan bu çözüm, özel ağınızdaki uçtan uca şifrelemenin kullanımını genişleterek ağınıza duyduğunuz güveni azaltır.
WebTransport
Bu çözüm, kullanıcılarınızın DNS çözümü üzerinde kontrol sahibi olmanızı gerektirmez. Bunun için hedef sunucunun minimum bir WebTransport sunucusu (bazı değişiklikler yapılmış HTTP/3 sunucusu) çalıştırması gerekir.
WebTransport'u ve sertifika sabitleme mekanizmasını kullanarak güvenilir bir CA tarafından imzalanmış geçerli bir TLS sertifikasının bulunmamasını atlayabilirsiniz. Bu sayede, örneğin kendi kendine imzalanmış sertifikası olan özel cihazlara güvenli bağlantılar kurulabilir. WebTransport bağlantıları, iki yönlü veri aktarımına izin verir ancak getirme isteklerine izin vermez. Bu yaklaşımı, web uygulamanızın bakış açısından bağlantı üzerinden HTTP isteklerini şeffaf bir şekilde proxy'lemek için bir hizmet çalışanıyla birleştirebilirsiniz. Sunucu tarafında, ilgili bir çeviri katmanı WebTransport mesajlarını HTTP isteklerine dönüştürebilir.
Bunun oldukça fazla iş gerektirdiğinin farkındayız ancak WebRTC'nin üzerine kod yazmaktan çok daha kolay olacaktır. Ayrıca, gerekli yatırımın bir kısmının yeniden kullanılabilir kitaplıklar olarak uygulanmasını umuyoruz. Ayrıca, platform zaman içinde HTTPS kullanımını daha güçlü şekillerde teşvik etmeye yönelik adımlar attığından, güvenli olmayan bağlamların web platformu özelliklerine erişimini kaybetme olasılığının artması nedeniyle bu değişikliğin özellikle değerli olduğunu düşünüyoruz. Özel Ağ Erişimi'nden bağımsız olarak, bu muhtemelen akıllıca bir yatırım olacaktır.
HTTP/3 üzerinden WebTransport'ın, Chrome 96'da (kaynak denemesi başladı) anahtar paylaşımına ve diğer standart altı güvenlik uygulamalarına karşı koruma sağlayan azaltıcı önlemlerle birlikte kullanıma sunulmasını bekliyoruz. Bu önlemler arasında şunlar yer alır:
- Sabitlenmiş sertifikalar için kısa bir maksimum geçerlilik süresi.
- Kötüye kullanıma maruz kalan belirli anahtarları iptal etmek için tarayıcıya özgü bir mekanizma.
WebTransport'ın tam olarak kullanıma sunulmasından sonra en az iki aşama tamamlanana kadar güvenli bağlam kısıtlamasını kullanıma sunmayacağız. Gerekirse desteğin sonlandırılması denemesi uzatılır.
Ters yerleştirme
Bu çözüm, ağ üzerinde herhangi bir yönetici kontrolü gerektirmez ve hedef sunucu HTTPS çalıştıracak kadar güçlü olmadığında kullanılabilir.
Özel alt kaynakları herkese açık bir web uygulamasından almak yerine, uygulamanın iskeleti özel sunucudan sunulabilir. Bu iskelet daha sonra tüm alt kaynaklarını (ör. komut dosyaları veya resimler) CDN gibi herkese açık bir sunucudan alır. Sonuç olarak oluşturulan web uygulaması, aynı kaynak olarak kabul edildiğinden özel sunucuya istek gönderebilir. Hatta özel IP'lere sahip diğer sunuculara (localhost hariç) istekte bulunabilir ancak bu durum uzun vadede değişebilir.
Özel sunucuda yalnızca bir iskelet barındırarak, herkese açık bir web uygulamasını güncellerken yaptığınız gibi herkese açık sunucuya yeni kaynaklar göndererek web uygulamasını güncelleyebilirsiniz. Öte yandan, ortaya çıkan web uygulaması güvenli bir bağlam olmadığından web'in daha güçlü özelliklerinden bazılarına erişemez.
Gelecek için planlar
Özel ağ isteklerini güvenli bağlamlarla kısıtlamak, Özel Ağ Erişimi'ni kullanıma sunmanın yalnızca ilk adımıdır. Chrome, önümüzdeki aylarda spesifikasyonun geri kalanını uygulamak için çalışıyor. Gelişmeler için bizi takip edin.
Özel web sitelerinden localhost erişimini kısıtlama
Chrome 94'teki değişiklikler yalnızca özel IP adreslerine veya localhost'a erişen herkese açık web sitelerini etkiler. Özel Ağ Erişimi spesifikasyonu, özel web sitelerinden localhost'a yapılan istekleri de sorunlu olarak sınıflandırır. Chrome, zaman içinde bu sürümlerin desteğini de sonlandıracaktır. Ancak birçok özel web sitesinin alan adı olmadığından bu durum, kullanımdan kaldırılan deneme jetonlarının kullanımını zorlaştırarak biraz farklı zorluklar ortaya çıkarır.
CORS uçuş öncesi istekleri
Özel Ağ Erişimi'nin ikinci kısmı, güvenli bağlamlardan başlatılan özel ağ isteklerini CORS ön uç istekleriyle kontrol etmektir. Buradaki amaç, istek güvenli bir bağlamda başlatılmış olsa bile hedef sunucunun, başlatıcıya açık bir izin vermesini istemektir. İstek yalnızca bağış başarılı olursa gönderilir.
Özetlemek gerekirse, CORS ön uç isteğinde, sonraki isteğinin niteliğini belirten bazı Access-Control-Request-* üstbilgileri taşıyan bir HTTP OPTIONS isteği gönderilir. Sunucu daha sonra 200 OK isteğine Access-Control-Allow-* başlıklarıyla yanıt vererek ayrıntılı erişim izni verip vermeyeceğine karar verebilir.
Bu konuda daha fazla bilgiyi özellikte bulabilirsiniz.
Gezinme getirmelerini kısıtlama
Chrome, özel ağlara gönderilen alt kaynak istekleriyle ilgili desteği sonlandırıp bu istekleri engellemeye başlayacaktır. Bu durum, özel ağlara yapılan gezinmeleri etkilemez. Bu gezinmeler CSRF saldırılarında da kullanılabilir.
Özel Ağ Erişimi spesifikasyonu, iki tür getirme arasında ayrım yapmaz. Bu getirmeler sonunda aynı kısıtlamalara tabi olur.
Markus Spiske tarafından Unsplash'ta çekilen kapak fotoğrafı