"Google.com" HSTS korumalı değil mi?
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ırhttpberigoogle.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 bilegoogle.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 denetimimax-age30 gün sonra sona erecek şekilde ayarlanmıştır (HSTS'ninmax-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 taleplerinhttp://www.google.comtarayıcı tarafından "dahili olarak" https'ye yönlendirileceği anlamına gelir, yukarıda belirtildiği gibi, HSTSmax-ageher istekte yenilenir. Tarayıcınızhttps://www.google.comyılda en az bir kez istekte bulunduğu sürece (STS'ninmax-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.comvewww.google.comkesinliklesecurebayrak 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 istekgoogle.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
- Google'ın HSTS'yi aşağıdakiler için etkinleştirmemesinin nedenleri neler olabilir?
google.com - Google'ın yalnızca STS üstbilgisini etkinleştirip
www.google.combu alanı HSTS önyükleme listesine eklememesinin nedenleri neler olabilir ?
Yanıtlar
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; preloadBu formu kullanırken şunları aklınızda bulundurun:
- Politika
https://domain.gov, yerine uygulanmalıdırhttps://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).