İçeriğe atla

HTTP Katı Taşıma Güvenliği

Vikipedi, özgür ansiklopedi

HTTP Katı Taşıma Güvenliği (HSTS), web sitelerini protokol indirgeme[1] ve oturum çalma saldırılarına karşı korumaya yardımcı olan bir web güvenlik politikası mekanizmasıdır. Web sunucuları, kendisine gönderilen isteklerin yalnızca HTTPS üzerinden olması gerektiğini web tarayıcılarına bu mekanizma ile belirtir. Bu sayede kullanıcı, herhangi bir güvenlik çözümü sunmayan HTTP yerine Taşıma Katmanı Güvenliği (TLS/SSL) sağlayan HTTPS kullanarak ilgili web sitesine erişim sağlar. HSTS, RFC 6797 ile detaylandırılan bir IETF Standards Track protokolüdür.

Sunucunun HSTS Politikası, yine sunucu tarafından HTTPS yanıt başlığındaki Strict-Transport-Security alanı ile web tarayıcısına iletilir.[1] HSTS politikası, tarayıcının sunucuya HTTPS kullanarak erişmesi gereken süreyi belirtir. HSTS kullanan web siteleri, HTTP üzerinden gelen bağlantıları reddederek veya kullanıcıları sistematik olarak HTTPS'ye yönlendirerek açık metin HTTP'yi kabul etmez (ancak bunun spesifikasyonda zorunlu olmadığı belirtilmiştir). Bunun sonucunda, TLS/SSL yapamayan web tarayıcısı bu siteye bağlanamayacaktır.

Spesifikasyon geçmişi

[değiştir | kaynağı değiştir]

HSTS spesifikasyonu, 2 Ekim 2012 tarihinde IESG tarafından Önerilen Standart RFC olarak yayımlanma onayı aldıktan sonra 19 Kasım 2012 tarihinde RFC 6797 olarak yayımlandı.[2] Yazarlar, spesifikasyonu ilk olarak 17 Haziran 2010 tarihinde İnternet Taslağı olarak sunmuşlardır. İnternet Taslağına dönüşmesiyle birlikte, spesifikasyon yalnızca HTTP için geçerli olduğundan, adı "Katı Taşıma Güvenliği" (STS) iken "HTTP Katı Taşıma Güvenliği" olarak değiştirilmiştir.[3] Ancak HSTS spesifikasyonunda tanımlanan HTTP yanıt başlığı alanı "Katı Taşıma Güvenliği" olarak kalmaya devam etmiştir.

"Topluluk sürümü" olarak adlandırılan spesifikasyon, topluluk geri bildirimlerini temel alan revizyonlarla daha sonra "STS" adını alarak 18 Aralık 2009 tarihinde yayımlandı.[4]

PayPal'dan Jeff Hodges, Collin Jackson ve Adam Barth tarafından hazırlanan orijinal taslak spesifikasyon, 18 Eylül 2009 tarihinde yayımlandı.[5]

HSTS spesifikasyonu, Jackson ve Barth tarafından "ForceHTTPS: Protecting High-Security Web Sites from Network Attacks" başlıklı makalede anlatılan orijinal çalışmalara dayanmaktadır.[6]

Ayrıca HSTS, Jeff Hodges ve Andy Steingruebl tarafından 2010 yılında hazırlanan "The Need for Coherent Web Security Policy Framework(s)" başlıklı makalede ortaya konulan web güvenliğini geliştirme genel vizyonunun gerçekleşmesi yönünde atılan bir adımdır.[7]

HSTS mekanizmasına genel bakış

[değiştir | kaynağı değiştir]

Bir sunucu, HSTS politikasını HTTPS bağlantısı üzerinden bir başlık sağlayarak uygular (HTTP üzerinden gelen HSTS başlıkları yok sayılır).[1] Örneğin, bir sunucu gelecek bir yıl için alan adına yapılacak isteklerin (max-age -maksimum ömür- saniye cinsinden belirtilir; 31.536.000 ise artık olmayan bir yıla -365 gün- eşittir) yalnızca HTTPS kullanacak şekilde yapılması için şu başlığı gönderebilir: Strict-Transport-Security: max-age=31536000.

Bir web uygulaması kullanıcı aracılarına HSTS politikası kullanacağını bildirdiğinde, uyumlu kullanıcı aracıları aşağıdaki gibi davranır (RFC 6797):[8]

  1. Erişilmek istenen web uygulamasına güvenli olmayan bağlantıları otomatik olarak güvenli bağlantılara dönüştürmelidir (örn. http://example.com/some/page/, sunucuya erişmeden önce https://example.com/some/page/ olarak değiştirilecektir).
  2. Güvenli bağlantı sağlanamıyorsa (örn. sunucunun TLS sertifikası güvenilir değilse), kullanıcı aracısı bağlantıyı sonlandırmalıdır (RFC 6797 Bölüm 8.4, Errors in Secure Transport Establishment) ve kullanıcının web uygulamasına erişmesine izin vermemelidir (Bölüm 12.1, No User Recourse).

HSTS Politikası, web uygulaması kullanıcılarının bazı pasif (gizli dinleme) ve aktif ağ saldırılarına karşı korunmasına yardımcı olur.[9] Web tarayıcısında herhangi bir web uygulaması için HSTS politikası geçerli olduğunda; MITM, bir kullanıcı ve bu web uygulaması sunucusu arasındaki istek ve yanıtları yakalama yeteneğini büyük ölçüde kaybeder.

Uygulanabilirlik

[değiştir | kaynağı değiştir]

HSTS'nin giderebileceği en önemli güvenlik açığı, Moxie Marlinspike tarafından 2009 yılında BlackHat Federal "New Tricks For Defeating SSL In Practice" konuşması sırasında ilk kez tanıtılan SSL sıyırma MITM saldırılarıdır.[10][11] SSL (ve TLS) sıyırma saldırısı, güvenli bir HTTPS bağlantısını şeffaf bir şekilde düz HTTP bağlantısına dönüştürerek çalışır. Kullanıcı bağlantının güvensiz olduğunu görebilir ama en önemlisi bağlantının güvenli olup olmaması gerektiği bilmenin bir yolu yoktur. Birçok web sitesi TLS/SSL kullanmadığından, düz HTTP kullanımının bir saldırıdan kaynaklanıp kaynaklanmadığını veya yalnızca web sitesinin TLS/SSL uygulamadığı için mi olduğunu anlamanın (önceki bilgilere dayanmaksızın) bir yol yoktur. Ayrıca, indirgeme işlemi sırasında kullanıcıya hiçbir uyarı yapılmaz, bu da saldırıyı çok dikkatli olanlar dışındaki herkese karşı oldukça etkili hale getirir. Marlinspike, saldırıyı tamamen otomatik hale getiren bir de araç hazırlamıştır.

HSTS, siteye olan bağlantıların her zaman TLS/SSL kullanması gerektiğini tarayıcıya bildirerek bu sorunu[9] giderir. HSTS başlığı, kullanıcının ilk ziyaretiyse saldırgan tarafından çıkarılabilir. Google Chrome, Mozilla Firefox, Internet Explorer ve Microsoft Edge, HSTS sitelerinin "önyüklü" bir listesini ekleyerek bu sorunu sınırlamaya çalışır.[12][13][14] Ne yazık ki bu çözüm internetteki tüm web sitelerini içerecek şekilde ölçeklendirilemez. Aşağıdaki sınırlamaları inceleyiniz.

HSTS ayrıca Firesheep gibi yaygın olarak kullanılan araçlar tarafından gerçekleştirilen çerez tabanlı web sitesi giriş kimlik bilgilerinin çalınmasını da önlemeye yardımcı olabilir.[15]

HSTS zaman sınırlı olduğu için, mağdurun bilgisayar saatini değiştirmek gibi saldırılara karşı hassastır. Buna örnek olarak düzenlenmiş NTP paketleri kullanmak verilebilir.[16]

Sınırlamalar

[değiştir | kaynağı değiştir]

Web sunucusuna gönderilen ilk istek için düz HTTP gibi güvenli olmayan bir protokol veya güvenli olmayan bir kanal üzerinden alınmış URI kullanılıyorsa etkin saldırılara karşı korumasız kalınır.[17] Aynısı, HSTS Politikasında başlıktaki max-age değeriyle belirtilen geçerlilik süresinden sonraki ilk istek için de geçerlidir (siteler, kullanıcı etkinliği ve davranışına bağlı olarak bu süreyi birkaç gün veya birkaç ay olarak ayarlamalıdır). Google Chrome, Mozilla Firefox ve Internet Explorer/Microsoft Edge, HSTS'yi desteklediği bilinen siteleri içeren bir liste olan "önyüklü HSTS listesi" kullanarak bu sınırlamayı giderir.[12][13][14][18] Bu liste, listedeki sitelere yapılacak ilk istek için HTTPS kullanılması amacıyla tarayıcıyla birlikte dağıtılır. Daha önce de belirtildiği gibi, bu önyüklü listeler tüm Web'i kapsayacak şekilde ölçeklendirilemez. Potansiyel çözüm, web sunucusunun HSTS politikasına DNS kayıtları üzerinden erişerek ve bu DNS kayıtlarına erişirken de güvenliği sağlamak adına DNSSEC kullanarak elde edilebilir.[19]

Junade Ali, HSTS'nin sahte alan kullanımlarına karşı etkisiz olduğuna dikkat çekmiş; DNS tabanlı saldırılar kullanarak, MITM gerçekleştiren saldırganın önyüklü HSTS listesinde olmayan sahte bir alandan trafik sunmasının mümkün olduğunu,[20] bunun DNS Spoofing Saldırıları[21] veya www.example.org yerine www.example.com gibi gerçek alan adını andıran yanıltıcı basit bir alan adı ile de gerçekleşebileceğini dile getirmiştir.

"Önyüklü HSTS listesi" ile bile HSTS, Juliano Rizzo ve Thai Duong'un getirdiği TLS'e yönelik gerçekleşen BEAST veya CRIME saldırıları gibi gelişmiş saldırıları engelleyemez. TLS'e yönelik saldırılar, HSTS politika uygulamasına diktir. Sunucudaki saldırılara karşı da koruma sağlayamaz - eğer birisi sızacak olursa, TLS üzerinden herhangi bir içeriğe erişebilir hale gelecektir.

HSTS güvenlik hususlarının detaylı incelemeleri için RFC 6797'ye bakınız.

Gizlilik sorunları

[değiştir | kaynağı değiştir]

HSTS, tarayıcı "gizli" gizlilik modları da dahil olmak üzere, elde edilen tanımlayıcı verilerle (süperçerezler) ziyaret eden tarayıcıları neredeyse kalıcı bir şekilde etiketlemek için kullanılabilir. Belirlenen alanlara birden çok HTTP isteği yapan bir web sayfası oluşturarak, örneğin yirmi farklı alan adına erişim için yirmi tarayıcı isteği, her bir isteğin HTTP ve HTTPS üzerinden gelmesine göre oluşturulan ikili bit'lerin karşılaştırılmasıyla bir milyondan fazla ziyaretçi ayırt edilebilir (220).[22]

Tarayıcı desteği

[değiştir | kaynağı değiştir]
Settings page for HTTPS Strict Transport Security within Chromium 45, showing the status of the security policy for the domain "en.wikipedia.org".
Chromium 45 içindeki HTTPS Sıkı Aktarım Güvenliği ayarlar sayfası, "en.wikipedia.org" etki alanı için güvenlik ilkesinin durumunu gösterir.

Kurulum sırasında dikkat edilmesi gerekenler

[değiştir | kaynağı değiştir]

Kuruluma da bağlı olarak aşağıda verilenleri takip ederek belirli tehditler önlenebilir (örn. çerez enjeksiyon saldırıları).

  • HSTS ana bilgisayarları, üst düzey etki alanı adlarında HSTS ilkesini bildirmelidir. Örneğin, https://sub.example.com için olan HSTS ana bilgisayarı https://example.com için de HSTS başlığıyla yanıtı vermelidir. Başlık, Strict-Transport-Security: max-age=16070400; includeSubDomainsşeklinde olmalı yani mutlaka includeSubDomains yönergesini de içermelidir.[30]
  • HSTS dağıtımına ek olarak, https://www.example.com için olan ana bilgisayar, üst alan için de HSTS'nin ayarlandığından ve kullanıcıyı MITM tarafından üst etki alanına referans enjekte edilerek (veya http://nonexistentpeer.example.com) gerçekleştirilecek potansiyel çerez enjeksiyon saldırısına karşı koruduğundan emin olmak için https://example.com adresindeki bir kaynağa yönelik bir istek içermelidir.[31]

Kaynakça

[değiştir | kaynağı değiştir]
  1. ^ a b c d "Strict-Transport-Security". MDN Web Docs (İngilizce). Mozilla. 20 Mart 2020 tarihinde kaynağından arşivlendi. Erişim tarihi: 31 Ocak 2018. 
  2. ^ "[websec] Protocol Action: 'HTTP Strict Transport Security (HSTS)' to Proposed Standard (draft-ietf-websec-strict-transport-sec-14.txt)". 2 Ekim 2012. 29 Ocak 2017 tarihinde kaynağından arşivlendi. Erişim tarihi: 2 Ekim 2012. 
  3. ^ "Re: [HASMAT] "STS" moniker (was: IETF BoF @IETF-78 Maastricht: HASMAT...)". 30 Haziran 2010. 2 Şubat 2017 tarihinde kaynağından arşivlendi. Erişim tarihi: 22 Temmuz 2010. 
  4. ^ "Strict Transport Security -06". 18 Aralık 2009. 21 Şubat 2017 tarihinde kaynağından arşivlendi. Erişim tarihi: 23 Aralık 2009. 
  5. ^ "Strict Transport Security -05". 18 Eylül 2009. 24 Şubat 2020 tarihinde kaynağından arşivlendi. Erişim tarihi: 19 Kasım 2009. 
  6. ^ "ForceHTTPS: Protecting High-Security Web Site from Network Attacks". Nisan 2008. 28 Şubat 2020 tarihinde kaynağından arşivlendi. Erişim tarihi: 19 Kasım 2009. 
  7. ^ "The Need for Coherent Web Security Policy Framework(s)". 29 Ekim 2010. 14 Ağustos 2017 tarihinde kaynağından arşivlendi. Erişim tarihi: 21 Kasım 2012. 
  8. ^ "Section 5. HSTS Mechanism Overview". RFC 6797. IETF. Kasım 2012. 26 Şubat 2020 tarihinde kaynağından arşivlendi. Erişim tarihi: 21 Kasım 2012. 
  9. ^ a b "2.3. Threat Model". RFC 6797. IETF. Kasım 2012. 26 Şubat 2020 tarihinde kaynağından arşivlendi. Erişim tarihi: 21 Kasım 2012. 
  10. ^ "New Tricks For Defeating SSL In Practice" (PDF). 30 Aralık 2014 tarihinde kaynağından (PDF) arşivlendi. Erişim tarihi: 17 Mart 2020. 
  11. ^ YouTube'da Defeating SSL Using Sslstrip
  12. ^ a b "Strict Transport Security". The Chromium Projects. 8 Temmuz 2010. 1 Eylül 2019 tarihinde kaynağından arşivlendi. Erişim tarihi: 22 Temmuz 2010. 
  13. ^ a b c "Preloading HSTS". Mozilla Security Blog. 1 Kasım 2012. 24 Şubat 2020 tarihinde kaynağından arşivlendi. Erişim tarihi: 6 Şubat 2014. 
  14. ^ a b "HTTP Strict Transport Security comes to Internet Explorer". 16 Şubat 2015. 15 Kasım 2015 tarihinde kaynağından arşivlendi. Erişim tarihi: 16 Şubat 2015. 
  15. ^ "Firesheep and HSTS (HTTP Strict Transport Security)". 31 Ekim 2010. 23 Haziran 2016 tarihinde kaynağından arşivlendi. Erişim tarihi: 8 Mart 2011. 
  16. ^ "Bypassing HTTP Strict Transport Security" (PDF). 17 Ekim 2014. 22 Ekim 2014 tarihinde kaynağından (PDF) arşivlendi. Erişim tarihi: 22 Ekim 2014. 
  17. ^ "Section 14.6. Bootstrap MITM Vulnerability". RFC 6797. IETF. Kasım 2012. 26 Şubat 2020 tarihinde kaynağından arşivlendi. Erişim tarihi: 21 Kasım 2012. 
  18. ^ "Chromium HSTS Preloaded list". cs.chromium.org. 18 Şubat 2020 tarihinde kaynağından arşivlendi. Erişim tarihi: 10 Temmuz 2019. 
  19. ^ "HTTP Strict Transport Security". 11 Eylül 2011. 26 Nisan 2019 tarihinde kaynağından arşivlendi. Erişim tarihi: 27 Mart 2012. 
  20. ^ "Performing & Preventing SSL Stripping: A Plain-English Primer". Cloudflare Blog. 20 Ekim 2017. 14 Aralık 2019 tarihinde kaynağından arşivlendi. Erişim tarihi: 17 Mart 2020. 
  21. ^ 2017 SSDSE (İngilizce). 2017. ISBN 978-1-5386-1593-5. 
  22. ^ "The HSTS super cookie forcing you to choose: "privacy or security?" -". sophos.com. 11 Şubat 2020 tarihinde kaynağından arşivlendi. Erişim tarihi: 1 Aralık 2015. 
  23. ^ "Strict Transport Security - The Chromium Projects". 17 Kasım 2010. 20 Mart 2020 tarihinde kaynağından arşivlendi. Erişim tarihi: 17 Kasım 2010. 
  24. ^ "fyi: Strict Transport Security specification". 18 Eylül 2009. 29 Şubat 2020 tarihinde kaynağından arşivlendi. Erişim tarihi: 19 Kasım 2009. 
  25. ^ "Web specifications support in Opera Presto 2.10". 23 Nisan 2012. 20 Haziran 2018 tarihinde kaynağından arşivlendi. Erişim tarihi: 8 Mayıs 2012. 
  26. ^ "Confirmed. See ~/Library/Cookies/HSTS.plist. Includes Chromium preloads as of some date and processes HSTS headers". on Twitter. 9 Mayıs 2019 tarihinde kaynağından arşivlendi. Erişim tarihi: 20 Aralık 2013. 
  27. ^ "HTTP Strict Transport Security comes to Internet Explorer 11 on Windows 8.1 and Windows 7". windows.com. 27 Kasım 2019 tarihinde kaynağından arşivlendi. Erişim tarihi: 12 Haziran 2015. 
  28. ^ "Internet Explorer Web Platform Status and Roadmap". 29 Haziran 2015 tarihinde kaynağından arşivlendi. Erişim tarihi: 14 Nisan 2014. 
  29. ^ "Project Spartan and the Windows 10 January Preview Build - IEBlog". 29 Kasım 2019 tarihinde kaynağından arşivlendi. Erişim tarihi: 23 Ocak 2015. 
  30. ^ "HTTP Strict Transport Security (HSTS) 6.1.2". ietf.org. 22 Temmuz 2019 tarihinde kaynağından arşivlendi. Erişim tarihi: 11 Kasım 2016. 
  31. ^ "RFC 6797 - HTTP Strict Transport Security (HSTS)". IETF Tools. 28 Mayıs 2019 tarihinde kaynağından arşivlendi. Erişim tarihi: 28 Mayıs 2019. 

Dış bağlantılar

[değiştir | kaynağı değiştir]
"https://tr.wikipedia.org/w/index.php?title=HTTP_Katı_Taşıma_Güvenliği&oldid=33507730" sayfasından alınmıştır