Güncellemeler
23 Mart 2023: Zaman çizelgesi güncellendi ve Chrome 117 sürümüne kadar kullanımdan kaldırma işlemi gerçekleşmeyecek.
19 Ocak 2023: Zaman çizelgesi güncellendi ve Chrome 114 sürümüne kadar kullanımdan kaldırılma işlemi olmayacak.
12 Ağustos 2022: Zaman çizelgesi güncellendi ve Chrome 109 sürümüne kadar kullanımdan kaldırma işlemi gerçekleşmeyecek.
10 Şubat 2022: Özel Ağ Erişimi: Ön kontroller tanıtılıyor başlıklı makalede güncellenmiş bir makale yayınlandı
25 Ağustos 2021: Zaman çizelgesi duyurusu güncellendi ve desteği sonlandırma denemesinin kullanıma sunulması.
Chrome, Özel Ağ Erişimi spesifikasyonunun bir parçası olarak, 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 yüz binlerce kullanıcıyı etkileyerek saldırganların kullanıcıları kötü amaçlı sunuculara yönlendirmesine neden olmuştur.
Chrome aşağıdaki değişiklikleri sunacak:
- Chrome 94'ten itibaren, güvenli olmayan herkese açık web sitelerinden özel ağlara yapılan istekleri engelleme.
- Chrome'da sona erecek olan kullanımdan kaldırma deneme sürümü kullanıma sunuluyor
- Geliştiricilerin, seçilen kaynaklar için zaman uzatma isteğinde bulunmalarına olanak tanır. Bu süre, desteğin sonlandırılmasına dair deneme süresinden etkilenmez.
- Yönetilen Chrome dağıtımlarının, kullanımdan kaldırma sürecini kalıcı olarak atlatmasına olanak tanıyan bir Chrome politikasıyla tanışın. Chrome 92 sürümünde kullanılabilir.
Desteğin sonlandırılmasının etkisini azaltmak için daha fazla zamana ihtiyacınız varsa kullanımdan kaldırma denemesi için kaydolun.
Kullanıcılarınız üzerinde yönetici denetiminiz varsa 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 HTTPS'ye ve gerekirse hedef sunucuya yükseltin.
- Web sitenizi HTTPS'ye yükseltin ve WebTransport'u kullanın.
- Yerleştirme ilişkisini tersine çevirin.
Zaman çizelgesi
- Kasım 2020: Yakında yapılacak değişiklikler hakkında geri bildirim almak için arayın.
- Mart 2021: Geri bildirimleri inceledikten ve kullanıcılara ulaşmayı tamamladıktan sonra yapılacak değişiklikler duyurulacaktır. Spesifikasyon, CORS-RFC1918 iken Özel Ağ Erişimi olarak yeniden adlandırılmıştır.
- Nisan 2021: Chrome 90, Mevcut ürün kanalında kullanıma sunuldu ve kullanımdan kaldırma uyarılarıyla karşılaştı.
- Haziran 2021: Chrome 92, güvenli olmayan bağlamlardan özel ağ istekleri sunulmasına izin vermeyerek Beta sürümünde kullanıma sunulur. Düzenleme için daha fazla zaman isteyen geliştiricilerden geri bildirim aldıktan sonra, kullanımdan kaldırma sürecini Chrome 93'e erteledik ve Desteğin sonlandırılması Denemesi ile birlikte sunulacak.
- Temmuz 2021: Geliştiricilerden daha fazla geri bildirim aldıktan sonra, kullanımdan kaldırma ve beraberindeki deneme Chrome 94 sürümüne ertelenmiştir. Ayrıca, gizli web siteleri artık kullanımdan kaldırma işleminden etkilenmeyecektir.
- Ağustos 2021: Chrome 94, Beta sürümünde kullanıma sunuluyor. Web geliştiricileri, kullanımdan kaldırma deneme sürümüne kaydolmaya başlayabilir.
- Eylül 2021: Chrome 94, Mevcut ürün kanalında kullanıma sunuldu. Web geliştiricilerinin kullanımdan kaldırılan denemeye kaydolmuş ve deneme jetonlarını üretime dağıtmış olması gerekir.
- Aralık 2022: Kaynak denemesi anketi gönderildi ve geri bildirim alındı. Desteği sonlandırılan deneme süresi, Chrome 113 sürümüne kadar uzatılmıştır.
- Mart 2023: Desteği sonlandırma denemesi Chrome 116'ya uzatıldı ve Chrome 117'de sona erecek şekilde ayarlandı. Chrome 114'teki ilk sürümü hedefleyen izne dayalı alternatif bir mekanizma geliştirme aşamasındadır.
- Mayıs 2023 (kesin değil): İzne dayalı mekanizma Chrome 114'te kullanıma sunuldu. Web siteleri bunu, desteği sonlandırma denemesinden çıkmak için kullanabilir.
- Eylül 2023: Chrome 117, Mevcut ürün kanalında kullanıma sunuldu ve kullanımdan kaldırma deneme süresi sona erecek. 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. Yalnızca güvenli bağlamlardan gelen isteklere izin verir. Spesifikasyon ayrıca Merkezler Arası Kaynak Paylaşımı (CORS) protokolünün kapsamını genişletmektedir. Böylece web sitelerinin rastgele istekler göndermesine izin verilmeden önce özel ağlardaki sunuculardan açık bir şekilde hibe talebinde bulunmaları gerekmektedir.
Özel ağ istekleri, hedef sunucusunun IP adresi, isteği başlatanın alındığı adresten daha gizli olan isteklerdir. Örneğin, herkese açık bir web sitesinden (https://example.com) özel bir web sitesine (http://router.local) veya özel bir web sitesinden localhost'a yapılan bir istek.
Geri bildirim istendi: Özel ağlar için CORS (RFC1918) başlıklı makaleden daha fazla bilgi edinebilirsiniz.
Kullanımdan kaldırma denemesi nedir?
Kullanımdan kaldırma denemeleri (eski adıyla ters kaynak denemeleri), web özelliklerinin kullanımdan kaldırılmasını kolaylaştırmak için kullanılan bir kaynak deneme türüdür. Kullanımdan kaldırma denemeleri, Chrome'un belirli web özelliklerini kullanımdan kaldırmasına ve web sitelerinin bunlara yeni bağımlılıklar oluşturmasını önlerken aynı zamanda mevcut bağımlı web sitelerine bunları taşımaları için ek zaman tanımasına olanak tanır.
Kullanımdan kaldırma denemesi sırasında, kullanımdan kaldırılan özellikler varsayılan olarak tüm web sitelerinde kullanılamaz. Etkilenen özellikleri kullanmaya devam etmesi gereken geliştiricilerin desteği sonlandırma denemesine kaydolmaları ve belirtilen web kaynakları için jetonları edinmeleri, ardından web sitelerini bu jetonları HTTP üst bilgileri veya meta etiketlerde sunacak şekilde değiştirmeleri gerekir (bu durum hariç). Bir web sitesi kaynaklarıyla eşleşen geçerli jetonlar sunarsa Chrome, kullanımdan kaldırılan özelliğin kullanımına sınırlı bir süre izin verir.
Daha fazla bilgi edinmek için Chrome'un kaynak denemelerini kullanmaya başlama başlıklı makaleye ve kaynak denemeleriyle ilgili web geliştiricisi kılavuzuna göz atın.
Chrome'daki değişiklikler
Chrome 94
Chrome 94'ten itibaren, genel güvenli olmayan bağlamların (genel olarak HTTPS üzerinden veya özel bir IP adresinden yayınlanmayan web siteleri) özel ağa istekte bulunmasına izin verilmemektedir. Bu durum daha önce Chrome 92 için planlanmıştı. Bu nedenle, kullanımdan kaldırma mesajlarında önceki aşamadan bahsediliyor olabilir.
Bu kullanımdan kaldırma işlemiyle birlikte, web sitelerinde desteği sonlandırılan özelliği kullanan web geliştiricilerinin jetonlara kaydolarak Chrome 116'ya kadar bu özelliği kullanmaya devam etmelerine olanak tanıyan bir desteği sonlandırma denemesi sunulur. Web sitenizde deneme sürümünü nasıl kaydedeceğiniz ve etkinleştireceğinizle ilgili talimatlar için aşağıdaki bilgilere 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, yönetilen Chrome yüklemeleri (ör. şirket ayarlarındakiler) kesinti yaşamaz.
Chrome 117
Kullanımdan kaldırma deneme süresi sona erer. Tüm web sitelerinin kullanımdan kaldırılan özelliğin kaldırılması veya kullanıcı politikalarının bu özelliği etkinleştirmeye devam edebilmesi için yapılandırılması gerekir.
Önerilen geliştirici işlemleri
Etkilenen web siteleri için atılacak ilk adım, büyük olasılıkla uygun bir düzeltmenin kullanıma sunulmasına kadar biraz zaman alacaktır. Bunun için kullanımdan kaldırma deneme sürümüne kaydolma veya politikaları kullanma gibi yöntemler uygulanabilir. Daha sonra önerilen işlem yolu, etkilenen her web sitesinin durumuna göre değişiklik gösterir.
Kullanımdan kaldırma deneme sürümüne kaydolma
- Katılımcı kaynak için deneme jetonu almak amacıyla güvenli olmayan bağlamlardan Özel Ağ Erişimi kaynak denemesine katılmak için Kaydol'u tıklayın.
- Kaynağa özgü
Origin-Trial: $tokendeğerini yanıt üst bilginize ekleyin. Bu yanıt üstbilgisi, yalnızca sonuç belgesi kullanımdan kaldırılan özelliği kullandığında ana kaynak ve gezinme yanıtlarında ayarlanmalıdır. Bu başlığı alt kaynak yanıtlarına eklemek yararsızdır (ancak zararsızdır).
Bir dokümanın istekte bulunmasına izin verilmesi için bu denemenin 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, üçüncü bir tarafın sunduğu github.io statik web siteleri gibi yanıt üst bilgilerinin kontrolünde olmayan web siteleri için bir zorluk oluşturur.
Daha fazla bilgi için Kaynak denemeleriyle ilgili web geliştiricisi kılavuzunu inceleyin.
Politikaları etkinleştirin
Kullanıcılarınız üzerinde yönetici denetiminiz varsa kullanımdan kaldırılmış özelliği aşağıdaki politikalardan birini kullanarak yeniden etkinleştirebilirsiniz:
Kullanıcılarınız için politikaları yönetme hakkında daha fazla bilgi edinmek için bu yardım merkezi makalesini inceleyin.
Localhost'a erişme
Web sitenizin localhost'a istek göndermesi gerekiyorsa web sitenizi HTTPS'ye yükseltmeniz yeterlidir.
http://localhost (veya http://127.*.*.*, http://[::1]) hedefleyen istekler, güvenli bağlamlardan olsa bile Karma İçerik tarafından engellenmez.
WebKit motorunun ve bunu temel alan tarayıcıların (en önemlisi, Safari) buradaki W3C Karma İçerik spesifikasyonundan saptığını ve bu istekleri Karma İçerik olarak yasakladığını unutmayın. Ayrıca, Özel Ağ Erişimi 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 tür tarayıcılar, localhost'a istekte bulunmaya devam edebilir.
Özel IP adreslerine erişme
Web sitenizin özel bir IP adresindeki hedef sunucuya istek göndermesi gerekiyorsa, başlatıcı web sitesini HTTPS'ye yükseltmek işe yaramaz. Karma İçerik, güvenli bağlamların düz metinli HTTP üzerinden istekte bulunmasını önler. Bu nedenle, güvenliği yeni sağlanan web sitesi yine de istek yapamaz. Bu sorunu çözmenin birkaç yolu vardır:
- Yükseltmenin her iki ucu da HTTPS'ye ayarlanır.
- 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ükselt
Bu çözüm, kullanıcıların DNS çözümlemesi üzerinde kontrol sahibi olmayı gerektirir. Örneğin, intranet bağlamlarındaki durumlar veya kullanıcıların, kontrolünüzdeki bir DHCP sunucusundan ad sunucularının adreslerini alıp almadığı durumlar buna örnek olarak gösterilebilir. Ayrıca, herkese açık bir alan adına sahip olmanız da gereklidir.
Özel web sitelerini HTTPS üzerinden sunmayla ilgili temel sorun, ortak anahtar altyapı sertifikası yetkililerinin (PKI CA) yalnızca herkese açık alan adlarına sahip web sitelerine TLS sertifikaları sağlamasıdır. Bu sorunu çözmek için:
- Genel bir alan adı (örneğin,
intranet.example) kaydedin ve bu alan adını tercih ettiğiniz herkese açık bir sunucuya yönlendiren DNS kayıtlarını yayınlayın. intranet.exampleiçin bir TLS sertifikası edinin.- Özel ağınızın içinde, DNS'yi
intranet.examplealanını hedef sunucunun özel IP adresine çözümleyecek şekilde yapılandırın. - Özel sunucunuzu,
intranet.exampleiçin TLS sertifikasını kullanacak şekilde yapılandırın. Bu, kullanıcılarınızınhttps://intranet.exampleadresindeki özel sunucuya erişmesine olanak tanır.
Ardından, istekleri başlatan web sitesini HTTPS'ye yükseltebilir ve eskisi gibi istekte bulunmaya devam edebilirsiniz.
Bu çözüm geleceğe hazırdır ve ağınıza duyduğunuz güveni azaltarak özel ağınızda uçtan uca şifreleme kullanımını artırır.
WebTransport
Bu çözüm, kullanıcılarınızın DNS çözümlemesi üzerinde denetim gerektirmez. Hedef sunucunun minimum düzeyde WebTransport sunucusu (bazı değişikliklerle HTTP/3 sunucusu) çalıştırmasını gerektirir.
WebTransport ve onun sertifika sabitleme mekanizmasını kullanarak güvenilir bir CA tarafından imzalanan geçerli bir TLS sertifikası olmamasını atlayabilirsiniz. Bu, örneğin kendinden imzalı bir sertifikası olan özel cihazlarla güvenli bağlantılar kurulmasını sağlar. WebTransport bağlantıları çift yönlü veri aktarımına izin verir ancak getirme isteklerine izin vermez. Web uygulamanızın bakış açısından HTTP isteklerine bağlantı üzerinden şeffaf bir proxy uygulamak için bu yaklaşımı bir hizmet çalışanıyla birleştirebilirsiniz. Sunucu tarafında, karşılık gelen bir çeviri katmanı WebTransport mesajlarını HTTP isteklerine dönüştürebilir.
Bunun oldukça fazla çalışma gerektirdiğinin farkındayız ancak WebRTC üzerine inşa etmekten çok daha kolay olacaktır. Gerekli yatırımın bir kısmının yeniden kullanılabilir kitaplık olarak uygulanmasını da umuyoruz. Ayrıca, platform zaman içinde HTTPS kullanımını daha güçlü şekilde teşvik etmeye doğru ilerledikçe, güvenli olmayan bağlamların giderek daha fazla web platformu özelliğine erişimi kaybetme ihtimalinin yüksek olduğunu göz önünde bulundurmanın özellikle önemli olduğuna inanıyoruz. Özel Ağ Erişiminden bağımsız olarak, bu büyük olasılıkla akıllıca bir yatırım olacaktır.
HTTP/3 üzerinden WebTransport'un, anahtar paylaşımına ve aşağıdakiler de dahil olmak üzere diğer standart altındaki güvenlik uygulamalarına karşı koruma sağlamak için Chrome 96'da (kaynak deneme sürümü başlatıldı) gönderilmesini bekliyoruz:
- Sabitlenmiş sertifikalar için kısa bir maksimum geçerlilik süresi.
- Kötüye kullanıma tabi belirli anahtarları iptal etmek için tarayıcıya özel bir mekanizma.
WebTransport tam olarak kullanıma sunulduktan sonra en az iki aşamaya kadar güvenli içerik kısıtlamasını göndermeyeceğiz. Kullanımdan kaldırma denemesi gerekirse uzatılır.
Tersine yerleştirme
Bu çözüm ağ üzerinde herhangi bir yönetici denetimi gerektirmez ve hedef sunucu HTTPS çalıştırmak için yeterince güçlü olmadığında kullanılabilir.
Herkese açık bir web uygulamasından özel alt kaynakları getirmek yerine, özel sunucudan uygulamanın iskeleti sunulabilir. Daha sonra bu iskelet, tüm alt kaynaklarını (komut dosyaları veya resimler gibi) CDN gibi genel bir sunucudan getirir. Sonuçta elde edilen web uygulaması, aynı kaynak olarak kabul edildiğinden özel sunucuya istek gönderebilir. Özel IP'leri olan (ancak localhost'u değil) diğer sunuculara bile istek yapabilir ancak bu durum uzun vadede değişebilir.
Özel sunucuda yalnızca bir iskelet barındırarak, herkese açık bir web uygulamasında yaptığınız gibi yeni kaynakları genel sunucuya göndererek web uygulamasını güncelleyebilirsiniz. Diğer yandan, ortaya çıkan web uygulaması güvenli bir bağlam olmadığından web'in daha güçlü özelliklerinden bazılarına erişemez.
Geleceğe yönelik planlar
Özel ağ isteklerini güvenli bağlamlarla kısıtlamak, Özel Ağ Erişimini başlatmanın yalnızca ilk adımıdır. Chrome, spesifikasyonun geri kalanını önümüzdeki aylarda uygulamak için çalışmaktadır. Güncellemeler için bizi takip etmeye devam 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, gizli web sitelerinden localhost'a gelen istekleri de sorunlu olarak sınıflandırır. Chrome sonunda bunları da kullanımdan kaldıracaktır. Ancak bu durum biraz daha farklı zorlukları beraberinde getirir. Çünkü birçok özel web sitesinin alan adı yoktur ve bu durum, kullanımdan kaldırma deneme jetonlarının kullanımını daha karmaşık hale getirir.
CORS ön kontrol istekleri
Özel Ağ Erişiminin ikinci bölümü, CORS ön kontrol istekleriyle güvenli bağlamlardan başlatılan özel ağ isteklerini denetlemektir. Buradaki düşünce, istek güvenli bir bağlamdan başlatılmış olsa bile, hedef sunucudan, başlatıcıya açık bir izin sağlaması istenmektedir. İstek yalnızca hibe başarılı olursa gönderilir.
Kısacası CORS ön kontrol isteği, sonraki isteğin yapısını belirten bazı Access-Control-Request-* üst bilgilerini taşıyan bir HTTP OPTIONS isteğidir. Ardından sunucu, Access-Control-Allow-* üst bilgileriyle 200 OK yanıtını vererek ayrıntılı erişim sağlayıp sağlamamaya karar verebilir.
Bu konuyla ilgili daha fazla bilgiyi spesifikasyonda bulabilirsiniz.
Gezinme getirmelerini kısıtla
Chrome kullanımdan kaldırılıyor ve ilerleyen zamanlarda özel ağlara gönderilen alt kaynak isteklerini engelliyor. Bu durum, CSRF saldırılarında da kullanılabilen özel ağlara gezinmeyi etkilemez.
Özel Ağ Erişimi spesifikasyonu, bir süre sonra aynı kısıtlamalara tabi olacak iki getirme türü arasında bir ayrım yapmaz.
Kapak fotoğrafı: Markus Spiske Unsplash'ta