Güncellemeler
23 Mart 2023: Zaman çizelgesi güncellendi ve desteğin sonlandırılması, Chrome 117 sürümüne kadar geçerli olmayacak.
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 sahtekarlığı (CSRF) saldırılarına karşı 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 sona erecek bir desteği sonlanan deneme ile tanışın
- Bu sayede geliştiriciler, kullanımdan kaldırılma denemesi sırasında etkilenmeyecek seçili kaynaklar için zaman uzatımı isteyebilir.
- Yönetilen Chrome dağıtımlarının, kullanımdan kaldırma sürecini kalıcı olarak atlamasını sağlayacak bir Chrome politikasını kullanıma sunuyoruz. Chrome 92'de kullanılabilir.
Kullanımdan kaldırma denemesinin kullanımdan kaldırma kaydının etkisini azaltmak için daha fazla zamana ihtiyacınız varsa.
Kullanıcılarınız üzerinde yönetici denetiminiz varsa Chrome politikalarını kullanarak ö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 almak için arayın.
- 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, desteği sonlandırılan özelliklerle ilgili uyarılar göstererek kararlı sürüme dağıtıldı.
- 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. Bu sürümde, desteğin sonlandırılması denemesi de yer alacak.
- 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 de kullanımdan kaldırma işleminden etkilenmeyecektir.
- 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 kaydolabilir.
- Eylül 2021: Chrome 94, Kararlı kanalında kullanıma sunuldu. 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: Destek sonu denemesi Chrome 116'ya 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 bu özelliği, kullanımdan kaldırma denemesinden çıkmak için 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, 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ı Kaynak Paylaşımı (CORS) protokolünün kapsamını da genişletmektedir. Böylece web siteleri, rastgele istekler göndermelerine izin verilmeden önce özel ağlardaki sunuculardan açıkça hibe talebinde bulunmak zorundadır.
Ö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.
Desteği sonlandırma denemesi nedir?
Kullanımdan kaldırma denemeleri (eski adıyla tersine kaynak denemeleri), web özelliklerinin kullanımdan kaldırılmasını kolaylaştırmak için kullanılan bir kaynak deneme biçimidir. 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.
Kullanımdan kaldırma denemesi sırasında, desteği sonlandırılmış özellikler varsayılan olarak tüm web sitelerinde 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 ve kaynak denemeleriyle ilgili web geliştiricisi kılavuzuna göz atın.
Chrome'da neler değişiyor?
Chrome 94 sürümü
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. Denemeyi web sitenizde kaydettirme ve etkinleştirmeyle ilgili 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üzeltmenin uygulanabilmesine 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: $token
değ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]
),
güvenli bağlamlardan gönderilse bile Karma İç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'u kullanın.
- Yerleştirme ilişkisini tersine çevirin.
İki ucu da HTTPS'ye yükseltme
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.example
için bir TLS sertifikası alın.- Özel ağınızda,
intranet.example
adresini hedef sunucunun özel IP adresine çözümleyecek şekilde DNS'yi yapılandırın. - Özel sunucunuzu
intranet.example
için TLS sertifikasını kullanacak şekilde yapılandırın. Bu, kullanıcılarınızınhttps://intranet.example
adresindeki özel sunucuya erişmesine izin verir.
Ardından, istekleri başlatan web sitesini HTTPS'ye yükseltebilir ve önceki gibi istekte bulunmaya 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ş olduğunun 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 tam olarak kullanıma sunulduktan 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 yayınlanabilir. 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 gelecek aylarda spesifikasyonun geri kalanını uygulamak için çalışıyor. Gelişmeler için bizi takip edin.
Özel web sitelerinden yerel ana makine 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 da zaman içinde bu sürümlere yönelik desteğini 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 ön kontrol 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.
Kısacası, CORS ön kontrol isteği, sonraki isteğin niteliğini gösteren bazı Access-Control-Request-*
başlıkları içeren bir HTTP OPTIONS
isteğidir. Sunucu daha sonra 200 OK
adresine Access-Control-Allow-*
üstbilgileriyle yanıt vererek ayrıntılı erişim izni verip vermemeye karar verebilir.
Spesifikasyonda bu konuyla ilgili daha fazla bilgi 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ı