CORS Origin başlığı ve CSRF belirteci ile CSRF koruması

103

Bu soru, yalnızca Siteler Arası İstek Sahteciliği saldırılarına karşı korumayla ilgilidir.

Özellikle şunlarla ilgilidir: Origin başlığı (CORS) aracılığıyla koruma, bir CSRF belirteci yoluyla koruma kadar iyi mi?

Misal:

Yani:

  • Origin başlığını (sunucu tarafı) kontrol etmezsek ve CSRF belirteci yoksa, bir CSRF güvenlik açığımız olur.
  • Bir CSRF belirtecini kontrol edersek, güvendeyiz (ama bu biraz sıkıcı).
  • Origin başlığını kontrol edersek, evil.com'un istemci tarafı kodundan gelen istek, bir CSRF belirteci kullanırken olduğu gibi engellenmelidir - bunun dışında, evil.com'un kodunun Origin başlığını ayarlaması mümkünse.

W3C spesifikasyonunun tüm modern tarayıcılarda doğru şekilde uygulanacağına güveniyorsak, bunun XHR ile mümkün olmaması gerektiğini biliyorum (örneğin , kaynak çapraz kaynak paylaşımı için güvenlik ), en azından hayır

Peki ya diğer türden talepler - örneğin form gönderme? Bir script / img / ... etiketi mi yükleniyor? Veya bir sayfanın (yasal olarak) istek oluşturmak için kullanabileceği başka bir yol? Ya da belki bazı bilinen JS hackleri?

Not: hakkında konuşmuyorum

  • yerel uygulamalar,
  • değiştirilmiş tarayıcılar,
  • example.com sayfasındaki siteler arası komut dosyası hataları,
  • ...
javascript  security  cors  csrf 
— Chris Lercher
kaynak
1
Pek çok vekilin kaynak başlığını kaldırdığına inanıyorum.
— thefourtheye
Ve form gönderme ve img / script etiketleri için eski tarayıcılardan emin değiliz, CSP'lere güvenmeliyiz.
— thefourtheye
3
@thefourtheye: Bağlantı TLS üzerinden başlatıldığı için, eğer bir proxy ortadaki adam yapabiliyorsa, kullanıcının CSRF'den çok daha acil bir sorunu vardır.
— Perseids
2
@thefourtheye, neden soyunsunlar Origin? Bu, CORS korumasını ortadan kaldırır.
— Paul Draper
1
Bu soruyu ve cevaplarını seviyorum çünkü belirli bir konu hakkında, ama aynı zamanda bana CSRF ile CORS arasındaki farkı da hatırlatıyorlar. (Bunların kolayca karıştırılamayacak kavramlar olmadığını kabul ediyorum ... Ama yine de onları karıştırmayı başarıyorum.)
— The Red Pea

Yanıtlar:

41

W3C spesifikasyonunun tüm modern tarayıcılarda doğru bir şekilde uygulanacağına güveniyorsak, bunun XHR ile mümkün olmaması gerektiğini bilin (örneğin, kaynak çapraz kaynak paylaşımı için güvenlik), en azından hayır

Günün sonunda, kullanıcının verilerini güvenli bir şekilde depolamak ve oturumun istemci tarafını korumak için istemci tarayıcısına "güvenmeniz" gerekir. İstemci tarayıcısına güvenmiyorsanız, statik içerik dışında herhangi bir şey için web'i kullanmayı bırakmalısınız. CSRF belirteçlerini kullanıyor olsanız bile, istemci tarayıcısına Aynı Kaynak Politikasına doğru bir şekilde uyması için güveniyorsunuz .

IE 5.5 / 6.0'da olduğu gibi saldırganların Aynı Köken İlkesini atlayıp saldırıları gerçekleştirmesinin mümkün olduğu daha önceki tarayıcı güvenlik açıkları olsa da , genellikle bunların keşfedildiği anda yamalanmasını ve çoğu tarayıcının otomatik olarak güncellenmesini bekleyebilirsiniz. bu risk büyük ölçüde azaltılacaktır.

Peki ya diğer türden talepler - örneğin form gönderme? Bir script / img / ... etiketi mi yükleniyor? Veya bir sayfanın (yasal olarak) istek oluşturmak için kullanabileceği başka bir yol? Ya da belki bazı bilinen JS hackleri?

OriginBaşlık normalde yalnızca XHR alanlar arası istekleri için gönderilir. Resim istekleri başlığı içermez.

Not: hakkında konuşmuyorum

  • yerel uygulamalar,

  • değiştirilmiş tarayıcılar,

  • example.com sayfasındaki siteler arası komut dosyası hataları,

Bunun manipüle edilmiş tarayıcıların altına düşüp düşmediğinden emin değilim, ancak Flash'ın eski sürümleri, bir saldırganın refererbir saldırıyı gerçekleştirmek için kurbanın makinesinden sahte bir başlık içeren bir istek göndermesine olanak tanıyan rastgele başlıkların ayarlanmasına izin verdi .

— SilverlightFox
kaynak
Flash örneği iyi bir örnektir - ve belki diğer eklentiler de benzer bir güvenlik açığına sahip olabilir. (Maalesef) Alice'i yalnızca modern bir tarayıcı vb. Kullanıyorsa CSRF'den koruyabilirim, bu çok açık. Ancak, güvenlik konusunda bilinçli bir kullanıcı olarak bile 3. taraf eklentileri kurmuş olması mantıksız değildir - özellikle büyük (güvenilir) şirketlerden olduklarında. Güvenli eklentiler yazsalar bile, CSRF hakkında da düşünüyorlarsa,% 100 ikna olmadım! Dolayısıyla, tarayıcı sanal alanları eklentilerin SOP'yi ihlal etmesini kısıtlamadıkça (olabilirler mi?), CSRF belirtecine bağlı kalmayı tercih ederim.
— Chris Lercher
@ChrisLercher: Evet, günümüzün eklentileri biraz daha sağlam görünüyor. Ancak, herhangi bir anda, bir saldırganın tarayıcı korumalarını atlatacak şekilde onu kullanmasına olanak tanıyan yeni bir sürüm piyasaya sürülebilir. Bununla başa çıkmanın en iyi yolu (örn. Simge / başlık), verilerinizin hassasiyetine ve böyle bir riskin kabul edilebilir olup olmadığına bağlı olacaktır. Flash bir SOP'ye uyar, ancak bir Flash eklentisinin kaynağı, yüklendiği sitedir (JavaScript gibi çağıran site değil). crossdomain.xmlEtki alanları arası iletişimi etkinleştirebilen bir var.
— SilverlightFox
27

Web içeriği, Origin başlığını değiştiremez. Ayrıca, aynı menşe politikası altında, bir kaynak, diğer kaynaklara özel başlıklar bile gönderemez. [1]

Bu nedenle, Origin başlığını kontrol etmek, saldırıları engellemek için bir CSRF belirteci kullanmak kadar iyidir .

Buna güvenmenin temel kaygısı, tüm meşru taleplerin çalışmasına izin verip vermediğidir. Soruyu soran kişi bu sorunu biliyor ve soruyu ana durumları dışlamak için oluşturdu (eski tarayıcılar yok, yalnızca HTTPS).

Tarayıcı satıcıları bu kurallara uyar, peki ya eklentiler? Olmayabilirler, ancak soru "değiştirilmiş tarayıcıları" göz ardı eder. Bir saldırganın Origin başlığını taklit etmesine izin veren tarayıcıdaki hatalar ne olacak? CSRF belirtecinin kökenler arasında da sızmasına izin veren hatalar olabilir, bu nedenle birinin diğerinden daha iyi olduğunu iddia etmek daha fazla çalışma gerektirir.

— misafir
kaynak
5
Firefox 47'yi kısa süre önce test ettim ve çapraz kaynak form gönderisi için bir kaynak başlığı göndermiyor (XHR için CORS'u etkinleştirmeyen REST hizmetlerine saldırmanın yaygın bir yolu), bu yüzden bir kaynak başlık kontrolü olduğunu düşünmüyorum kullanıcı Firefox kullanıyorsa etkili olacaktır.
— Andy
3
Referans olarak, Firefox'un "Origin" başlığı göndermemesi sorunu Bugzilla'da izleniyor: bugzilla.mozilla.org/show_bug.cgi?id=446344 Bu durumda "Referer" başlığını kontrol etmeye geri dönebilirsiniz, ancak benim deneyimime göre biraz Firefox kullanıcıları, gizlilik kaygıları nedeniyle "Referer" başlığını engeller (IMHO, yolu ve sorguyu çıkarmak yeterli olacaktır).
— Steffen
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.