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

HTTP Katı Taşıma Güvenliği (HSTS), web sitelerini protokol indirgeme 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. 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.

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ı. 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. 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ı.

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.

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). Ö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.

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. 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.

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. 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 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. 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.

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.

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. 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. 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.

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, bunun DNS Spoofing Saldırıları 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, 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).

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.

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.