"Google.com" HSTS korumalı değil mi?

Oct 07 2020

Konu:

Çoğu zaman insanlar google.com, http://veya https://öneklerini eklemeden tarayıcının adres çubuğuna doğrudan girer .

Chrome DevTools'u yeni bir gizli oturumda kullanarak aşağıdaki deneyi çalıştırdım:

ADIMLAR:
-----------------
Doğrudan şuraya "google.com" (veya eşdeğer olarak "http://google.com") girin. 
tarayıcının adres çubuğu.

 1. Talep: http://google.com;
    Yanıt: Durum Kodu: 301 Kalıcı Olarak Taşındı
              Yer: http://www.google.com/
              Önbellek Kontrolü: genel, maks-yaş = 2592000

 2. Talep: http://www.google.com;
    Yanıt: Durum Kodu: 302 Bulundu
              Konum: https://www.google.com/?gws_rd=ssl

 3. Talep: https://www.google.com/?gws_rd=ssl;
    Yanıt: Durum Kodu: 200
              sıkı taşıma güvenliği: maks-yaş = 31536000

NOTLAR: 
-----------------
* Aynı sonuçları almak için yeni bir gizli oturum başlatın (tüm gizli modları kapatın 
  pencereler ve yenisini açın). Zaten gizli bir pencereniz açıksa
  aynı sonuçları almayabilir. "Önbelleği devre dışı bırak" seçeneğinin işaretlenmesi de yardımcı olmaz.

* Denemeyi aynı gizli oturumdan tekrarlarsanız, 
  ilk seferden itibaren aşağıdaki farklılıklar:

    * Talep 1: "Önbelleği devre dışı bırak" işaretli değilse (bu, tarayıcının 
                 normal kullanım sırasındaki davranış), yanıt önbellekten olacaktır 
                 "Cache-Control: public, max-age = 2592000" yanıtı nedeniyle 
                 üstbilgi ilk kez döndü. Bu, http'nin
                 istek gönderilmedi (yine de 301 göstermesine rağmen 
                 yanıt) bu muhtemelen iyi bir şeydir.

    * Talep 2: Yanıt, 302 yerine 307 olacaktır. Bunun nedeni 
                 "sıkı-taşıma-güvenliği: maks-yaş = 31536000", 
                 üçüncü istek ilk kez. Bu ne olursa olsun durumdur
                 "önbelleği devre dışı bırak" seçeneğinin işaretli olup olmadığı.

* Tarayıcı bir alan adının HSTS korumalı olduğunun farkına vardığında ( 
  HSTS önyüklemesi veya STS yanıt başlığı) tarayıcı "dahili olarak" yeniden yönlendirecektir
  o alan için https'ye yönelik tüm http istekleri. Bu yönlendirmeler şurada görüntülenir:
  ağ sekmesi "Durum Kodu: 307 Dahili Yönlendirme" (bir tür 
  yanıltıcı çünkü yanıt bir sunucudan geliyor gibi görünüyor 
  gerçeklik hepsi tarayıcı içinde oluyor. Olmadığına dikkat edin
  Bu istekler için "Genel" bölümündeki "Uzak Adres"

* Bir alanın HSTS korumalı olup olmadığını kontrol etmenin başka (belki daha kolay) bir yolu, 
  https://hstspreload.org/ adresinden alan adını giriyor ancak bazı uyarılar var! 
  https://hstspreload.org/, "www.google.com" için aşağıdakileri bildirir:
     - "Yanıt hatası: Yanıtta HSTS başlığı yok."
     - "` http: // www.google.com`, `https: // www.google.com` 'a yönlendirmiyor"
  Bu bulguların hiçbiri ağda gözlemlenenlerle tutarlı değil 
  yukarıdaki deneyde sekmesi! Hstspreload posta listesine e-posta gönderdim ve
  şu ilginç yanıtı aldı: "için sunucu 
  http://www.google.com http'yi her zaman https'ye yönlendirmez, bu nedenle 
  hata belirir. Örneğin curl kullanırsam, yönlendirmeyi alamıyorum. "
-----------------

Gizlilik / güvenlik endişeleri:

  • İçin ilk istek google.comüzerine yapılır httpberi google.comHSTS önyükleme listesine dahil değildir. Bu istek, MITM saldırılarına karşı savunmasızdır.

  • Tarayıcı hiçbir noktada yeniden yönlendirilmez https://google.com, bu nedenle STS başlığı bu etki alanı için asla ayarlanmamıştır. Bu, gelecekteki taleplerin bile google.comHSTS korumalı olmayacağı ve bu nedenle MITM saldırılarına açık olabileceği anlamına gelir !

    İlk 301 yönlendirmesine dahil edilen cache-control max-age = 2592000 (30 gün) yanıt başlığının, gelecekteki isteklerin http://google.com"dahili olarak" işlenmesine neden olduğu için HSTS'nin sağladığına benzer bir koruma düzeyi sağladığını belirtmek gerekir önbellek tarafından (ve daha da önemlisi HSTS korumalı "www.google.com" alanına yönlendirilir). Öte yandan, önbellek denetimi max-age 30 gün sonra sona erecek şekilde ayarlanmıştır (HSTS'nin max-agegenellikle ayarlandığından çok daha kısa ) ve en önemlisi, HSTS'nin etkin olduğu bir etki alanına yapılan her talepte yenilenen HSTS'nin aksine , önbellek denetimi , güvenli olmayan yeni bir istek yapılana kadar yenilenmez ! Bu, taleplerinizin her 30 günde bir kadar sık ​​bir şekilde ele geçirilebileceği anlamına gelir .max-agehttpsmax agehttpgoogle.com

  • İsteği www.google.comhttp üzerinden yapılır ve MITM saldırılarına karşı savunmasızdır. En azından bu durumda yanıt, https://www.google.comSTS başlığını içeren bir 302 yeniden yönlendirmesidir . Bu, daha sonraki tüm taleplerin http://www.google.comtarayıcı tarafından "dahili olarak" https'ye yönlendirileceği anlamına gelir, yukarıda belirtildiği gibi, HSTS max-ageher istekte yenilenir. Tarayıcınız https://www.google.comyılda en az bir kez istekte bulunduğu sürece (STS'nin max-agesona ermesinin ayarlandığı şey budur), o alana gönderilen tüm istekler HSTS korumalı olacaktır.

TL; DR - "google.com" HSTS korumalı değildir ve istekler potansiyel olarak her 30 günde bir (veya önbellek temizlenirse veya gizli mod kullanılırsa daha sık) MITM saldırılarına maruz kalabilir gibi görünüyor.

Bu, aşağıdaki nedenlerden ötürü göründüğü kadar kötü olmayabilir:

  • Tüm önemli çerezler için .google.comve www.google.comkesinlikle securebayrak ayarlıdır.
  • google.comGörünüşe göre yeniden yönlendirmeden başka bir şey yapmıyor, www.google.combu nedenle herhangi bir istek google.comgerçekçi olarak yalnızca kök yoluna olacaktır (Bu nedenle URL'nin kendisi bir kulak misafiri için ilginç olmayacaktır).
  • Daha hassas veriler gönderen / alan Google alt alanları (örn. Gmail.com, accounts.google.com ...) HSTS önyükleme listesindedir. Dolayısıyla, bir saldırgan sslsplit gibi bir şey ayarlasa ve bir kullanıcı saldırganın kontrolünde olsa bile http://www.google.com(kullanıcının eksik asma kilit simgesini fark etmemesini gerektirdiğinden bu zaten çekilmesi yeterince zordur), HSTS'nin önceden yüklenmiş etki alanları korunmaya devam edecektir. . Bu nedenle bir saldırganın, bir kullanıcının bu alt etki alanlarından herhangi birine gitmesini engellemesi gerekir.

Sorular

  1. Google'ın HSTS'yi aşağıdakiler için etkinleştirmemesinin nedenleri neler olabilir? google.com
  2. Google'ın yalnızca STS üstbilgisini etkinleştirip www.google.combu alanı HSTS önyükleme listesine eklememesinin nedenleri neler olabilir ?

Yanıtlar

28 EsaJokinen Oct 07 2020 at 13:35

Mevcut durum

Ekim 2020 itibariyle, Google'ın HSTS'nin açık olmadığı google.com, yalnızca açık www.google.comolduğu ve önce wwwve sonra yeniden yönlendirme yaptığı doğrudur https://. Açık bir HSTS başlığı olsa bile google.com, tarayıcı onu göremez ve önbelleğe alamaz. Yalnızca www.google.comHSTS tarafından korunmaktadır.

En iyi uygulamalar

Ayrıca, örneğin Federal CIO Konseyi tarafından en iyi uygulamalar olarak tavsiye edilmektedir :

En güçlü ve önerilen biçiminde, HSTS politikası tüm alt etki alanlarını içerir ve tarayıcılara "önceden yüklenmeye" istekli olduğunu gösterir:

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload 

Bu formu kullanırken şunları aklınızda bulundurun:

  • Politika https://domain.gov, yerine uygulanmalıdır https://www.domain.gov.
  • Ana alanla ilişkili tüm alt alanlar HTTPS'yi desteklemelidir. (Her birinin kendi HSTS politikasına sahip olması gerekmez.)

OWASP HTTP Strict Transport Security Hile Sayfası ekler (ayrıca RFC 6797, 14.4'te belirtilmiştir ):

Çerezler alt etki alanlarından yönetilebilir, bu nedenle includeSubDomainsseçeneğin atlanması, HSTS'nin bir alt etki alanı için geçerli bir sertifika gerektirerek önleyeceği çok çeşitli çerezle ilgili saldırılara izin verir. Güvenli bayrağın tüm tanımlama bilgilerinde ayarlandığından emin olmak aynı saldırıların hepsini olmasa da bazılarını önleyecektir.

Bu, yalnızca önce HTTPS'ye yeniden yönlendirilerek elde edilebilir.

Neden?

Bununla birlikte, yalnızca neyin daha iyi olacağını söyleyebiliriz, ancak bazılarının neden bu yönergelere uymadığını yanıtlayamayız. Bunu neden bu şekilde uyguladıklarını yalnızca Google bilir. gmail.comHalihazırda HSTS önyükleme listesinde bulunanlar için zaten yaptıkları gibi bilgi ve yetenek eksikliği değildir .

Google Güvenlik Blogu'ndan Jay Brown'un HSTS'yi www.google.com'a Getirmesini okuyarak cevabınıza en yakın olanı bulabilirsiniz . Temmuz 2016 tarihli bu makaleden , devasa sitenin karmaşıklığından ve eski hizmetlerle geriye dönük uyumluluğundan dolayı bunun kasıtlı olduğunu öğrenebiliriz .

Normalde, HSTS'nin uygulanması nispeten basit bir süreçtir. Bununla birlikte, Google'ın kendine özgü karmaşıklıkları nedeniyle, diğer alanların çoğunun yapmak zorunda kalmayacağı bazı ekstra hazırlık çalışmaları yapmamız gerekiyordu. Örneğin, karma içeriği, bozuk HREF'leri, HTTP'ye yönlendirmeleri ve eski hizmetlerin güncellenmesi gibi kullanıcılar için çekirdek alanımıza erişmeye çalışırken sorunlara neden olabilecek diğer sorunları ele almamız gerekiyordu.

Bu süreç, tuzakları olmadan değildi. Belki de en akılda kalıcı olarak, geçen yıl Noel'den hemen önce Google'ın Santa Tracker'ı yanlışlıkla bozduk (endişelenmeyin - Noel Baba ve ren geyiği yolculuklarını yapmadan önce onu düzelttik).