Güncellemeler
- 7 Temmuz 2022: Mevcut durum güncellendi ve IP adresi alanı tanımı eklendi.
- 27 Nisan 2022: Zaman çizelgesi duyurusu güncellendi.
- 7 Mart 2022: Chrome 98'de sorunlar tespit edildikten sonra geri alma duyurusu yapıldı.
Giriş
Chrome, Özel Ağ Erişimi (PNA) spesifikasyonunun bir parçası olarak, herkese açık web sitelerinden özel ağ uç noktalarına doğrudan erişimi kullanımdan kaldırıyor.
Chrome, hedef sunucudan açık izin isteyen bir alt kaynak için herhangi bir özel ağ isteğinden önce CORS ön kontrol isteği göndermeye başlar. Bu ön kontrol isteği yeni bir üst bilgi (Access-Control-Request-Private-Network: true) taşır ve buna karşılık gelen yanıtın Access-Control-Allow-Private-Network: true başlıklı başlığını içermesi gerekir.
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.
Kullanıma sunma planı
Chrome, web sitelerine değişikliği fark edip uygun şekilde düzenleme yapmaları için zaman tanımak amacıyla bu değişikliği iki aşamada kullanıma sunacaktır.
Chrome 104'te:
- Chrome, özel ağ alt kaynak isteklerinden önce kontrol öncesi istekleri göndererek denemeler yapar.
- Ön kontrol hataları, özel ağ isteklerini etkilemeden yalnızca Geliştirici Araçları'nda uyarı gösterir.
- Chrome, uyumluluk verilerini toplar ve etkilenen en büyük web sitelerine ulaşır.
- Bu uygulamanın, mevcut web siteleriyle geniş çapta uyumlu olmasını bekliyoruz.
En erken Chrome 113 sürümünde:
- Bu işlem yalnızca uyumluluk verileri değişikliğin yeterince güvenli olduğunu gösterdiğinde ve gerektiğinde doğrudan iletişime geçtiğimizde başlayacaktır.
- Chrome, ön kontrol isteklerinin başarılı olması gerektiğini, aksi halde isteklerin başarısız olmasını zorunlu kılar.
- Desteği sonlandırma denemesi, bu aşamadan etkilenen web sitelerinin zaman uzatma isteğinde bulunabilmesi için aynı zamanda başlar. Deneme en az 6 ay sürer.
Özel Ağ Erişimi (PNA) nedir?
Özel Ağ Erişimi (eski adıyla CORS-RFC1918), web sitelerinin özel ağlardaki sunuculara istek gönderme özelliğini kısıtlar.
Chrome, bu spesifikasyonun bir kısmını zaten uygulamıştır: Chrome 96 itibarıyla yalnızca güvenli bağlamların özel ağ istekleri yapmasına izin verilmektedir. Ayrıntılar için önceki blog yayınımıza göz atın.
Spesifikasyon ayrıca Merkezler Arası Kaynak Paylaşımı (CORS) protokolünün kapsamını genişletmiştir. Böylece web siteleri artık rastgele istek göndermelerine izin verilmeden önce özel ağlardaki sunuculardan açıkça bağış talep etmelidir.
PNA, IP adreslerini nasıl sınıflandırır ve özel ağı nasıl tanımlar?
IP adresleri üç IP adresi alanında sınıflandırılır:
- public
- private
- local
Yerel IP adresi alanı, RFC1122'nin 3.2.1.3 bölümünde tanımlanan IPv4 döngü adresi (127.0.0.0/8) veya RFC4291 bölüm 2.5.3'te tanımlanan IPv6 geri dönüş adresleri (::1/128) olan IP adreslerini içerir.
Özel IP adresi alanı, RFC1918'de tanımlanan 10.0.0.0/8, 172.16.0.0/12 ve 192.168.0.0/16 dahil olmak üzere yalnızca geçerli ağ içinde anlam taşıyan IP adreslerini içerir. RFC1918'de tanımlanan 169.254.0.0/16 yerel bağlantı adresleri, RFC4193'te tanımlanan benzersiz yerel IPv6 tek noktaya yayın adresleri fc00::/7, RFC4193'te tanımlanan benzersiz yerel IPv6 tek noktaya yayın adresleri fc00::/7, RFC4 bölümlü RFC15 eşlenmiş IPv4 adresleri{/6 RFC1'e ait özel IPv4 adresleri{/6 RFC1'deki özel bağlantı adresleri{/1, özel IPv4 adresleridir. RFC4 adresi, özel IPv4 adresleridir. RFC14 adresleri, RFC14 adresleridir. RFC14 adresleri, RFC4'e dahildir{/6, RFC14 adresleri, RFC14 adresleridir., özel IPv4 adresleridir. RFC4 adresi, özel IPv4 adresleridir. RFC4 adresi, özel IPv4 adresleridir. RFC4 adresi, özel IPv4 adresleridir. Bu adresler, RFC1918'de tanımlanmıştır. {1918'de tanımlanan yerel bağlantı adresleridir 169.254.0.0/16.RFC3927fe80::/10RFC4291
Genel IP Adresi alanı, daha önce bahsedilmeyen diğer tüm adresleri içerir.
Yerel IP adresi, genel IP adresinden daha gizli olarak değerlendirilen özel IP adresinden daha özel olarak kabul edilir.
Geri bildirim istendi: Özel ağlar için CORS (RFC1918) başlıklı makaleden daha fazla bilgi edinebilirsiniz.
Kontrol öncesi istekleri
Arka plan
Ön kontrol istekleri, Merkezler Arası Kaynak Paylaşımı (CORS) standardı tarafından kullanıma sunulan ve yan etkileri olabilecek bir HTTP isteği göndermeden önce hedef web sitesinden izin istemek için kullanılan bir mekanizmadır. Bu, hedef sunucunun CORS protokolünü anlamasını sağlar ve CSRF saldırısı riskini önemli ölçüde azaltır.
İzin isteği, yaklaşan HTTP isteğini açıklayan belirli CORS istek başlıklarıyla birlikte bir OPTIONS HTTP isteği olarak gönderilir. Yanıtta, yaklaşan isteğin açıkça kabul edildiği belirli CORS yanıt başlıkları bulunmalıdır.
Özel Ağ Erişimi ile ilgili yenilikler
Yayın öncesi isteklere yeni bir istek ve yanıt başlığı çifti eklendi:
Access-Control-Request-Private-Network: truetüm PNA ön kontrol isteklerinde ayarlandı- Tüm PNA ön kontrol yanıtlarında
Access-Control-Allow-Private-Network: trueayarlanmalıdır
PNA için ön kontrol istekleri, istek yöntemi ve moddan bağımsız olarak tüm özel ağ istekleri için gönderilir. cors modunun yanı sıra no-cors ve diğer tüm modlarda isteklerden önce gönderilirler. Bunun nedeni, istek modundan ve yanıt içeriğinin başlatıcıya sunulup sunulmadığına bakılmaksızın tüm özel ağ isteklerinin CSRF saldırıları için kullanılabilmesidir.
Hedef IP adresi başlatıcıdan daha gizliyse PNA için ön kontrol istekleri de aynı kaynak istekleri için gönderilir. Bu, ön kontrol isteklerinin yalnızca kaynaklar arası istekler için yapıldığı normal CORS'den farklıdır. Aynı kaynak istekleri için ön kontrol istekleri, DNS yeniden birleştirme saldırılarına karşı koruma sağlar.
Örnekler
Gözlemlenebilir davranış isteğin moduna bağlıdır.
CORS yok modu
https://foo.example/index.html ürününün
<img src="https://bar.example/cat.gif" alt="dancing cat"/> kodunu yerleştirdiğini ve
bar.example'nin RFC 1918'e uygun özel bir IP adresi olan 192.168.1.1 olarak çözümlediğini düşünelim.
Chrome önce bir ön kontrol isteği gönderir:
HTTP/1.1 OPTIONS /cat.gif
Origin: https://foo.example
Access-Control-Request-Private-Network: true
Bu isteğin başarılı olması için sunucunun şu şekilde yanıt vermesi gerekir:
HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://foo.example
Access-Control-Allow-Private-Network: true
Ardından Chrome asıl isteği gönderir:
HTTP/1.1 GET /cat.gif
...
Sunucunun normal şekilde yanıt verebileceği.
CORS modu
https://foo.example/index.html işlevinin aşağıdaki kodu çalıştırdığını düşünelim:
await fetch('https://bar.example/delete-everything', {
method: 'PUT',
credentials: 'include',
})
Yine bar.example ürününün 192.168.1.1 olarak çözüldüğünü varsayalım.
Chrome önce bir ön kontrol isteği gönderir:
HTTP/1.1 OPTIONS /delete-everything
Origin: https://foo.example
Access-Control-Request-Method: PUT
Access-Control-Request-Credentials: true
Access-Control-Request-Private-Network: true
Bu isteğin başarılı olması için sunucunun şu şekilde yanıt vermesi gerekir:
HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://foo.example
Access-Control-Allow-Methods: PUT
Access-Control-Allow-Credentials: true
Access-Control-Allow-Private-Network: true
Ardından Chrome asıl isteği gönderir:
HTTP/1.1 PUT /delete-everything
Origin: https://foo.example
Sunucunun her zamanki CORS kurallarına göre yanıt verebileceği:
HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://foo.example
Web sitenizin etkilenip etkilenmediğini nasıl anlarsınız?
Chrome 104'ten itibaren, özel bir ağ isteği algılanırsa öncesinde bir yayın öncesi isteği gönderilir. Bu ön kontrol isteği başarısız olursa son istek yine de gönderilir ancak Geliştirici Araçları sorunları panelinde bir uyarı gösterilir.
Etkilenen ön kontrol istekleri, ağ panelinde de görüntülenebilir ve teşhis edilebilir:
İsteğiniz, Özel Ağ Erişimi kuralları olmadan normal bir CORS ön kontrolünü tetiklediyse ağ panelinde, ilki her zaman başarısız olmuş gibi görünen iki ön kontrol görebilirsiniz. Bu bilinen bir hatadır ve güvenle yoksayabilirsiniz.
Kontrol öncesi başarı uygulanırsa ne olacağını incelemek için Chrome 98'den itibaren aşağıdaki komut satırı bağımsız değişkenini aktarabilirsiniz:
--enable-features=PrivateNetworkAccessRespectPreflightResults
Başarısız olan ön kontrol istekleri, getirme işleminin başarısız olmasına yol açar. Bu, kullanıma sunma planımızın ikinci aşamasından sonra web sitenizin çalışıp çalışmadığını test etmenize olanak tanır. Hatalar, yukarıda bahsedilen Geliştirici Araçları panelleri kullanılarak uyarılarla aynı şekilde teşhis edilebilir.
Web siteniz etkileniyorsa ne yapmanız gerekir?
Bu değişiklik Chrome 104'te kullanıma sunulduğunda, herhangi bir web sitesini bozması beklenmemektedir. Bununla birlikte, web sitenizin beklendiği gibi çalışmaya devam etmesi için etkilenen istek yollarını güncellemenizi önemle tavsiye ederiz.
Kullanabileceğiniz iki çözüm vardır:
- Kontrol öncesi isteklerini sunucu tarafında işleme
- Kurumsal politikalarla PNA kontrollerini devre dışı bırakın
Kontrol öncesi isteklerini sunucu tarafında işleme
Etkilenen tüm getirmelerin hedef sunucusunu PNA ön kontrol isteklerini işlemek için güncelleyin. Öncelikle, etkilenen rotalarda standart CORS ön kontrol istekleri için destek uygulayın. Ardından iki yeni yanıt başlığı için destek ekleyin.
Sunucunuz bir ön kontrol isteği (CORS başlıkları olan bir OPTIONS isteği) aldığında, bir Access-Control-Request-Private-Network: true üst bilgisinin olup olmadığını kontrol etmelidir. İstekte bu başlık varsa sunucu, isteğe izin verilmesini sağlamak için Origin üst bilgisini ve istek yolunu diğer alakalı bilgilerle (Access-Control-Request-Headers gibi) birlikte incelemelidir.
Genellikle, kontrolünüz altındaki tek bir kaynağa erişim izni vermeniz gerekir.
Sunucunuz isteğe izin vermeye karar verdiğinde, gerekli CORS başlıkları ve yeni PNA başlığıyla 204 No Content (veya 200 OK) yanıtı vermelidir. Bu başlıklar, Access-Control-Allow-Origin ve Access-Control-Allow-Private-Network: true ile birlikte gerektiğinde diğerlerini içerir.
Somut senaryolar için örneklere bakın.
Kurumsal politikaları kullanarak Özel Ağ Erişimi kontrollerini devre dışı bırakın
Kullanıcılarınız üzerinde yönetici kontrolünüz varsa aşağıdaki politikalardan birini kullanarak Özel Ağ Erişimi kontrollerini devre dışı bırakabilirsiniz:
Daha fazla bilgi için Chrome politika yönetimini anlama başlıklı makaleye bakın.
Geri bildirimlerinizi bizimle paylaşın
Herkese açık ağlardan istek bekleyen bir web sitesini özel bir ağda barındırıyorsanız Chrome ekibi geri bildirimleriniz ve kullanım alanlarınızla ilgilenir.
crbug.com adresinden Chromium ile ilgili bir sorun oluşturarak bize bildirin ve bileşeni Blink>SecurityFeature>CORS>PrivateNetworkAccess değerine ayarlayın.
Sırada ne var?
Chrome daha sonra Özel Ağ Erişimi kontrollerini, web çalışanlarını: özel çalışanları, ortak çalışanları ve hizmet çalışanlarını kapsayacak şekilde genişletecek. Geçici olarak Chrome 107'nin uyarı göstermeye başlamasını hedefliyoruz.
Ardından Chrome, Özel Ağ Erişimi kontrollerini iframe'ler ve pop-up'lar dahil olmak üzere gezinmeleri kapsayacak şekilde genişletir. Geçici olarak Chrome 108'in uyarılar göstermeye başlamasını amaçlıyoruz.
Her iki durumda da, web geliştiricilerine uyumluluk riskini ayarlaması ve tahmin etmesi için zaman tanımak amacıyla benzer bir aşamalı kullanıma sunumu dikkatle ileteceğiz.
Teşekkür
Mark Olsen'in Unsplash'teki kapak fotoğrafı.