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

Maud Nalpas

Bu sayfada, Yönlendiren Politikanızı ayarlama ve gelen isteklerde yönlendireni kullanma ile ilgili en iyi uygulamalardan bazıları açıklanmaktadır.

Özet

• Kaynaklar arası beklenmedik bilgi sızıntısı, web kullanıcılarının gizliliğine zarar verir. Koruyucu bir yönlendiren politikası bu konuda yardımcı olabilir.
• strict-origin-when-cross-origin yönlendiren politikası ayarlayabilirsiniz. Bu yöntem, yönlendiricinin yararlılığının büyük bir kısmını korurken kaynaktan kaynaka 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 üstbilgileri kullanın.

Yönlendiren ve Yönlendiren Politikası hakkında temel bilgiler

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

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

Referer üstbilgisi farklı türde isteklerde 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.

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

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

1 ile 5 arasındaki URL'ler özel bilgiler ve bazen hassas veya kimliği tanımlayabilecek bilgiler içerir. Bu bilgilerin gizlice kaynaklar arasında sızdırılması, web kullanıcılarının gizliliğini tehlikeye atabilir.

6. URL bir yetenek URL'sidir. Bu e-posta, amaçlanan kullanıcı dışında bir kullanıcı tarafından alınırsa kötü amaçlı bir kişi bu kullanıcının hesabını kontrol altına alabilir.

Sitenizden gelen istekler için hangi yönlendiren verilerinin kullanılabileceğini kısıtlamak istiyorsanız bir yönlendiren politikası ayarlayabilirsiniz.

Hangi politikalar mevcuttur ve bu politikalar arasında ne gibi farklar vardır?

Sekiz politikadan birini seçebilirsiniz. Politikaya bağlı olarak Referer başlığında (ve document.referrer) kullanılabilen veriler şunlar olabilir:

• Veri yok (Referer başlığı yok)
• Yalnızca origin
• Tam URL: kaynak, yol ve sorgu dizesi

Bazı politikalar, bağlama bağlı olarak farklı şekilde davranacak şekilde tasarlanmıştır: kaynaktan farklı veya aynı kaynaktan istek, istek hedefinin kaynak kadar güvenli olup olmadığı veya her ikisi. Bu, kendi sitenizde yönlendiricinin 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 Referer başlığında ve document.referrer'te bulunan 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), bir HTTP kaynağından başka bir HTTP kaynağına yapılan istekleri, HTTP daha az güvenli olsa bile bir HTTPS kaynağından başka bir HTTPS kaynağına yapılan istekler gibi işler. Bunun nedeni, bu politikalarda önemli olanın güvenlik düşüşünün gerçekleşip gerçekleşmediğidir. Yani, istek, HTTPS → HTTP isteklerinde olduğu gibi şifrelenmiş bir kaynaktan şifrelenmemiş bir kaynağa veri gösterebiliyorsa. HTTP → HTTP isteği tamamen şifrelenmemiş olduğundan sürüm düşürme olmaz.
• Bir istek aynı kaynaktan ise şema (HTTPS veya HTTP) aynıdır. Bu nedenle, güvenlik düzeyi düşürülmez.

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

Ekim 2021 itibarıyla

Yönlendirme politikası ayarlanmazsa tarayıcı varsayılan politikasını kullanır.

Yönlendiren politikası ayarlamayla ilgili en iyi uygulamalar

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

• HTTP üst bilgisi olarak
• HTML içinde
• JavaScript'ten istek başına

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

Hem HTTP üstbilgisi hem de meta öğesi sayfa düzeyindedir. Bir öğenin geçerli 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 uyuyor.

Yönlendiren politikasını nasıl görebilirim?

securityheaders.com, belirli bir sitenin 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östermez ancak gönderilen Referer değerini gösterir.

Web siteniz için hangi politikayı ayarlamanız gerekir?

strict-origin-when-cross-origin gibi (veya daha katı) bir gizlilik artırıcı politika belirlemenizi kesinlikle öneririz.

Neden "açıkça"?

Yönlendiren politikası ayarlamazsanız tarayıcının varsayılan politikası kullanılır. Web siteleri genellikle tarayıcının varsayılan politikasını kullanır. Ancak bu ideal bir durum değildir çünkü:

• Farklı tarayıcıların varsayılan politikaları farklıdır. Bu nedenle, tarayıcı varsayılanlarını kullanırsanız siteniz tarayıcılar arasında öngörülebilir şekilde davranmaz.
• Tarayıcılar, strict-origin-when-cross-origin gibi daha katı varsayılan ayarları ve kaynaklar arası istekler için yönlendiren kırpma gibi mekanizmaları kullanır. Tarayıcı varsayılanları değiştirilmeden önce, gizliliği artıran bir politikayı açık bir şekilde etkinleştirmek size kontrol sağlar ve uygun gördüğünüz testler yapmanıza yardımcı olur.

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

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

• Güvenli: Web siteniz HTTPS kullanıyorsa (kullanmıyorsa öncelikli hale getirin) web sitenizin URL'lerinin HTTPS olmayan isteklerde sızmasını istemezsiniz. Ağdaki herkes bunları 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.
• Gizlilik artırıcı: no-referrer-when-downgrade, kaynak farklı olan istekler için tam URL'yi paylaşır. Bu da gizlilik sorunlarına neden olabilir. strict-origin-when-cross-origin ve strict-origin yalnızca kaynağı paylaşır, no-referrer ise hiçbir şey paylaşmaz. Bu durumda da gizliliği artıracak seçenekler olarak strict-origin-when-cross-origin, strict-origin ve no-referrer kullanabilirsiniz.
• Faydalı: no-referrer ve strict-origin, aynı kaynaktan gelen istekler için bile URL'nin tamamını hiçbir zaman 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'un 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 aşamalı bir yaklaşım benimseyin: Web siteniz için strict-origin-when-cross-origin gibi koruyucu bir politika ve gerekirse belirli istekler veya HTML öğeleri için daha izin verici bir politika ayarlayın.

Ö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'});

Neleri göz önünde bulundurmalısınız?

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

Gelen istekler için en iyi uygulamalar

Aşağıda, sitenizde gelen isteklerin yönlendiren URL'si kullanılıyorsa ne yapmanız gerektiğiyle ilgili bazı yönergeler verilmiştir.

Kullanıcı verilerini koruma

Referer özel, kişisel veya kimliği tanımlayabilecek veriler içerebileceğinden bu verileri bu şekilde ele almanız gerekir.

Gelen yönlendiriciler {referer-can-change}

Gelen kaynaklar arası isteklerden yönlendirenin kullanılmasıyla ilgili birkaç sınırlama vardır:

• İstek gönderenin uygulanması üzerinde hiçbir kontrolünüz yoksa aldığınız Referer üstbilgisi (ve document.referrer) hakkında varsayımlarda bulunamazsınız. İstek gönderen, dilerse istediği zaman no-referrer politikasına veya daha genel olarak daha önce kullandığından daha katı bir politikaya geçmeye karar verebilir. Bu, Referer kaynağından daha az veri aldığınız anlamına gelir.
• Tarayıcılar, Referrer-Policy strict-origin-when-cross-origin başlığını varsayılan olarak giderek daha fazla kullanıyor. Bu, gönderen sitede politika ayarlanmamışsa gelen kaynak arası isteklerde artık tam yönlendiren URL'si yerine yalnızca kaynağı alabileceğiniz anlamına gelir.
• Tarayıcılar, Referer ürününü yönetme şeklini değiştirebilir. Örneğin, bazı tarayıcı geliştiricileri, kullanıcı gizliliğini korumak için kaynaktan kaynak arası alt kaynak isteklerinde yönlendiricileri her zaman kaynakla sınırlamaya karar verebilir.
• Referer başlığı (ve document.referrer) ihtiyacınızdan daha fazla veri içerebilir. Örneğin, yalnızca isteğin kaynaklar arası olup olmadığını öğrenmek istediğinizde tam URL'ye sahip olabilir.

Referer yerine alternatifler

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

• Sitenizin önemli bir özelliği, gelen kaynaklar arası isteklerin yönlendiren URL'sini kullanıyor.
• Siteniz artık kaynak dışı isteklerde yönlendiren URL'sinin ihtiyaç duyduğu kısmı almıyor. Bu durum, istek gönderenin politikasını değiştirdiğinde veya politika ayarlanmamışsa ve tarayıcı varsayılan politikası değiştiğinde (ör. Chrome 85'te) ortaya çıkar.

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

Yalnızca kaynak bilgisine ihtiyacınız varsa

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

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

• İstek parametreleri, kullanım alanınızı ele alabilir. Bu sayede yönlendireni ayrıştırma işlemini yapmanıza gerek kalmaz.
• Yönlendiriciyi, sayfaya üst düzey erişimi olan bir komut dosyasında kullanıyorsanız window.location.pathname alternatif olarak kullanılabilir. URL'nin yalnızca yol bölümünü ayıklayıp bağımsız değişken olarak iletin. Böylece, URL parametrelerindeki hassas olabilecek bilgiler aktarılmaz.

Bu alternatifleri kullanamıyorsanız:

• Sistemlerinizi, istek gönderenin (ör. site-one.example) ihtiyacınız olan bilgileri bir tür yapılandırmada açıkça ayarlamasını bekleyeceği şekilde değiştirip değiştiremeyeceğinizi kontrol edin.
  • Artısı: site-one.example kullanıcıları için daha açık, gizliliği daha koruyan, daha geleceğe hazır.
  • Dezavantaj: Sizin tarafınızdan veya sisteminizin kullanıcıları tarafından daha fazla çalışma gerekebilir.
• İstekleri gönderen sitenin öğe başına veya istek başına no-referrer-when-downgrade yönlendiren politikası ayarlayabileceğini kontrol edin.
  • Dezavantaj: site-one.example kullanıcıları için gizliliği koruma konusunda daha az etkili olabilir ve tüm tarayıcılarda desteklenmeyebilir.

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

İstek gönderen, no-referrer politikası belirleyerek yönlendiriciyi göndermemeye her zaman karar verebilir. Kötü niyetli bir kişi, yönlendiriciyi taklit bile edebilir.

Birincil korumanız olarak CSRF jetonlarını kullanın. Daha fazla koruma için SameSite'yi kullanın ve Referer yerine Origin (POST ve CORS isteklerinde kullanılabilir) ve varsa Sec-Fetch-Site gibi üstbilgileri kullanın.

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

Kullanıcıların Referer içinde bulunabilecek 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, hata ayıklama amaçları için ihtiyaç duyduğunuz bilgileri daha basit bir şekilde ve yönlendireni ayrıştırmanıza gerek kalmadan sağlayabilir.

Ö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 sitesinde bir Satın Al düğmesini tıklar.
• online-shop.example, işlemi yönetmek için payment-provider.example adresine yönlendirir.
• payment-provider.example, bu isteğin Referer değerini, satıcılar tarafından ayarlanan izin verilen Referer değerleri listesiyle karşılaştırarak kontrol eder. Listedeki hiçbir girişle eşleşmezse payment-provider.example isteği reddeder. Eşleşme olması durumunda kullanıcı işleme devam edebilir.

Ödeme akışı güvenlik kontrolleri için en iyi uygulamalar

Ödeme sağlayıcısı olarak, bazı saldırılara karşı temel bir kontrol olarak Referer kullanabilirsiniz. Ancak Referer üstbilgisi tek başına kontrol için güvenilir bir temel değildir. İstekte bulunan site, yasal bir satıcı olup olmadığına bakılmaksızın, Referer bilgilerinin ödeme sağlayıcı tarafından kullanılamamasını sağlayan bir no-referrer politikası belirleyebilir.

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

• Referer değerinin her zaman mevcut olmasını beklemeyin. Mevcutsa yalnızca içerebileceği minimum verilerle (kaynak) 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 bekleyerek satıcının Referrer-Policy ürünü hakkında varsayımlarda bulunmaktan kaynaklanabilecek hataları önlersiniz.
• Referer yoksa veya varsa ve temel Referer kaynağı kontrolünüz başarılıysa daha güvenilir başka bir doğrulama yöntemine geçebilirsiniz.

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

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

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

Sonuç

Kullanıcılarınıza daha fazla gizlilik sunmanın mükemmel bir yolu, koruyucu bir yönlendiren politikası kullanmaktır.

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

Kaynaklar

• "Aynı site" ve "aynı kaynak" terimlerini anlama
• Yeni bir güvenlik başlığı: Yönlendiren Politikası (2017)
• MDN'de Referrer-Policy
• Yönlendiren başlık: MDN'de gizlilik ve güvenlikle ilgili sorunlar
• Chrome değişikliği: Blink intent'i uygulama
• Chrome değişikliği: Blink intent kullanıma sunulacak
• Chrome değişikliği: durum girişi
• Chrome değişikliği: 85 beta blog yayını
• Referrer trimming GitHub thread: what different browsers do
• Referrer-Policy Spesifikasyonu

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