Bu sayfada, Referrer-Policy'nizi ayarlama ve gelen isteklerde yönlendireni kullanma konusunda bazı en iyi uygulamalar özetlenmektedir.
Özet
- Beklenmeyen merkezler arası bilgi sızıntısı, web kullanıcılarının gizliliğine zarar veriyor. Koruyucu bir yönlendiren politikası yardımcı olabilir.
strict-origin-when-cross-origin
yönlendiren politikası belirleyebilirsiniz. Yönlendirenin kullanışlılığının büyük bir kısmını korurken kaynaklar arasında veri sızıntısı riskini azaltır.- Siteler Arası İstek Sahtekarlığı (CSRF) koruması için yönlendirenler kullanmayın. Bunun yerine CSRF jetonları ve ek bir güvenlik katmanı olarak diğer başlıkları kullanın.
Yönlendiren ve Yönlendiren Politikası 101
HTTP istekleri, isteğin yapıldığı kaynak veya web sayfası URL'sini belirten isteğe bağlı bir Referer
üst bilgisi içerebilir. Referrer-Policy
üst bilgisi, Referer
üst bilgisinde hangi verilerin kullanıma sunulacağını tanımlar.
Aşağıdaki örnekte Referer
başlığı, site-one
sitesindeki isteğin yapıldığı sayfanın tam URL'sini içerir.
Referer
başlığı farklı istek türlerinde olabilir:
- Kullanıcı bir bağlantıyı tıkladığında gezinme istekleri.
- Bir tarayıcı bir sayfanın ihtiyaç duyduğu resimler, iframe'ler, komut dosyaları ve diğer kaynakları istediğinde alt kaynak istekleri.
Gezinmeler 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
konumundan geldiğini belirlemek için bunları kullanabilir. Ancak yol ve sorgu dizesi dahil tam URL, kaynaklar genelinde Referer
içinde gönderildiğinde kullanıcı gizliliğini tehlikeye atabilir ve güvenlik riskleri oluşturabilir:
1'den 5'e kadar olan URL'ler özel bilgiler ve bazen de hassas veya tanımlayıcı bilgiler içeriyor. Bunları sessizce belirli bir kaynaktan sızdırmak web kullanıcılarının gizliliğini tehlikeye atabilir.
6. URL bir özellik URL'sidir. Bu e-posta, hedeflenen kullanıcı dışında bir kişi tarafından kullanılırsa kötü amaçlı bir kişi bu kullanıcının hesabının kontrolünü ele geçirebilir.
Sitenizden gelen istekler için hangi yönlendiren verilerinin kullanıma sunulacağını kısıtlamak için bir yönlendiren politikası ayarlayabilirsiniz.
Hangi politikalar kullanılabilir ve nasıl farklılık gösterir?
Sekiz politikadan birini seçebilirsiniz. Politikaya bağlı olarak Referer
başlığından (ve document.referrer
) kullanılabilen veriler aşağıdaki gibi olabilir:
- Veri yok (
Referer
başlığı yok) - Yalnızca origin
- Tam URL: kaynak, yol ve sorgu dizesi
Bazı politikalar, bağlama şartlarına (kaynaklar arası veya aynı kaynak isteği, istek hedefinin kaynak kadar güvenli olup olmadığı veya her ikisi) bağlı olarak farklı şekilde davranacak şekilde tasarlanmıştır. Bu, kendi sitenizdeki yönlendirenin zenginliğini korurken, kaynaklar arasında paylaşılan bilgi miktarını veya güvenliği daha düşük kaynaklarla sınırlandırmak için yararlı olur.
Aşağıdaki tabloda, yönlendiren politikalarının Yönlendiren üstbilgisinden ve document.referrer
ürününden kullanılabilen URL verilerini nasıl kısıtladığı gösterilmektedir:
Politika kapsamı | Politika adı | Başvuran: Veri yok | Yönlendiren: Yalnızca kaynak | Yönlendiren: Tam URL |
---|---|---|---|---|
İsteğin bağlamı dikkate alınmaz | no-referrer |
çek | ||
origin |
çek | |||
unsafe-url |
çek | |||
Güvenlik odaklı | strict-origin |
HTTPS'den HTTP'ye istek | HTTPS'den HTTPS'ye veya HTTP'den HTTP'ye istek |
|
no-referrer-when-downgrade |
HTTPS'den HTTP'ye istek | HTTPS'den HTTPS'ye veya HTTP'den HTTP'ye istek |
||
Gizlilik odaklı | origin-when-cross-origin |
Kaynaklar arası istek | Aynı kaynak isteği | |
same-origin |
Kaynaklar arası istek | Aynı kaynak isteği | ||
Gizlilik ve güvenlik odaklı | strict-origin-when-cross-origin |
HTTPS'den HTTP'ye istek | Çapraz kaynak isteği HTTPS'den HTTPS'ye veya HTTP'den HTTP'ye |
Aynı kaynak isteği |
MDN, politika ve davranış örneklerinin tam listesini sağlar.
Bir yönlendiren politikası belirlerken göz önünde bulundurmanız gereken bazı noktalar şunlardır:
- Şemayı (HTTPS - HTTP) dikkate alan tüm politikalar (
strict-origin
,no-referrer-when-downgrade
vestrict-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 isteklerle aynı şekilde ele alır. Bunun nedeni, bu politikalar için önemli olan, güvenlikte eski sürüme geçişin yapılıp yapılmadığıdır. Diğer bir deyişle, isteğin şifrelenmiş bir kaynaktan gelen verileri, HTTPS → HTTP isteklerinde olduğu gibi şifrelenmemiş bir kaynağa ifşa edip edemeyeceğidir. HTTP → HTTP isteği tamamen şifrelenmemiş olduğu için eski sürüme geçilemez. - Bir isteğin same-origin olması, şemanın (HTTPS veya HTTP) aynı olduğu anlamına gelir. Bu şekilde güvenlik düzeyi düşürülmez.
Tarayıcılarda varsayılan yönlendiren politikaları
Ekim 2021 itibarıyla
Bir yönlendiren politikası belirlenmemişse tarayıcı varsayılan politikasını kullanır.
Tarayıcı | Varsayılan Referrer-Policy / Davranış |
---|---|
Chrome |
Varsayılan değer: strict-origin-when-cross-origin .
|
Firefox |
Varsayılan değer: strict-origin-when-cross-origin .93 sürümünden itibaren, Katı İzleme Koruması ve Özel Tarama kullanıcıları için daha az kısıtlayıcı olan no-referrer-when-downgrade , origin-when-cross-origin ve unsafe-url yönlendiren politikaları siteler arası istekler için yok sayılır. Diğer bir deyişle, web sitesinin politikasından bağımsız olarak, siteler arası istekler için yönlendiren her zaman kırpılır.
|
Edge |
Varsayılan değer: strict-origin-when-cross-origin .
|
Safari |
Varsayılan ayar strict-origin-when-cross-origin ile benzerdir ancak bazı farklılıklar vardır. Ayrıntılar için
İzlemeyi Önleme Takibini Engelleme bölümüne bakın.
|
Yönlendiren politikası belirlemek için en iyi uygulamalar
Siteniz için yönlendiren politikaları ayarlamanın farklı yolları vardır:
- HTTP başlığı olarak
- HTML
- JavaScript'ten istek bazında
Farklı sayfalar, istekler veya öğeler için farklı politikalar belirleyebilirsiniz.
Hem HTTP üstbilgisi hem de meta öğesi sayfa düzeyindedir. Bir öğenin etkili politikasını belirlemek için öncelik sırası şu şekildedir:
- Öğe düzeyinde politika
- Sayfa düzeyinde politika
- Tarayıcı varsayılanı
Örnek:
index.html
:
<meta name="referrer" content="strict-origin-when-cross-origin" />
<img src="..." referrerpolicy="no-referrer-when-downgrade" />
Görüntü, no-referrer-when-downgrade
politikasıyla istenir ve bu sayfadaki diğer tüm alt kaynak istekleri strict-origin-when-cross-origin
politikasına uyar.
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 yazının yazıldığı sırada Safari, Referrer-Policy
üst bilgisini göstermez ancak gönderilen Referer
bilgisini göstermektedir.
Web siteniz için hangi politikayı belirlemelisiniz?
strict-origin-when-cross-origin
gibi (veya daha katı) bir gizlilik artırıcı politika belirlemenizi kesinlikle öneririz.
Neden "açıkça"?
Bir yönlendiren politikası belirlemezseniz tarayıcının varsayılan politikası kullanılır. Hatta, web siteleri genellikle tarayıcının varsayılan politikasını tercih eder. Ancak bu ideal bir seçenek değildir, çünkü:
- Farklı tarayıcıların farklı varsayılan politikaları vardır. Bu nedenle, tarayıcı varsayılan ayarlarını kullanırsanız siteniz tüm tarayıcılarda tahmin edilebilir şekilde çalışmaz.
- 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ı kullanmaktadır. Tarayıcı varsayılanları değişmeden önce bir gizliliği iyileştiren politikayı açıkça etkinleştirmek, kontrol sahibi olmanızı sağlar ve uygun gördüğünüz şekilde testler yapmanıza yardımcı olur.
Neden strict-origin-when-cross-origin
(veya daha katı)?
Güvenli, gizliliği artıran ve yararlı bir politikaya ihtiyacınız vardır. "Yararlı" ifadesinin ne anlama geldiği yönlendirenden ne istediğinize bağlıdır:
- Güvenli: Web siteniz HTTPS kullanıyorsa (kullanılmıyorsa öncelikli hale getirin), web sitenizin URL'lerinin HTTPS olmayan isteklerde sızmasını istemezsiniz. Ağdaki herkes bunları görebildiğinden, sızıntılar kullanıcılarınızı ortadaki kişi saldırılarına maruz bırakır.
no-referrer-when-downgrade
,strict-origin-when-cross-origin
,no-referrer
vestrict-origin
politikaları bu sorunu çözmektedir. - Gizliliği artıran: Kaynaklar arası istekler için
no-referrer-when-downgrade
, tam URL'yi paylaşır. Bu durum gizlilik sorunlarına neden olabilir.strict-origin-when-cross-origin
vestrict-origin
yalnızca kaynağı paylaşır.no-referrer
ise hiçbir şey paylaşmaz. Bu durumda, gizliliği artıran seçenekler olarakstrict-origin-when-cross-origin
,strict-origin
veno-referrer
sunulur. - Yararlı:
no-referrer
vestrict-origin
, aynı kaynak istekleri için bile tam URL'yi hiçbir zaman paylaşmaz. Tam URL'ye ihtiyacınız varsastrict-origin-when-cross-origin
daha iyi bir seçenektir.
Tüm bunlar, strict-origin-when-cross-origin
'in genellikle mantıklı bir seçim olduğu anlamına gelir.
Örnek: strict-origin-when-cross-origin
politikası belirleme
index.html
:
<meta name="referrer" content="strict-origin-when-cross-origin" />
Veya sunucu tarafında, örneğin Express'te:
const helmet = require('helmet');
app.use(helmet.referrerPolicy({policy: 'strict-origin-when-cross-origin'}));
strict-origin-when-cross-origin
(veya daha katı) seçeneği tüm kullanım alanlarınıza uymuyorsa ne olur?
Bu durumda progresif bir yaklaşım kullanın: Web siteniz için strict-origin-when-cross-origin
gibi koruyucu bir politika ve gerekirse belirli istekler ya da HTML öğeleri için daha geniş kapsamlı 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
üst bilgisini sınırlandırabilir.
Ayrıntıları inceleyin.
Örnek: istek düzeyinde politika
script.js
:
fetch(url, {referrerPolicy: 'no-referrer-when-downgrade'});
Başka neleri göz önünde bulundurmalısınız?
Politikanız siz, ekibiniz ve şirketiniz tarafından belirlenen web sitenize ve kullanım alanlarına bağlı olmalıdır. Bazı URL'ler tanımlayıcı veya hassas veriler içeriyorsa bir koruyucu politika belirleyin.
Gelen istekler için en iyi uygulamalar
Siteniz gelen isteklerin yönlendiren URL'sini kullanıyorsa ne yapmanız gerektiğiyle ilgili bazı yönergeler aşağıda verilmiştir.
Kullanıcı verilerini koruyun
Referer
gizli, kişisel veya tanımlayıcı veriler içerebilir. Bu nedenle, bu verileri uygun şekilde kullandığınızdan emin olun.
Gelen yönlendirenler {referer-can-change} değiştirebilir
Gelen çapraz kaynak isteklerinden yönlendireni kullanmayla ilgili birkaç sınırlama vardır:
- İstek ileticinin uygulaması üzerinde kontrolünüz yoksa aldığınız
Referer
başlığı (vedocument.referrer
) hakkında varsayımlarda bulunamazsınız. İstek iletici, istediği zaman birno-referrer
politikasına veya daha genel olarak, önceden kullandığından daha katı bir politikaya geçmeye karar verebilir. Bu,Referer
ürününden geçmişe kıyasla daha az veri alacağınız anlamına gelir. - Tarayıcılar, varsayılan olarak Referrer-Policy
strict-origin-when-cross-origin
'yi giderek daha fazla kullanmaktadır. Bu, gönderen sitede hiçbir politika ayarlanmamışsa gelen çapraz kaynak isteklerinde artık tam yönlendiren URL'si yerine yalnızca kaynağı alabileceğiniz anlamına gelir. - Tarayıcılar
Referer
sayfasını yönetme biçimlerini değiştirebilir. Örneğin, bazı tarayıcı geliştiricileri, kullanıcı gizliliğini korumak için çapraz kaynak alt kaynakları isteklerinde yönlendirenleri her zaman yalnızca kaynağa yönlendirmeye karar verebilir. Referer
başlığı (vedocument.referrer
) ihtiyacınız olandan daha fazla veri içerebilir. Örneğin, isteğin çapraz kaynak olup olmadığını öğrenmek istiyorsanız tam URL'si olabilir.
Referer
alternatifleri
Aşağıdaki durumlarda alternatifleri değerlendirmeniz gerekebilir:
- Sitenizin önemli bir özelliği, gelen çapraz kaynak isteklerinin yönlendiren URL'sini kullanır.
- Siteniz artık çapraz kaynak isteğinde ihtiyaç duyduğu yönlendiren URL'sinin parçasını almıyor. Bu durum, istek gönderen kişi 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 öncelikle, yönlendirenin hangi bölümünü kullandığınızı analiz edin.
Yalnızca kaynak kaynağına ihtiyacınız varsa
- Yönlendireni sayfaya üst düzey erişimi olan bir komut dosyasında kullanıyorsanız
window.location.origin
alternatif bir çözümdür. - Varsa
Origin
veSec-Fetch-Site
gibi başlıklar, sizeOrigin
bilgisini verir veya isteğin çapraz kaynak olup olmadığını açıklar. Bu, tam olarak ihtiyaç duyduğunuz şey olabilir.
URL'nin başka öğelerine (yol, sorgu parametreleri...) ihtiyacınız varsa
- İstek parametreleri kullanım alanınıza uygun olabilir. Bu da sizi yönlendireni ayrıştırma zahmetinden kurtarır.
- Yönlendireni sayfaya üst düzey erişimi olan bir komut dosyasında kullanıyorsanız,
window.location.pathname
alternatif olarak çalışabilir. URL'nin yalnızca yol bölümünü çıkarıp bağımsız değişken olarak aktarın. Böylece URL parametrelerindeki hassas olabilecek bilgiler aktarılmaz.
Bu alternatifleri kullanamıyorsanız:
- Sistemlerinizi, istek ileticinin (örneğin,
site-one.example
) bir tür yapılandırmada ihtiyaç duyduğunuz bilgileri 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 anlaşılır, gizliliği daha fazla korur ve geleceğe daha iyi uyum sağlar. - Dezavantajı: Potansiyel olarak sizin tarafınızdan veya sistem kullanıcılarının daha fazla iş yükü olur.
- Avantajı:
- İstekleri gönderen sitenin,
no-referrer-when-downgrade
için öğe başına veya istek başına bir Yönlendirme Politikası ayarlamayı kabul edip edemeyeceğini kontrol edin.- Dezavantaj:
site-one.example
kullanıcıları için gizliliği daha az koruyabilir ve tüm tarayıcılarda desteklenmeyebilir.
- Dezavantaj:
Siteler Arası İstek Sahtekarlığı (CSRF) koruması
İstek gönderen her zaman bir no-referrer
politikası belirleyerek yönlendireni göndermemeye karar verebilir ve kötü amaçlı bir kişi yönlendireni bile taklit edebilir.
Birincil korumanız olarak CSRF jetonları kullanın. Daha fazla koruma için SameSite kullanın ve Referer
yerine Origin
(POST ve CORS isteklerinde kullanılabilir) ve varsa Sec-Fetch-Site
gibi başlıkları kullanın.
Günlük ve hata ayıklama
Kullanıcıların Referer
içinde olabilecek kişisel veya hassas verilerini koruduğunuzdan emin olun.
Yalnızca kaynağı kullanıyorsanız alternatif olarak Origin
üst bilgisini kullanıp kullanamayacağınızı kontrol edin. Bu, hata ayıklama amacıyla ihtiyacınız olan bilgileri daha basit bir şekilde ve yönlendireni ayrıştırmanıza gerek kalmadan verebilir.
Ödemeler
Ödeme sağlayıcılar, güvenlik kontrolleri için gelen isteklerin Referer
başlığını kullanabilir.
Örneğin:
- Kullanıcı,
online-shop.example/cart/checkout
ürününde Satın al düğmesini tıklar. online-shop.example
, işlemi yönetmek içinpayment-provider.example
öğesine yönlendirir.payment-provider.example
, bu isteğinReferer
değerini, satıcılar tarafından ayarlanan izin verilenReferer
değerleri listesiyle karşılaştırarak kontrol eder. Listedeki hiçbir girişle eşleşmezsepayment-provider.example
isteği reddeder. Eşleşirse kullanıcı işleme devam edebilir.
Ödeme akışı güvenlik kontrolleri için en iyi uygulamalar
Ödeme sağlayıcı olarak Referer
hizmetini bazı saldırılara karşı temel bir kontrol olarak kullanabilirsiniz. Bununla birlikte, Referer
üst bilgisi tek başına kontrol için güvenilir bir temel değildir. İstekte bulunan site, yasal bir satıcı olsun veya olmasın, Referer
bilgilerini ödeme
sağlayıcının kullanımına engelleyen bir no-referrer
politikası belirleyebilir.
Referer
incelemek, ödeme sağlayıcıların no-referrer
politikası belirlememiş naif saldırganları yakalamasına yardımcı olabilir. İlk kontrol olarak Referer
kullanırsanız:
Referer
öğesinin her zaman mevcut olmasını beklemeyin. Dosya varsa yalnızca içerebileceği minimum verilerle, yani kaynakla karşılaştırarak kontrol edin.- İzin verilen
Referer
değerlerinin listesini ayarlarken yalnızca kaynağı dahil ettiğinizden ve yol eklemediğinizden emin olun. - Örneğin,
online-shop.example
için izin verilenReferer
değerlerionline-shop.example/cart/checkout
değilonline-shop.example
olmalıdır. HiçReferer
olmaması veya yalnızca istekte bulunan sitenin kaynağı olan birReferer
değeri bekleyerek, satıcınınReferrer-Policy
hakkında varsayımlarda bulunmaktan oluşabilecek hataları engellersiniz.
- İzin verilen
Referer
yoksa veya varsa ve temelReferer
kaynak 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 istekte bulunan kişinin, benzersiz bir anahtarla istek parametrelerini karma hale getirmesine izin verin. Daha sonra ödeme sağlayıcıları, aynı karmayı kendi tarafınızda hesaplayabilir ve isteği yalnızca hesaplamanızla eşleşiyorsa kabul edebilir.
Yönlendiren politikası olmayan bir HTTP satıcı sitesi bir HTTPS ödeme sağlayıcıya yönlendirirse Referer
öğesine ne olur?
Bir web sitesinde bir 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ıya gönderilen istekte Referer
görünmez.
Chrome'un yeni bir varsayılan politikaya geçmesi bu davranışı değiştirmez.
Sonuç
Koruyucu bir yönlendiren politikası, kullanıcılarınıza daha fazla gizlilik sağlamanın harika bir yoludur.
Kullanıcılarınızı korumak amacıyla kullanılan farklı teknikler hakkında daha fazla bilgi edinmek için Güvenli ve güvenli koleksiyonumuza göz atın.
Kaynaklar
- "Aynı site" ve "aynı-kaynak"ı anlama
- Yeni bir güvenlik başlığı: Yönlendiren Politikası (2017)
- MDN'deki Yönlendiren Politikası
- Yönlendiren başlığı: MDN'de gizlilik ve güvenlikle ilgili endişeler
- Chrome değişikliği: Uygulamak için niyeti göz ardı etmeyin
- Chrome değişikliği: Kargonuzu gönderme isteğini göz önünde bulundurun
- Chrome değişikliği: Durum girişi
- Chrome değişikliği: 85 beta blog yayını
- Yönlendiren GitHub iş parçacığını kırpma: farklı tarayıcılar ne yapar?
- Yönlendiren Politikası Spesifikasyonu
Başta 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.