Özel Ağ Erişimi: ön kontroller kullanıma sunuluyor

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.

Giriş

Chrome, herkese açık özel ağ uç noktalarına doğrudan erişimi kullanımdan kaldırıyor web sitelerinin Özel Ağ Erişimi (PNA) bakın.

Chrome, bir alt kaynak için herhangi bir özel ağ isteğinden önce CORS ön kontrol isteği göndermeye başlar ve bunun sonucunda hedef sunucudan gelen açık izin için kullanın. Bu yayın öncesi isteği, yeni bir üstbilgi, Access-Control-Request-Private-Network: true ve yanıta karşılık gelen bir üstbilgi bulunmalıdır. Access-Control-Allow-Private-Network: true.

Amaç, kullanıcıları siteler arası istek sahtekarlığı (CSRF) saldırılarından korumaktır özel ağlardaki yönlendiricileri ve diğer cihazları hedeflemek. Bu saldırılar yüz binlerce kullanıcıyı, Bu da saldırganların kendilerini kötü amaçlı sunuculara yönlendirmesini sağlar.

Kullanıma sunma planı

Chrome, web sitelerine fark etmeleri için zaman tanımak amacıyla bu değişikliği iki aşamada kullanıma sunacaktır ve buna göre ayarlama yapmaktır.

1. Chrome 104'te:

   • Kontrol öncesi istekleri özel ağdan önce göndererek Chrome denemeleri alt kaynak istekleridir.
   • Yayın öncesi hataları, aksi olmadan yalnızca Geliştirici Araçları'nda uyarı gösterir özel ağ isteklerini etkiler.
   • Chrome, uyumluluk verilerini toplar ve etkilenen en geniş bulabilirsiniz.
   • Bunun, mevcut web siteleriyle kapsamlı olarak uyumlu olmasını bekliyoruz.
   ziyaret edin.

2. En erken Chrome 113 sürümünde:

   • Bu, yalnızca uyumluluk verileri güvenli olduğunu ve gerektiğinde doğrudan iletişim kurduğumuzu bilmenizi isteriz.
   • Chrome, kontrol öncesi isteklerin başarılı olması gerektiğini zorunlu kılar, aksi takdirde başarısız olur talep etmiş olursunuz.
   • Desteği sonlandırılan deneme, şu tarihte başlar: aynı zamanda bu aşamadan etkilenen web sitelerinin de uzatılır. Deneme süresi en az 6 ay sürer.

ziyaret edin.

Özel Ağ Erişimi (PNA) nedir?

Özel Ağ Erişimi (eski adıyla CORS-RFC1918) Web sitelerinin gizli sunuculara istek gönderme olanağını kısıtlar ağlar.

Chrome spesifikasyonun bir kısmını zaten uyguladı: Chrome 96'dan itibaren yalnızca güvenli bağlamların özel ağ istekleri yapmasına izin verilir. Daha fazla bilgi için önceki blog yayınına göz atın.

Bu spesifikasyon, Kaynaklar Arası Kaynak Paylaşımı'nı (CORS) da web sitelerinin artık sunuculardan açıkça hibe talebinde bulunması için kullanılacak protokol önce özel ağlarda rastgele istek göndermesine izin verilmez.

PNA, IP adreslerini nasıl sınıflandırır ve özel bir ağı nasıl tanımlar?

IP adresleri üç IP adresi alanına ayrılır: - public - private - local

Yerel IP adresi alanı, IPv4 olan IP adreslerini içerir RFC1122'nin 3.2.1.3 bölümünde tanımlanan geri döngü adresleri (127.0.0.0/8) veya RFC4291'in 2.5.3 numaralı bölümünde tanımlanan IPv6 geri dönüş adresleri (::1/128) olabilir.

Özel IP adresi alanı, yalnızca anlamı olan IP adreslerini içerir 10.0.0.0/8, 172.16.0.0/12 ve RFC1918'de tanımlanan 192.168.0.0/16, RFC3927'de tanımlanan yerel bağlantı adresleri 169.254.0.0/16, RFC4193'de tanımlanan benzersiz yerel IPv6 tek noktaya yayın adresleri fc00::/7, RFC4291'in 2.5.6 numaralı bölümünde tanımlanan yerel link-yerel IPv6 tek yayın adresleri fe80::/10 ve eşlenen IPv4 adresinin gizli olduğu IPv4 eşlenmiş IPv6 adresleri.

Genel IP adresi alanı, daha önce bahsedilmeyen diğer tüm adresleri içerir.

Yerel IP adresi, özel bir IP adresinden daha gizli kabul edilir. herkese açık bir IP adresinden daha gizli olarak kabul edilir.

Daha fazla bilgi edinmek için Geri bildirim isteniyor: Özel ağlar için CORS (RFC1918) bölümüne bakın.

Yayın öncesi istekler

Arka plan

Yayın öncesi istekler, Kaynaklar Arası Kaynak Paylaşımı (CORS) standardı tarafından sağlanan bir mekanizmadır. HTTP isteği göndermeden önce hedef web sitesinden izin isteme yan etkileri olabilir. Bu sayede, hedef sunucunun hem de CSRF saldırısı riskini önemli ölçüde azaltır.

İzin isteği, belirli CORS istek başlıklarıyla bir OPTIONS HTTP isteği olarak gönderilir. yaklaşmakta olan HTTP isteğini açıklar. Yanıtta belirli CORS yanıt başlıkları bulunmalıdır kabul etmiş olursunuz.

Özel Ağ Erişimi'ndeki yenilikler

Kontrol öncesi isteklere yeni bir istek ve yanıt başlığı çifti eklenir:

• Access-Control-Request-Private-Network: true, tüm PNA ön kontrol isteklerinde ayarlandı
• Tüm PNA ön kontrol yanıtlarında Access-Control-Allow-Private-Network: true ayarlanmalıdır

PNA için yayın öncesi istekleri tüm özel ağ istekleri için gönderilir. talep yöntemi ve kapsamı ne olursa olsun mod'u seçin. Gönderilen cors modundaki isteklerin önünde, no-cors ve diğer tüm modlarda. Bu tüm özel ağ isteklerinin CSRF saldırıları için kullanılabilmesidir, istek modundan ve yanıt içeriklerinin hazırlanıp içeriği başlatan kişi tarafından kullanılabilir.

PNA için yayın öncesi istekler aynı kaynaklı istekler için de gönderilir. Bu istekler hedef IP adresi, başlatıcıdan daha gizli. Normalden farklı Yayın öncesi isteklerin yalnızca kaynaklar arası isteklere yönelik olduğu CORS. Yayın öncesi aynı kaynaktan gelen isteklere karşı koruma sağlar DNS yeniden birleştirme saldırıları.

Örnekler

Gözlemlenebilir davranış, istek modunu etkinleştirmelisiniz.

CORS modu yok

https://foo.example/index.html yerleştirilmiş öğeyi söyleyin <img src="https://bar.example/cat.gif" alt="dancing cat"/> ve bar.example, şu bilgilere göre özel bir IP adresi olan 192.168.1.1 olarak çözümlenir: RFC 1918.

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 aşağıdaki kodla 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 gerçek isteği gönderir:

HTTP/1.1 GET /cat.gif
...

Sunucunun normal şekilde yanıt verebileceği adrestir.

CORS modu

https://foo.example/index.html uygulamasının aşağıdaki kodu çalıştırdığını varsayalım:

await fetch('https://bar.example/delete-everything', {
  method: 'PUT',
  credentials: 'include',
})

Yine bar.example'ın 192.168.1.1 olarak çözümlendiğini 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 aşağıdaki kodla 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 gerçek isteği gönderir:

HTTP/1.1 PUT /delete-everything
Origin: https://foo.example

Sunucunun normal 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 ağ isteği algılanırsa ön kontrol istek gönderilir. Bu ön kontrol isteği başarısız olursa nihai isteği yine de gönderilir ancak Geliştirici Araçları'nda bir uyarı gösterilir sorunları kontrol edin.

Etkilenen yayın öncesi istekler ağ panelinde de görüntülenebilir ve teşhis edilebilir:

İsteğiniz, dönüşüm izleme işlemi olmadan normal bir CORS ön kontrolünü tetiklerse özel Ağ Erişimi kurallarına göre hareket ederseniz, ağ paneline geliyor. İlk panelin sürekli başarısız olduğu görülüyor. Bu, bilinen bir hata alır ve bunu güvenle yoksayabilirsiniz.

Yayın öncesi başarı uygulanırsa ne olacağını incelemek için aşağıdaki komut satırı bağımsız değişkenini iletin, (Chrome 98'den itibaren):

--enable-features=PrivateNetworkAccessRespectPreflightResults

Başarısız olan herhangi bir ön kontrol isteği, getirme işleminin başarısız olmasına neden olur. Bu sayede çalışıp çalışmadığını test etmek için önemli bir noktadayız. Hatalar aşağıdaki bölümlerde teşhis edilebilir: Bu işlemler, yukarıda bahsedilen Geliştirici Araçları panelleri kullanılarak yapılan uyarılarla aynıdır.

Web siteniz etkileniyorsa ne yapmanız gerekir?

Bu değişiklik Chrome 104 sürümünde kullanıma sunulduğunda, web sitesi. Ancak, etkilenen istek yollarını web sitenizin beklendiği gibi çalışmaya devam etmesini sağlamak.

Kullanabileceğiniz iki çözüm vardır:

1. Sunucu tarafındaki kontrol öncesi istekleri yönetme
2. Kurumsal politikalarla PNA kontrollerini devre dışı bırak

Sunucu tarafı kontrol öncesi istekleri işleme

PNA ön kontrolünü işlemek için etkilenen tüm getirmelerin hedef sunucusunu güncelleyin kabul edersiniz. Öncelikle, yardımcı olur. Ardından, iki yeni yanıt başlığı için destek ekleyin.

Sunucunuz bir yayın öncesi isteği (CORS ile bir OPTIONS isteği) aldığında emin olunması halinde sunucu, bu tür bir Access-Control-Request-Private-Network: true üstbilgisi. Bu başlık istekte mevcutsa sunucu, Origin başlığını ve diğer alakalı bilgilerle (örneğin, Access-Control-Request-Headers) kontrol edin. Genellikle sizin kontrolünüzdeki tek bir kaynağa erişim izni vermeniz gerekir.

Sunucunuz isteğe izin vermeye karar verdikten sonra isteğe yanıt vermelidir. Gerekli CORS başlıkları ve yeni PNA ile 204 No Content (veya 200 OK) kullanabilirsiniz. Bu başlıklar arasında Access-Control-Allow-Origin ve Access-Control-Allow-Private-Network: true ve gerektiğinde başka kullanıcılar.

Somut senaryolar için örneklere bakın.

Kurumsal politikaları kullanarak Özel Ağ Erişimi kontrollerini devre dışı bırak

Kullanıcılarınız üzerinde yönetici denetimine sahipseniz Gizli ayarını devre dışı bırakabilirsiniz. Ağ Erişimi, aşağıdaki politikalardan birini kullanarak kontrol eder:

• InsecurePrivateNetworkRequestsAllowed
• InsecurePrivateNetworkRequestsAllowedForUrls

Daha fazla bilgi için Chrome politika yönetimini anlama başlıklı makaleye bakın.

Görüşlerinizi bizimle paylaşın

Özel bir ağ içinde, sizden istekler bekleyen bir web sitesi barındırıyorsanız ağlarla ilgili daha fazla bilgi edinmek için Chrome ekibi, geri bildirimleriniz ve kullanım alanlarınızla ilgilenir. crbug.com adresinden Chromium'da sorun bildirerek bize bildirin ve Blink>SecurityFeature>CORS>PrivateNetworkAccess değerine ayarlayın.

Sırada ne var?

Bir sonraki adımda Chrome, Özel Ağ Erişimi kontrollerini kapsayacak şekilde genişletecektir web çalışanları: ve hizmet çalışanları var. Geçici olarak uyarıları göstermeye başlaması içindir.

Ardından Chrome, Özel Ağ Erişimi kontrollerini gezinmeleri, iç çerçeveler ve pop-up'lar dahil. Geçici olarak Chrome 108'in kullanıma sunulmasını hedefliyoruz. uyarılar gösteriliyor.

Biz her iki durumda da, benzer bir aşamalı geçiş ile ilgili ihtiyatlı bir yaklaşım benimseyeceğiz. .

Teşekkür

Mark Olsen'in kapak fotoğrafı Lansmanı kaldırın.