Vikipedi

HTTP Katı Taşıma Güvenliği: Revizyonlar arasındaki fark

Etkileşimli olarak geçmişe göz at
[kontrol edilmemiş revizyon][kontrol edilmiş revizyon]
← Önceki sürümle aradaki farkSonraki sürümle aradaki fark →
İçerik silindi İçerik eklendi
GörselVikimetin
wiki içinde bulunan konulara link verildi
Gerekçe: + deneme amaçlı değişiklik
1. satır:
{{teknik|tarih=Mart 2020}}
'''HTTP Katı Taşıma Güvenliği''' ('''HSTS'''), [[İnternet sitesi|web sitelerini]] protokol [[İndirgeme saldırısı|protokol indirgeme]] <ref name="mdn-security">{{Web kaynağı | url = https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Strict-Transport-Security | başlık = Strict-Transport-Security | erişimtarihi = 31 Ocak 2018 | dil = en-US | çalışma = [[MDN Web Docs]] | yayıncı = [[Mozilla]] | arşivurl = https://web.archive.org/web/20200320021752/https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Strict-Transport-Security | arşivtarihi = 20 Mart 2020 | ölüurl = no }}</ref> ve [[:en:Session hijacking|çerez ele geçirme]] saldırılarına karşı korumaya yardımcı olan bir web güvenlik politikası mekanizmasıdır. [[Web sunucusu|Web sunucuları]], kendisine gönderilen isteklerin yalnızca [[HTTPS]] üzerinden olması gerektiğini [[Çerez (İnternet)|web tarayıcılarına]] bu mekanizma ile belirtir. Bu sayede kullanıcı, herhangi bir güvenlik çözümü sunmayan [[HTTP]] yerine [[Transport Layer Security|Taşıma Katmanı Güvenliği]] ([[Transport Layer Security|TLS/SSL]]) sağlayan [[HTTPS]] kullanarak ilgili web sitesine erişim sağlar. HSTS, RFC 6797 ile detaylandırılan bir [[IETF]] [[:en:Internet_Standard|Standards Track]] protokolüdür.
 
Sunucunun HSTS Politikası, yine sunucu tarafından HTTPS yanıt başlığındaki <code>Strict-Transport-Security</code> alanı ile web tarayıcısına iletilir.<ref name="mdn-security"/> 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 ==
HSTS spesifikasyonu, 2 Ekim 2012 tarihinde [[:en:Internet Engineering Steering Group|IESG]] tarafından [[:en:Internet_Standard#Proposed_Standard|Önerilen Standart]] [[Yorumlar İçin Talep|RFC]] olarak yayımlanma onayı aldıktan sonra 19 Kasım 2012 tarihinde RFC 6797 olarak yayımlandı.<ref name="hsts-ps-rfc-approval-iesg-msg">{{Web kaynağı | url = https://www.ietf.org/mail-archive/web/websec/current/msg01401.html | başlık = [websec] Protocol Action: 'HTTP Strict Transport Security (HSTS)' to Proposed Standard (draft-ietf-websec-strict-transport-sec-14.txt) | erişimtarihi = 2 Oct 2012 | tarih = 2 Oct 2012 | arşivurl = https://web.archive.org/web/20170129010418/https://www.ietf.org/mail-archive/web/websec/current/msg01401.html | arşivtarihi = 29 Ocak 2017 | ölüurl = no }}</ref> 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.<ref>{{Web kaynağı | url = //www.ietf.org/mail-archive/web/hasmat/current/msg00025.html | başlık = Re: [HASMAT] "STS" moniker (was: IETF BoF @IETF-78 Maastricht: HASMAT...) | erişimtarihi = 22 Temmuz 2010 | tarih = 30 Haziran 2010 | arşivurl = https://web.archive.org/web/20170202023740/https://www.ietf.org/mail-archive/web/hasmat/current/msg00025.html | arşivtarihi = 2 Şubat 2017 | ölüurl = no }}</ref> Ancak HSTS spesifikasyonunda tanımlanan HTTP yanıt başlığı alanı ise "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ı.<ref name="STS-draft-spec-2">{{Web kaynağı | url = //lists.w3.org/Archives/Public/www-archive/2009Dec/att-0048/draft-hodges-strict-transport-sec-06.plain.html | başlık = Strict Transport Security -06 | erişimtarihi = 23 Aralık 2009 | tarih = 18 Aralık 2009 | arşivurl = https://web.archive.org/web/20170221200316/http://lists.w3.org/Archives/Public/www-archive/2009Dec/att-0048/draft-hodges-strict-transport-sec-06.plain.html | arşivtarihi = 21 Şubat 2017 | ölüurl = no }}</ref>
26. satır:
 
== Uygulanabilirlik ==
HSTS'nin giderebileceği en önemli güvenlik açığı, [[:en:Moxie_Marlinspike|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 [[:en:Moxie Marlinspike#SSL stripping|SSL sıyırma]] [[Man-in-the-middle saldırısı|MITM]] saldırılarıdır.<ref>{{Dergi kaynağı|url=https://blackhat.com/presentations/bh-dc-09/Marlinspike/BlackHat-DC-09-Marlinspike-Defeating-SSL.pdf|başlık=New Tricks For Defeating SSL In Practice|çalışma=}}</ref><ref>{{YouTube|MFol6IMbZ7Y|Defeating SSL Using Sslstrip}}</ref> SSL (ve [[Transport Layer Security|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<ref name="hsts-threats-addressed"/> 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.<ref name="preloading_hsts_chromium">{{Web kaynağı | url = https://www.chromium.org/sts | başlık = Strict Transport Security | erişimtarihi = 22 Temmuz 2010 | tarih = 8 Temmuz 2010 | çalışma = The Chromium Projects | arşivurl = https://web.archive.org/web/20190901122419/http://www.chromium.org/sts | arşivtarihi = 1 Eylül 2019 | ölüurl = no }}</ref><ref name="preloading_hsts_mozillla">{{Web kaynağı | url = https://blog.mozilla.org/security/2012/11/01/preloading-hsts/ | başlık = Preloading HSTS | erişimtarihi = 6 Şubat 2014 | tarih = 1 Kasım 2012 | çalışma = Mozilla Security Blog | arşivurl = https://web.archive.org/web/20200224205730/https://blog.mozilla.org/security/2012/11/01/preloading-hsts/ | arşivtarihi = 24 Şubat 2020 | ölüurl = no }}</ref><ref name="iepreload">{{Web kaynağı | url = http://blogs.msdn.com/b/ie/archive/2015/02/16/http-strict-transport-security-comes-to-internet-explorer.aspx | başlık = HTTP Strict Transport Security comes to Internet Explorer | erişimtarihi = 16 Şubat 2015 | tarih = 16 Şubat 2015 | arşivurl = https://web.archive.org/web/20151115035120/http://blogs.msdn.com/b/ie/archive/2015/02/16/http-strict-transport-security-comes-to-internet-explorer.aspx | arşivtarihi = 15 Kasım 2015 | ölüurl = no }}</ref> 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 [[:en:Firesheep|Firesheep]] gibi yaygın olarak kullanılan araçlar tarafından gerçekleştirilen [[:en:HTTP_cookie#Cookie_theft_and_session_hijacking|çerez tabanlı web sitesi giriş kimlik bilgilerinin çalınmasını]] da önlemeye yardımcı olabilir.<ref>{{Web kaynağı | url = http://identitymeme.org/archives/2010/10/29/firesheep-and-hsts-http-strict-transport-security/ | başlık = Firesheep and HSTS (HTTP Strict Transport Security) | erişimtarihi = 8 Mar 2011 | tarih = 31 Ekim 2010 | arşivurl = https://web.archive.org/web/20160623191633/http://identitymeme.org/archives/2010/10/29/firesheep-and-hsts-http-strict-transport-security/ | arşivtarihi = 23 Haziran 2016 | ölüurl = no }}</ref>
 
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ş [[Network Time Protocol|NTP]] paketleri kullanmak verilebilir.<ref>{{Web kaynağı | url = https://www.blackhat.com/docs/eu-14/materials/eu-14-Selvi-Bypassing-HTTP-Strict-Transport-Security.pdf | başlık = Bypassing HTTP Strict Transport Security | erişimtarihi = 22 Ekim 2014 | tarih = 17 Ekim 2014 | arşivurl = https://web.archive.org/web/20141022112001/https://www.blackhat.com/docs/eu-14/materials/eu-14-Selvi-Bypassing-HTTP-Strict-Transport-Security.pdf | arşivtarihi = 22 Ekim 2014 | ölüurl = no }}</ref>
 
== Sınırlamalar ==
Web sunucusuna gönderilen ilk istek için düz HTTP gibi güvenli olmayan bir protokol veya [[:en:Insecure_channel|güvenli olmayan bir kanal]] üzerinden alınmış [[:en:Uniform_Resource_Identifier|URI]] kullanılıyorsa etkin saldırılara karşı korumasız kalınır.<ref name="hsts-bootstrap-mitm">{{Web kaynağı | url = https://tools.ietf.org/html/rfc6797#section-14.6 | başlık = Section 14.6. Bootstrap MITM Vulnerability | erişimtarihi = 21 Kasım 2012 | tarih = Kasım 2012 | çalışma = RFC 6797 | yayıncı = IETF | arşivurl = https://web.archive.org/web/20200226180912/https://tools.ietf.org/html/rfc6797#section-14.6 | arşivtarihi = 26 Şubat 2020 | ölüurl = no }}</ref> Aynısı, HSTS Politikasında başlıktaki <tt>max-age</tt> 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.<ref name="preloading_hsts_chromium"/><ref name="preloading_hsts_mozillla"/><ref name="iepreload"/><ref>{{Web kaynağı | url = https://cs.chromium.org/chromium/src/net/http/transport_security_state_static.json | başlık = Chromium HSTS Preloaded list | erişimtarihi = 10 Temmuz 2019 | çalışma = cs.chromium.org | arşivurl = https://web.archive.org/web/20200218174855/https://cs.chromium.org/chromium/src/net/http/transport_security_state_static.json | arşivtarihi = 18 Şubat 2020 | ölüurl = no }}</ref> 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.<ref>{{Web kaynağı | url = https://simon.butcher.name/archives/2011/09/11/HTTP-Strict-Transport-Security | başlık = HTTP Strict Transport Security | erişimtarihi = 27 Mart 2012 | tarih = 11 Eylül 2011 | arşivurl = https://web.archive.org/web/20190426183544/https://simon.butcher.name/archives/2011/09/11/HTTP-Strict-Transport-Security | arşivtarihi = 26 Nisan 2019 | ölüurl = no }}</ref>
 
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,<ref name="auto">{{Web kaynağı | url = https://blog.cloudflare.com/performing-preventing-ssl-stripping-a-plain-english-primer/ | başlık = Performing & Preventing SSL Stripping: A Plain-English Primer | tarih = 20 Ekim 2017 | çalışma = Cloudflare Blog | arşivurl = https://web.archive.org/web/20191214182725/https://blog.cloudflare.com/performing-preventing-ssl-stripping-a-plain-english-primer/ | arşivtarihi = 14 Aralık 2019 | erişimtarihi = 17 Mart 2020 | ölüurl = no }}</ref> bunun [[DNS spoofing|DNS Spoofing]] Saldırıları<ref>{{Kitap kaynağı|isbn=978-1-5386-1593-5}}</ref> veya <code>''www.example.org''</code> yerine <code>''www.example.com''</code> 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 [[:en:BEAST_(computer_security)Transport Layer Security|BEAST]] veya [[:en:CRIME_(security_exploit)|CRIME]] saldırıları gibi gelişmiş saldırıları engelleyemez. TLS'e yönelik saldırılar, HSTS politika uygulamasına [[:en:Orthogonality#Computer science|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ı ===
HSTS, tarayıcı "[[:en:Privacy_mode|gizli]]" gizlilik modları da dahil olmak üzere, elde edilen tanımlayıcı verilerle ([[:en:HTTP cookie#Supercookie|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 (2<sup>20</sup>).<ref>{{Web kaynağı | url = https://nakedsecurity.sophos.com/2015/02/02/anatomy-of-a-browser-dilemma-how-hsts-supercookies-make-you-choose-between-privacy-or-security/ | başlık = The HSTS super cookie forcing you to choose: "privacy or security?" - | erişimtarihi = 1 Aralık 2015 | çalışma = sophos.com | arşivurl = https://web.archive.org/web/20200211175612/https://nakedsecurity.sophos.com/2015/02/02/anatomy-of-a-browser-dilemma-how-hsts-supercookies-make-you-choose-between-privacy-or-security/ | arşivtarihi = 11 Şubat 2020 | ölüurl = no }}</ref>
 
== Tarayıcı desteği ==
"https://tr.wikipedia.org/wiki/HTTP_Katı_Taşıma_Güvenliği" sayfasından alınmıştır