Soru:
HTTP 403. 200 - "Sessiz Yönetici Kimliği"
greggles
2013-07-22 20:11:55 UTC
view on stackexchange narkive permalink

Bir araştırmacı, kısa süre önce bir sitede, bir kullanıcının yönetici olup olmadığını keşfetmek için üçüncü taraf bir sitede komut dosyası kullanma ile ilgili bir sorun bildirdi.

Senaryo şu:

  • Ana site target.example
  • Saldırgan site evil.example
  • target.example SSL ve HSTS'ye sahiptir ve 301 yeniden yönlendirmesi kullanarak tüm http trafiğini https'ye yönlendirir
  • target.example'daki oturum çerezi HTponly'dir ve "güvenlidir"
  • evil.example, javascript yükleyen javascript içerir target.example / admin / utility'den gelen src ve bu html sayfasını yüklemenin başarı / hatasının kullanılması javascript saldırısı gerçekleştirebilir

evil.example üzerinde olacak örnek javascript:

  <script type = "text / javascript" src = "https: //www.target.example/admin/utility" onload = "alert ('Merhaba, Yönetici')" onerror = "alert ('Tamam, siz yönetici değildir ') "async =" async ">< / script> 

Bu teknik, sitenin yönetici sayfalarında 200 yerine 403 döndürmesi gerçeğinden yararlanır. Öneri, 403 hatasını döndürmek yerine oturumu kapatılan kullanıcılar için yönetici sayfalarında 200 hatası döndürmekti.

403 veya 404 döndürmenin getirdiği risk, saldırganın yalnızca tanıdığı kullanıcılara saldırı göndermesidir. yöneticilerdir. Bu, saldırganın siteyi parmak izine bırakmasına veya onu kötüye kullanma girişiminde bulunmasına izin verir ve günlüklerdeki tek "gürültü", hata günlüğündeki normal 403 hata sayısından daha fazla olur ve bu da diğer etkinlik türleri kadar şüphe uyandırmayabilir. / p>

Soru: 200 döndürmek gerçekten pratik bir güvenlik avantajı sağlıyor mu? Bu, birçok sitenin yaptığı bir şey mi?

Hangi işletme, ilk etapta "zararsız konum" yerel aracı olmadan üçüncü tarafça barındırılan kaynaklara erişen yalnızca yönetici yerel belgesine sahiptir? Harici kaynaklara bağımlılığı en aza indirmeye çalışın ve geri kalanı için, herhangi bir harici istekleri engelleyecek, bunları yönetici istemciniz adına talep edecek ve bunları isteğe geri gönderecek, yerel olarak barındırılan bir aracı yeniden yönlendirici / proxy (bazen _anonymizers_ olarak da adlandırılır) kullanın. yerel bir yol kullanan kaynak müşteri. Bunu sizin için çevrimiçi olarak bulunabilecek çok sayıda yeniden kullanılabilir kaynak var ve sorununuz ortadan kalkacak.
Dört yanıtlar:
e-sushi
2013-07-22 20:39:47 UTC
view on stackexchange narkive permalink

  • Genellikle…”

    İstenen yerde bir kaynak olduğunu web istemcilere söylemek istemediğiniz sürece 200 OK vermem URI ve erişilebilir olması (örneğin: arama motorları tarafından dizine eklenecek). Özellikle, talepte bulunan müşteri yetkilendirmediği sürece korunan alanlar için asla 200 OK iade etmem.

    Ayrıntılar ...

    Bahsettiğiniz HTTP durum kodları hakkında size biraz fikir vereyim:

      200 OK 

    Botları (ve meraklıları) anlatır URI isteğinin geçerli olduğunu ve hedef kaynağın (html sayfası, css dosyası, ZIP indirmesi, her neyse) var olduğunu ve bu başlıkla birlikte döndürüldüğünü.

    Ne olur: talep ediyor müşteriye kaynağın var olduğu ve kullanılabilir olduğu söylenir. Arama motorları gibi botlar tarafından dizine eklenebilir ve indekslenecektir.

      403 Yasak  

    Botlara (ve meraklılara) URI isteğinin istemci olarak geçersiz olduğunu söyler veriyi istemek, o kaynağı istemek için uygun yetkiye sahip değil.

    Ne olur: talep eden müşteriye kaynağın var olduğu, ancak onu alma yetkisinin olmadığı söylenir. Kimlik doğrulama gerekli olduğu için "bunu yapmanıza izin verilmiyor" derken kapıyı birisinin burnuna çarpmak gibidir. İyi huylu botlar ve arama motorları buna saygı duyacak ve bu 403 Yasak 'ı neredeyse bir 404 Bulunamadı gibi ele alacak. URI'yi yeniden ziyaret etmek için iyi bir nedenleri olmadıkça URI'yi ziyaret etmeyi tekrar denemeyecekler. Örnek: bu URI'ye işaret eden yeni bağlantıları kontrol ederken.

      404 Bulunamadı  

    Botlara (ve meraklılara) URI isteğinin URI olarak geçersiz olduğunu söyler kullanılan, sunucudaki mevcut verilere işaret etmez.

    Ne olur: İsteyen müşteriye kaynağın mevcut olmadığı söylenir. Bu "burada bir şey yok, bir daha denemeyin" demek gibi. İyi huylu botlar ve arama motorları, URI'yi tekrar ziyaret etmek için iyi bir nedenleri olmadıkça URI'yi tekrar ziyaret etmeyi denemeyecektir. Örnek: o URI'ye işaret eden yeni bağlantıları kontrol ederken.

    Güvenlik açısından…

    Her zaman doğru olanı döndürmelisiniz duruma uygun başlık. Bariz protokol nedenlerinin yanı sıra, size neden doğru başlıkların gerekli olduğuna basit bir örnek vereyim: Kötü niyetli birinin sitenizi ele geçirmeye çalıştığını düşünün. Her zaman 200 OK döndürürseniz, iyi 'yi kötü isteklerden filtrelemekte zorlanacaksınız. Ancak, örneğin - sunucu günlüklerinizde bir dizi 403 Yasak olduğunu fark ederseniz, zaman damgasını, IP'yi ve Kullanıcı Aracısını tespit etmek kolaydır ... müşteri istekleri.

  • Evet, yanıt kodu amaçlarına aşinayım;) Son paragraf sağlam bir tavsiyedir. Bunun için teşekkürler.
    @greggles Olumlu geribildirim için teşekkürler! Durum kodu bilgilerine gelince: Sorunuzdan bilgi düzeyinizi okuyamadım, bu yüzden bu bilgiyi * her ihtimale karşı * sağladım. Sonuçta, bu şeyleri okuyan ve bizim gibi durum kodlarını bilip bilmediğini bilen o * sonraki * kişi her zaman vardır. ;) Umarım çok detaylı girip ayak parmaklarına basmamışımdır?
    Hiç sorun değil. Çok uygun başlık kullanımınız, önemsediğim kısma göz atmama izin verdi;)
    Tom Leek
    2013-07-22 20:41:48 UTC
    view on stackexchange narkive permalink

    Bir kullanıcı bir "yönetici" sayfasına erişmeye çalıştığında, tarayıcısı kesinlikle bir HTTP yanıt kodu (200, 403 ...) alır, ancak aynı zamanda bir sayfa da alır ve kullanıcının "yönetici" veya "yönetici" olmasına bağlı olarak farklıdır. Yüklemeyi tetikleyen Javascript kodun yanı sıra sayfaya da bakabilir. 403'ü 200 olarak taklit etmek, yalnızca en aptal saldırganlara zarar verir; bu, gerçekten umursamayan, yani saldırganlar için kesinlikle en az endişe verici olanıdır.

    Bir kullanıcı, gerekli olan bir siteye ulaştığında kimlik doğrulaması, bu site genellikle kullanıcıyı bir "oturum açma sayfasına" yönlendirir. Diğer bir deyişle, site bir 401 yanıtı göndermez (bu, HTTP'nin yazdığı gibi), bunun yerine bir sayfa için sadece bir metin içeren bir 200 yanıtı gönderiyor insan tüketimi , "Giriş yapmalısınız" yazan metin. Bu bir güvenlik özelliği değildir ve hiçbir zaman olmamıştır; bunun nedeni, tarayıcının 401 ile karşılaşıldığında görüntülediği açılır pencereler tamamen çirkin.

    "403 vs 200" durumunuz da aynı: güvenlik için yapmak istemezsiniz nedenler (çünkü hakkında konuşmaya değer herhangi bir güvenlik sağlamayacaktır) ancak bunu estetik nedenlerle yapmak isteyebilirsiniz (örneğin, yetkisiz kullanıcıları sorunsuz bir şekilde güzel görünen bir "yönetici olmayan" sayfaya yönlendirmek için).

    "Yüklemeyi tetikleyen Javascript, koda bakabilir, aynı zamanda sayfaya da bakabilir." Dediniz. ancak Aynı Kaynak Politikasının javascript'in sayfaya bakmasını engellediğini düşündüm. Senaryonun sayfayı nasıl okuyabileceğini biraz daha açabilir misin?
    Haklısınız, bu bağlamda SÇP gerçek okumayı engellemeye çalışacak, ancak hata kodunu sızdırabilir (veya en azından bir hata olduğu gerçeği). Gerçekten de bu şekilde küçük bir bilgi sızıntısı var. Yine de çok ciddi bulmuyorum. Bu biraz daha fazla düşünme süresini hak ediyor.
    symcbean
    2013-07-22 20:28:32 UTC
    view on stackexchange narkive permalink

    IMHO bu, siteye saldıran herkesin atlaması için çok küçük bir engel oluşturur. Bu, giriş geçersiz olduğunda içeriği de taklit ettiğiniz anlamına mı geliyor? Tüm geçersiz girişler için tam bir bal kabı oluşturulsun mu?

    Geçersiz girişlerin çoğu, bildiğimiz şekliyle uygarlığın sonunu getirmeye çalışan teröristlerden kaynaklanmaz - genellikle bu sadece büyük harf kilidi düğmesidir. Bu nedenle, kullanıcılara, sağladıkları kimlik doğrulama bilgilerinin başarılı olmadığını söylemeniz gerekir.

    Kimlik doğrulama yanıtının makine tarafından okunabilir olması amaçlanıyorsa , o zaman onu basit ve açık hale getirmek için daha da fazla neden vardır (ancak Javascript kullanımınızdan çok fazla çıkarım yapıyor olabilirim).

    yalnızca yönetici olduğunu bildikleri kullanıcılara saldırılar gönderecek

    ... ve belki de değil. Bu, javascript koduyla birleştiğinde, buradaki güvenlik modelinde biraz şüpheli bir şeyler olduğunu düşünmeme neden oluyor.

    Kimlik doğrulama geçişlerini güvence altına almak için yapmanız gereken pek çok şey var, ancak kasıtlı olarak HTTP yanıtını taklit etmeyi düşünüyorum Saldırganları caydırmak amacıyla geçersiz kimlik bilgilerine yanıt olarak verilen kod, zararlıdır.

    (Saldırı olduğuna inanılan bir isteğe yanıt olarak yanıt kodunu taklit etmek farklı bir hikaye).

    Senaryoyu yanlış anladığınızı düşünüyorum (ve / veya onu yetersiz bir şekilde açıkladım). İlgili hiçbir kimlik bilgisi yok. Bir kullanıcının tarayıcısının sitede yönetici olarak kimliği doğrulanan etkin bir oturumu olup olmadığını algılayabilen bir üçüncü taraf sitedeki javascript ile ilgilidir.
    Üzgünüm - daha dikkatli okumalıydım. Belki de kimlik doğrulama tanımlama bilgilerine güvenli ve HTPONly bayraklarını ayarlamamak iyi bir fikir değil mi? (HTML içeriğini örneğin "geçersiz" için taramak hala görece önemsizdir)
    Aynı kaynak politikasının html içeriğinin taranmasını engelleyeceğini düşünüyorum. Çerezler üzerindeki güvenli vehttpl bayrakları hakkındaki yorumunuzdaki çifte olumsuzu takip ettiğimden emin değilim. Bunu detaylandırır mısın?
    Htponly çerezleri hala Ajax istekleriyle gönderilirken, yukarıdaki örneğiniz, çerezlerde ayarlanmayan güvenli bayrağa ve SSL olmayan bir URL'de doğrulanmış bir durumun tespit edilmesine dayanmaktadır: bir sitenin güvenliğini sağlamak için en iyi uygulama değildir. URL httpS: //www.target.example/admin/utility olsaydı, konu tartışmalı olurdu.
    Soruyu yeni güncelledim - sitedeki çerezler HTPONly ve güvenli ve site ssl ve hsts kullanıyor. "Doğru" davranışın ne olduğunu gerçekten söyleyemem, ancak testlerimde bu saldırının (bilgi ifşa etme) en son Chrome ve Firefox'ta hala çalıştığını söyleyebilirim.
    Lie Ryan
    2013-07-23 21:25:09 UTC
    view on stackexchange narkive permalink

    Bu bir sorunsa, güvenilir bir etki alanından olmayan bir Origin ile gelen istekleri reddederek / sahte istekleri reddederek CORS Erişim Kontrolü başlığını uygulayabilirsiniz.

    CORS -header farkında olan tarayıcılar, çapraz kaynak isteği yaparken bir Kaynak başlığı göndererek sunucuya isteği reddetme / sahte olma şansı verir. Site yöneticileriniz CORS talebinde bulunabilen ancak CORS başlığından haberdar olmayan bir tarayıcı kullanıyorsa, gerçekten daha güvenli bir tarayıcıya geçmeyi düşünmelidir.



    Bu Soru-Cevap, otomatik olarak İngilizce dilinden çevrilmiştir.Orijinal içerik, dağıtıldığı cc by-sa 3.0 lisansı için teşekkür ettiğimiz stackexchange'ta mevcuttur.
    Loading...