Yönlendiren ve Yönlendiren Politikası ile ilgili en iyi uygulamalar

Maud Nalpas

Bu sayfada, Referrer-Policy'nizi ayarlama ve gelen isteklerde yönlendireni kullanma ile ilgili bazı en iyi uygulamalar özetlenmektedir.

Özet

• Beklenmedik şekilde kaynaklar arası bilgi sızıntısı, web kullanıcılarının gizliliğine zarar verir. Koruyucu bir yönlendiren politikası yardımcı olabilir.
• strict-origin-when-cross-origin yönlendiren politikasını ayarlayabilirsiniz. Bu, yönlendirenin yararlılığının büyük bir kısmını korurken kaynaklar arası veri sızıntısı riskini azaltır.
• Siteler arası istek sahteciliği (CSRF) koruması için yönlendirenleri kullanmayın. Bunun yerine CSRF jetonlarını ve ek güvenlik katmanı olarak diğer başlıkları kullanın.

Yönlendiren ve yönlendiren politikası hakkında temel bilgiler

HTTP istekleri, isteğin yapıldığı kaynağı veya web sayfası URL'sini belirten isteğe bağlı bir Referer üstbilgisi içerebilir. Referrer-Policy başlığı, Referer başlığında hangi verilerin kullanılabileceğini tanımlar.

Aşağıdaki örnekte, Referer üstbilgisi, isteğin yapıldığı site-one üzerindeki sayfanın tam URL'sini içerir.

Referer üstbilgisi farklı istek türlerinde bulunabilir:

• Kullanıcı bir bağlantıyı tıkladığında gezinme istekleri.
• Tarayıcı, bir sayfanın ihtiyaç duyduğu resimleri, iFrame'leri, komut dosyalarını ve diğer kaynakları istediğinde alt kaynak istekleri gönderilir.

Geçişler ve iFrame'ler için bu verilere JavaScript ile de erişebilirsiniz.document.referrer

Referer değerlerinden çok şey öğrenebilirsiniz. Örneğin, bir analiz hizmeti, site-two.example adresindeki ziyaretçilerin% 50'sinin social-network.example adresinden geldiğini belirlemek için bunları kullanabilir. Ancak yol ve sorgu dizesi de dahil olmak üzere tam URL, Referer kaynaklar arası gönderildiğinde kullanıcı gizliliğini tehlikeye atabilir ve güvenlik riskleri oluşturabilir:

1-5 numaralı URL'ler özel bilgiler, bazen de hassas veya kişisel veri içeriyor. Bunların kaynaklar arasında sessizce sızdırılması, web kullanıcılarının gizliliğini tehlikeye atabilir.

6 numaralı URL bir yeterlilik URL'sidir. Bu e-postayı amaçlanan kullanıcı dışında biri alırsa kötü niyetli bir aktör, bu kullanıcının hesabının kontrolünü ele geçirebilir.

Sitenizden gelen istekler için hangi yönlendiren verilerinin kullanılabilir olacağını kısıtlamak istiyorsanız bir yönlendiren politikası belirleyebilirsiniz.

Hangi politikalar kullanılabilir ve aralarındaki farklar nelerdir?

Sekiz politikadan birini seçebilirsiniz. Politikaya bağlı olarak, Referer üstbilgisinden (ve document.referrer) elde edilebilen veriler şunlar olabilir:

• Veri yok (Referer üstbilgisi yok)
• Yalnızca kaynak
• Tam URL: kaynak, yol ve sorgu dizesi

Bazı politikalar, bağlama bağlı olarak farklı şekilde çalışacak şekilde tasarlanmıştır: kaynaklar arası veya aynı kaynaklı istek, istek hedefinin kaynak kadar güvenli olup olmadığı ya da her ikisi. Bu, kendi sitenizdeki yönlendirenin zenginliğini korurken kaynaklar arasında veya daha az güvenli kaynaklarla paylaşılan bilgi miktarını sınırlamak için yararlıdır.

Aşağıdaki tabloda, yönlendiren politikalarının, yönlendiren başlığından ve document.referrer'dan kullanılabilen URL verilerini nasıl kısıtladığı gösterilmektedir:

MDN, politikaların ve davranış örneklerinin tam listesini sağlar.

Yönlendiren politikası belirlerken dikkat etmeniz gereken bazı noktalar:

• Şemayı (HTTPS ve HTTP) dikkate alan tüm politikalar (strict-origin, no-referrer-when-downgrade ve strict-origin-when-cross-origin), HTTP daha az güvenli olmasına rağmen bir HTTP kaynağının başka bir HTTP kaynağına yaptığı istekleri, bir HTTPS kaynağının başka bir HTTPS kaynağına yaptığı isteklerle aynı şekilde ele alır. Bunun nedeni, bu politikalar için önemli olanın güvenlik düşürme işleminin gerçekleşip gerçekleşmediğidir. Yani, HTTPS → HTTP isteklerinde olduğu gibi, isteğin şifrelenmiş bir kaynaktan gelen verileri şifrelenmemiş bir kaynağa aktarıp aktaramadığıdır. HTTP → HTTP isteği tamamen şifrelenmemiş olduğundan protokol düşürme söz konusu değildir.
• Bir istek aynı kaynaklıysa şemanın (HTTPS veya HTTP) aynı olduğu anlamına gelir. Bu nedenle, güvenlik düşürülmez.

Tarayıcılardaki varsayılan yönlendiren politikaları

Ekim 2021 itibarıyla

Yönlendiren politikası ayarlanmamışsa tarayıcı, varsayılan politikasını kullanır.

Yönlendiren politikası ayarlamaya yönelik en iyi uygulamalar

Siteniz için yönlendiren politikalarını ayarlamanın farklı yolları vardır:

• HTTP üstbilgisi olarak
• HTML'niz içinde
• JavaScript'ten istek bazında

Farklı sayfalar, istekler veya öğeler için farklı politikalar belirleyebilirsiniz.

HTTP üstbilgisi ve meta öğesi sayfa düzeyindedir. Bir öğenin etkin politikasını belirleme öncelik sırası aşağıdaki gibidir:

1. Öğe düzeyinde politika
2. Sayfa düzeyinde politika
3. Tarayıcı varsayılanı

Örnek:

index.html:

<meta name="referrer" content="strict-origin-when-cross-origin" />
<img src="..." referrerpolicy="no-referrer-when-downgrade" />

Görsel, no-referrer-when-downgrade politikasıyla isteniyor ve bu sayfadaki diğer tüm alt kaynak istekleri strict-origin-when-cross-origin politikasına uygun.

Yönlendiren politikası nasıl görülür?

securityheaders.com, belirli bir site veya sayfanın hangi politikayı kullandığını belirlemek için kullanışlıdır.

Belirli bir istek için kullanılan yönlendiren politikasını görmek üzere Chrome, Edge veya Firefox'taki geliştirici araçlarını da kullanabilirsiniz. Bu makalenin yazıldığı sırada Safari, Referrer-Policy üstbilgisini göstermiyordu ancak gönderilen Referer üstbilgisini gösteriyordu.

Web siteniz için hangi politikayı ayarlamalısınız?

strict-origin-when-cross-origin gibi (veya daha katı) gizliliği artıran bir politikayı açıkça ayarlamanızı önemle tavsiye ederiz.

Neden "açıkça"?

Bir yönlendiren politikası ayarlamazsanız tarayıcının varsayılan politikası kullanılır. Aslında web siteleri genellikle tarayıcının varsayılan politikasına uyar. Ancak bu ideal bir durum değildir çünkü:

• Farklı tarayıcıların farklı varsayılan politikaları vardır. Bu nedenle, tarayıcı varsayılanlarına güveniyorsanız siteniz tarayıcılar arasında tahmin edilebilir şekilde davranmaz.
• Tarayıcılar, kaynaklar arası istekler için strict-origin-when-cross-origin gibi daha katı varsayılanlar ve yönlendiren kırpma gibi mekanizmalar kullanmaya başlıyor. Tarayıcı varsayılanları değişmeden önce gizliliği artıran bir politikayı açıkça etkinleştirmek, kontrolü size verir ve testleri istediğiniz gibi çalıştırmanıza yardımcı olur.

Neden strict-origin-when-cross-origin (veya daha katı)?

Güvenli, gizliliği artıran ve faydalı bir politikaya ihtiyacınız var. "Faydalı" ifadesinin anlamı, yönlendirenden ne istediğinize bağlıdır:

• Güvenli: Web siteniz HTTPS kullanıyorsa (kullanmıyorsa bu durumu öncelikli hale getirin) web sitenizin URL'lerinin HTTPS dışı isteklerde sızmasını istemezsiniz. Ağdaki herkes bu bilgileri görebileceğinden sızıntılar, kullanıcılarınızı ortadaki adam saldırılarına maruz bırakır. no-referrer-when-downgrade, strict-origin-when-cross-origin, no-referrer ve strict-origin politikaları bu sorunu çözer.
• Gizliliği artırıcı: Kaynaklar arası isteklerde no-referrer-when-downgrade tam URL'yi paylaştığı için gizlilik sorunlarına neden olabilir. strict-origin-when-cross-origin ve strict-origin yalnızca kaynağı paylaşır, no-referrer ise hiçbir şeyi paylaşmaz. Bu durumda gizliliği artıran seçenekler olarak strict-origin-when-cross-origin, strict-origin ve no-referrer kalır.
• Yararlı: no-referrer ve strict-origin, aynı kaynaklı istekler için bile tam URL'yi asla paylaşmaz. Tam URL'ye ihtiyacınız varsa strict-origin-when-cross-origin daha iyi bir seçenektir.

Tüm bunlar, strict-origin-when-cross-origin'ın genellikle mantıklı bir seçim olduğu anlamına gelir.

Örnek: strict-origin-when-cross-origin politikası ayarlama

index.html:

<meta name="referrer" content="strict-origin-when-cross-origin" />

Veya sunucu tarafında (ör. Express'te):

const helmet = require('helmet');
app.use(helmet.referrerPolicy({policy: 'strict-origin-when-cross-origin'}));

strict-origin-when-cross-origin (veya daha katı) tüm kullanım alanlarınızı karşılamıyorsa ne olur?

Bu durumda kademeli bir yaklaşım benimseyin: Web siteniz için strict-origin-when-cross-origin gibi koruyucu bir politika belirleyin ve gerekirse belirli istekler veya HTML öğeleri için daha izin verici bir politika belirleyin.

Örnek: öğe düzeyinde politika

index.html:

<head>
  <!-- document-level policy: strict-origin-when-cross-origin -->
  <meta name="referrer" content="strict-origin-when-cross-origin" />
  <head>
    <body>
      <!-- policy on this <a> element: no-referrer-when-downgrade -->
      <a src="…" href="…" referrerpolicy="no-referrer-when-downgrade"></a>
      <body></body>
    </body>
  </head>
</head>

Safari/WebKit, siteler arası istekler için document.referrer veya Referer üstbilgisini sınırlayabilir. Ayrıntıları inceleyin.

Örnek: istek düzeyinde politika

script.js:

fetch(url, {referrerPolicy: 'no-referrer-when-downgrade'});

Başka nelere dikkat etmeniz gerekir?

Politikanız, web sitenize ve sizin, ekibinizin ve şirketinizin belirlediği kullanım alanlarına bağlı olmalıdır. Bazı URL'ler tanımlayıcı veya hassas veriler içeriyorsa koruyucu bir politika ayarlayın.

Gelen isteklerle ilgili en iyi uygulamalar

Siteniz gelen isteklerin yönlendiren URL'sini kullanıyorsa yapmanız gerekenlerle ilgili bazı yönergeleri aşağıda bulabilirsiniz.

Kullanıcı verilerini koruma

Referer, özel, kişisel veya tanımlayıcı veriler içerebilir. Bu nedenle, bu verileri bu şekilde değerlendirdiğinizden emin olun.

Gelen yönlendirenler değişebilir {referer-can-change}

Gelen kaynaklar arası isteklerde yönlendireni kullanmayla ilgili birkaç sınırlama vardır:

• İsteği gönderen tarafın uygulaması üzerinde kontrolünüz yoksa aldığınız Referer üstbilgisi (ve document.referrer) hakkında varsayımlarda bulunamazsınız. İsteği yayınlayan , no-referrer politikasına istediği zaman geçebilir veya genel olarak daha önce kullandığından daha katı bir politikaya geçebilir. Bu, Referer adlı CSS'den daha önce aldığınızdan daha az veri aldığınız anlamına gelir.
• Tarayıcılar, Referrer-Policy'yi strict-origin-when-cross-origin varsayılan olarak giderek daha fazla kullanmaktadır. Bu nedenle, gönderen sitede politika ayarlanmamışsa gelen kaynaklar arası isteklerde tam yönlendiren URL yerine yalnızca kaynak alabilirsiniz.
• Tarayıcılar, Referer yönetme şekillerini değiştirebilir. Örneğin, bazı tarayıcı geliştiriciler, kullanıcı gizliliğini korumak için yönlendirenleri her zaman kaynaklar olarak kırpmaya karar verebilir.
• Referer başlığı (ve document.referrer), ihtiyacınız olandan daha fazla veri içerebilir. Örneğin, yalnızca isteğin kaynaklar arası olup olmadığını bilmek istediğinizde tam URL'ye sahip olabilir.

Referer alternatifleri

Aşağıdaki durumlarda alternatifleri değerlendirmeniz gerekebilir:

• Sitenizin temel bir özelliği, gelen kaynaklar arası isteklerin yönlendiren URL'sini kullanıyor.
• Siteniz, kaynaklar arası istekte yönlendiren URL'nin ihtiyaç duyduğu kısmını artık almıyor. Bu durum, isteği gönderen tarafın politikasını değiştirmesi veya politika ayarlanmamışken tarayıcının varsayılan politikasının değişmesi (ör. Chrome 85'te olduğu gibi) durumunda meydana gelir.

Alternatifleri tanımlamak için öncelikle yönlendirenin hangi bölümünü kullandığınızı analiz edin.

Yalnızca kaynağa ihtiyacınız varsa

• Yönlendireni, sayfaya üst düzey erişimi olan bir komut dosyasında kullanıyorsanız window.location.origin alternatif olarak kullanılabilir.
• Varsa Origin ve Sec-Fetch-Site gibi başlıklar Origin verir veya isteğin kaynaklar arası olup olmadığını açıklar. Bu, tam olarak ihtiyacınız olan şey olabilir.

URL'nin diğer öğelerine (yol, sorgu parametreleri vb.) ihtiyacınız varsa

• İstek parametreleri, kullanım alanınıza hitap edebilir ve bu sayede yönlendireni ayrıştırma işinden kurtulursunuz.
• Yönlendireni, sayfaya üst düzey erişimi olan bir komut dosyasında kullanıyorsanız window.location.pathname alternatif olarak işe yarayabilir. URL'nin yalnızca yol bölümünü ayıklayın ve bunu bağımsız değişken olarak iletin. Böylece, URL parametrelerindeki hassas olabilecek bilgiler iletilmez.

Bu alternatifleri kullanamıyorsanız:

• Sistemlerinizi, istek gönderenlerin (ör. site-one.example) ihtiyacınız olan bilgileri bir yapılandırma içinde açıkça ayarlamasını bekleyecek şekilde değiştirip değiştiremeyeceğinizi kontrol edin.
  • Avantaj: site-one.example kullanıcıları için daha açık, gizliliği korumaya yönelik ve geleceğe daha uygundur.
  • Dezavantaj: Sizin tarafınızdan veya sisteminizin kullanıcıları tarafından daha fazla çalışma gerekebilir.
• İstekleri yayınlayan sitenin, no-referrer-when-downgrade değerinde bir öğe başına veya istek başına Referrer-Policy ayarlamayı kabul edip etmeyeceğini kontrol edin.
  • Eksi: site-one.example kullanıcıları için gizliliği korumaya yönelik düzeyi daha düşük olabilir, tüm tarayıcılarda desteklenmeyebilir.

Siteler Arası İstek Sahteciliği (CSRF) koruması

İstek yayan her zaman bir no-referrer politikası belirleyerek yönlendireni göndermemeye karar verebilir ve kötü niyetli bir aktör yönlendireni sahteleştirebilir.

Birincil koruma olarak CSRF jetonlarını kullanın. Ek koruma için SameSite'ı kullanın ve Referer yerine Origin (POST ve CORS isteklerinde kullanılabilir) ve Sec-Fetch-Site gibi başlıkları kullanın.

Günlük kaydı ve hata ayıklama

Referer içinde bulunabilecek kullanıcıların kişisel veya hassas verilerini koruduğunuzdan emin olun.

Yalnızca kaynağı kullanıyorsanız alternatif olarak Origin üstbilgisini kullanıp kullanamayacağınızı kontrol edin. Bu sayede, yönlendireni ayrıştırmanıza gerek kalmadan, hata ayıklama için ihtiyacınız olan bilgileri daha basit bir şekilde alabilirsiniz.

Ödemeler

Ödeme sağlayıcılar, güvenlik kontrolleri için gelen isteklerin Referer üstbilgisini kullanabilir.

Örneğin:

• Kullanıcı, online-shop.example/cart/checkout üzerinde bir Satın al düğmesini tıklar.
• online-shop.example, işlemi yönetmek için payment-provider.example hedefine yönlendiriyor.
• payment-provider.example, bu isteğin Referer değerini satıcılar tarafından belirlenen izin verilen Referer değerlerinin listesiyle karşılaştırır. Listede herhangi bir girişle eşleşmezse payment-provider.example isteği reddeder. Eşleşme varsa kullanıcı işleme devam edebilir.

Ödeme akışı güvenlik kontrolleriyle ilgili en iyi uygulamalar

Ödeme sağlayıcı olarak, Referer simgesini bazı saldırılara karşı temel bir kontrol olarak kullanabilirsiniz. Ancak Referer üstbilgisi tek başına kontrol için güvenilir bir temel değildir. İster meşru bir satıcı olsun ister olmasın, istekte bulunan site, ödeme sağlayıcının no-referrer bilgilerine erişemeyeceği bir Referer politikası belirleyebilir.

Referer, ödeme sağlayıcıların no-referrer politikası belirlemeyen deneyimsiz saldırganları yakalamasına yardımcı olabilir. İlk kontrol olarak Referer kullanıyorsanız:

• Referer öğesinin her zaman mevcut olmasını beklemeyin. Bu alan varsa yalnızca kaynağı içeren minimum verilerle karşılaştırın.
  • İzin verilen Referer değerlerinin listesini ayarlarken yalnızca kaynağı eklediğinizden ve yol eklemediğinizden emin olun.
  • Örneğin, online-shop.example için izin verilen Referer değerleri online-shop.example/cart/checkout değil, online-shop.example olmalıdır. Hiç Referer olmaması veya yalnızca istekte bulunan sitenin kaynağı olan bir Referer değeri beklenerek satıcının Referrer-Policy hakkında varsayımlarda bulunmaktan kaynaklanabilecek hatalar önlenir.
• Referer yoksa veya varsa ve temel Referer kaynağı kontrolünüz başarılıysa başka bir doğrulama yöntemine geçebilirsiniz.

Ödemeleri daha güvenilir bir şekilde doğrulamak için, talep edenin istek parametrelerini benzersiz bir anahtarla birlikte karma oluşturmasına izin verin. Ödeme sağlayıcılar daha sonra aynı karma oluşturma işlemini sizin tarafınızda hesaplayabilir ve yalnızca hesaplamanızla eşleşirse isteği kabul edebilir.

Yönlendiren politikası olmayan bir HTTP satıcı sitesi, HTTPS ödeme sağlayıcısına yönlendirdiğinde Referer ne olur?

Çoğu tarayıcı, bir web sitesinde politika ayarlanmadığında varsayılan olarak strict-origin-when-cross-origin veya no-referrer-when-downgrade kullandığından HTTPS ödeme sağlayıcısına yapılan istekte Referer görünmez. Chrome'un yeni bir varsayılan politikaya geçmesi bu davranışı değiştirmeyecek.

Sonuç

Koruyucu bir yönlendiren politikası, kullanıcılarınıza daha fazla gizlilik sunmanın harika bir yoludur.

Kullanıcılarınızı korumak için farklı teknikler hakkında daha fazla bilgi edinmek üzere Güvenli ve güvenli koleksiyonumuza göz atın.

Kaynaklar

• "Aynı site" ve "aynı kaynak" kavramlarını anlama
• Yeni bir güvenlik başlığı: Yönlendiren Politikası (2017)
• MDN'de Referrer-Policy
• Yönlendiren üstbilgisi: MDN'deki gizlilik ve güvenlik endişeleri
• Chrome değişikliği: Blink'in uygulama amacı
• Chrome değişikliği: Blink'in kullanıma sunulması
• Chrome değişikliği: durum girişi
• Chrome değişikliği: 85 beta blog yayını
• Yönlendiren kırpma GitHub iş parçacığı: Farklı tarayıcılar ne yapar?
• Referrer-Policy Spec

Tüm yorumculara, özellikle Kaustubha Govind, David Van Cleve, Mike West, Sam Dutton, Rowan Merewood, Jxck ve Kayce Basques'e katkıları ve geri bildirimleri için çok teşekkür ederiz.