Web sunucuları aynı köken politikasını nasıl uygular?

RESTful API'ler geliştirmek için daha derine dalıyorum ve şimdiye dek bunu başarmak için birkaç farklı çerçeveyle çalıştım. Tabii aynı kökene sahip bir politikaya girdim ve şimdi web sunucularının (web tarayıcıları yerine) bunu nasıl uyguladıklarını merak ediyorum. Anladığım kadarıyla, bazı zorlayıcılar tarayıcının sonunda ortaya çıkıyor (örneğin, bir sunucudan alınan bir Access-Control-Allow-Origin başlığını onurlandırmak). Peki ya sunucu?

Örneğin, bir web sunucusunun, aynı zamanda o sunucuda barındırılan bir API'ye erişen bir Javascript web uygulamasını da barındırdığını varsayalım. Sunucunun aynı orijinli politikayı uygulayacağını ve böylece yalnızca bu sunucuda barındırılan javascript’in API’ye erişmesine izin verileceğini varsayalım. Bu, bir başkasının söz konusu API için bir javascript istemcisi yazmasını ve başka bir sitede barındırmasını engeller, değil mi? Peki bir web sunucusu, aynı web sunucusundan kaynaklanan bir javascript çalıştırdığını iddia ederken AJAX'in API uç noktalarına isteklerini yapmaya çalışacak kötü niyetli bir istemciyi nasıl durdurabilir? En popüler sunucuların (Apache, nginx) bu tür saldırılara karşı korunma şekli nedir? Yoksa bunu bir şekilde işaretleyemem mi?

Yoksa Çapraz kökenli politika yalnızca müşteri tarafında uygulanır mı?

Aynı kökenli ilke tamamen istemci tabanlı bir kısıtlama yoktur ve öncelikle koruma için tasarlanmıştır kullanıcılar değil, hizmet . Tarayıcıların tümü veya çoğu, kapatmak için bir komut satırı düğmesi veya yapılandırma seçeneği içerir. SOP arabadaki emniyet kemerleri gibidir: arabadaki biniciyi korurlar, ancak herkes bunları kullanmamayı özgürce seçebilir. Bir kişinin emniyet kemerinin arabalarından inmelerini ve size saldırmasını (veya Web servisinize erişmesini) kesinlikle engellemeyin.

Web servisinize erişen bir program yazdığımı varsayalım. Sadece HTTP isteklerini içeren TCP mesajları gönderen bir program. Programım tarafından yapılan istekleri (herhangi bir şey gönderebilir) ve izin verilen bir kaynaktan yüklenmiş bir sayfa içeren bir tarayıcı tarafından yapılan istekleri ayırt etmek için bir sunucu tarafı mekanizması istiyorsunuz. Bu sadece yapılamaz; programım her zaman bir Web sayfasının oluşturduğu ile aynı isteği gönderebilir.

Aynı menşe politikası, bir web sitesindeki kodun , başka bir sitede kimlik bilgileriyle kısıtlanmış içeriğe erişmesini engellediği için icat edildi . Ajax istekleri, varsayılan olarak, hedef site tarafından verilen kimlik bilgileriyle birlikte gönderilir. Örneğin, yanlışlıkla http://evil.com/bir istek gönderen yanlışlıkla yüklediğimi varsayalım http://mail.google.com/. SOP yerinde değilse ve Gmail’de oturum açtıysam, konumundaki komut dosyası evil.comgelen kutumu görebilir. Adresindeki site çerezlerim olmadan evil.comyüklenmek mail.google.comistiyorsa, yalnızca bir proxy sunucusu kullanabilir; kamu içeriği mail.google.comgizli değildir (ancak içeriği mail.google.combenim kurabiye erişildiğinde olan gizli).

Aynı köken politikası müşteri tarafında da uygulanmaktadır. Tarayıcı CORS'u destekliyorsa , sunucu, aynı menşe politikasında istisnalar yapması için tarayıcıya söyleyen başlıkları geri gönderebilir. Örneğin, başlığı göndermek

 Access-Control-Allow-Origin: www.example.com

tarayıcıya www.example.com adresinden çapraz kaynaklı isteklere izin vermesini söyler.

 Access-Control-Allow-Origin: *

Tarayıcıya, tüm kaynaklardan gelen isteklere bu kaynağa izin vermesini söyler.

Web sunucuları genellikle Referer, bir isteğin kendi sitelerinde bir sayfadan geldiğinden emin olmak için HTTP başlığındaki (yanlış yazılmış) satırı kontrol ederek bu tür saldırıları önler . Kötü niyetli bir müşteriye karşı korunmanın iyi bir yolu yok, ancak XSRF saldırıları böyle değil.

Müşteri kötü niyetli değil; genellikle kötü niyetli bir üçüncü tarafça müşterinin saklanan çerezlerini kullanarak sessizce bir HTTP isteği yapan bir belge açmak için kandırılan sıradan bir kullanıcıdır. Eğer sunucu Referer, HTTP isteğinin gmail.com'dan geldiğini ve MyAwesomeWebsite.com adresinden gelmediğini doğrulayabilirse, saldırıyı durdurabilir.

Web sunucuları aynı köken politikasını nasıl uygular?

Kısacası, onlar, yapma apsillers ve Dirk dikkat çekti.
Önemli nedenlerden biri , ACAO başlığının sunucuların kendilerini nadir DDOS, Dağıtılmış Hizmet Reddi saldırılarına karşı korumalarıdır .

Kim:

Bir HTTP yanıt başlığı olarak ACAO, web istemcisinin yorumlanması, insan internet kullanıcılarının büyük çoğunluğunun W3C'nin önerdiği taslağı uygulayan ve uygulayan büyük tarayıcı satıcıları aracılığıyla internette gezindiğini varsaydığı anlamına gelir . Hepsinden sonra, hızlı ve erişilebilir bir internetten faydalanmaları gerekir.

Nasıl:

Aksi halde, herhangi biri, birkaç satır javascript kodunu kopyalayıp yapıştırabilir; bu, basit bir döngü çalıştıran kötü amaçlı bir web sitesine yerleştirebilir; bu, Ajax GET'in veya POST'un yabancı bir alana isteğini yapar. Kullanıcı etkileşimi ve çoklu okuma yeteneği olmadan.

Bu nedenle , ACAO HTTP üstbilgisi üzerinden çapraz kökenli bir siteye erişmeyi seçmeniz gerekiyor . Siz, kullanıcı, söz konusu siteye, kullanıcının farkında olduğu bir etkileşim, yani bir internet bağlantısı aracılığıyla her zaman erişebilirsiniz. Tıpkı içeriği sizin panodan veya panoya kopyalayıp yapıştırabileceğiniz gibi, ancak başka bir yolla değil - eklentileri bir kenara bırakın.

Gelecek:

Bu noktada, web tarayıcısının üreticisinin aşağıdaki yönleri dikkate alın:

• tamamen korumalı bir ortama doğru bir adım olarak varsayılan eklentinin kaldırılması ve
• javascript'i kapatmak için kullanıcı seçeneğini kaldırma

Güvenlik kısıtlamaları, TSL 2/3, güçlü oturum kimlikleri, TAN'ler, iki faktörlü kimlik doğrulama vb.

'Google' DDOS hakkında göstermek ve söylemek için bu vardır

Son olarak, herhangi bir kişi web içeriğini proxy olarak kullanmakta ve proxy siteler arası içeriğe erişmek için istenen bir ACAO başlığı eklemekte özgürdür . Benzer şekilde, bu proxy ACAO ayarının yapmasına izin verdiği gibi bir DDOS saldırısına açıktır. Aslında, halka açık tek bir ücretsiz hizmetin ne olduğunu bilmiyorum. Yanılıyorsam beni duzelt lutfen.

Diğerlerinin dediği gibi müşteriye kalmış. Ancak, sunucunun SOP'yi atlayan XSS ile başa çıkması gerekebilir.

Sunucunuzu farz edin, diğer kullanıcılar sitenize göz atarken görüntülenen içeriği yüklemelerine izin verin. Bu sayfa iyi bir örnek - Yeni içerik yükledim ve size görüntülendi.
İçeriğim <script>etiketi içeriyorsa ve sunucu onu oluşturduğu HTML dosyasına kopyalarsa, yüklediğim komut dosyası çalışacaktır.
Komut dosyası, dosyanızda HTML’de bulunduğundan, sitenizin komut dosyasının tüm izinlerine sahiptir. Örneğin, bu cevabı geçersiz kılabilir. Ve bu yüzden bu cevabın bu kadar çok oyu var.

İyi bir web sunucusu (ne yazık ki, StackExchange'in kullandığı gibi), bunun olmasına izin vermez. <script>Etiketi kaldırabilir veya kaçabilir, böylece görülecektir ancak yürütülmeyecektir (uyarı - bu cevap XSS'yi önlemek için güvenilir bir tariften uzaktır).

Bu yüzden SOP'yi uygulayan müşteri tarafıdır, ancak bazı durumlarda sunucunun atlamayı önlemek için çalışması gerekir.