Türkiye'de HTTP Güvenlik Headerlarının Kullanımı

Headerlar, HTTP'nin hem istek hem de yanıt mesajlarında yer alan ve mesajın meta bilgilerini taşıyan bölümlerdir.

Bu meta bilgileri, istekler için, talep edilen mesajın dili, tipi, browserın sakladığı yetki bilgileri, önbellekte tutulan içeriğe ait bilgiler olabileceği gibi; yanıt yani response mesajlarında ise, içeriğin boyutu ve tipi, bellekte saklanma tercihleri, sunucu bilgileri, tarih ve saati, istemci tarafında set edilecek credentials gibi, bir takım bilgilerdir.

Yazımızın konusu ise, Dr. Emin İslam Tatlı ve Koray Emre Kısa tarafından yapılan Türkiye Güvenlik Headarları Araştırması¹. Bu araştırmadan hareketle hem güvenlik header'larına değinecek, hem de araştırma ile birlikte gündeme gelen güvenlik headerlarının kullanım oranlarını inceleyeceğiz.

Araştırma, Alexa Turkey 500 listesindeki siteleri kapsıyor. Kullanılan veriler 370 siteye ait. Listedeki 130 site ise global firmaların Türkiye versiyonları oldukları için (örneğin google.com) araştırmaya dahil edilmemiş. Araştırmaya konu olan sitelere herhangi bir yetki ile erişilmediği ve ayrıca sitelerin subdomainlerinin bu araştırmaya dahil edilmediği belirtiliyor.

Araştırmada incelenen siteler; Finans, Hükümet, Basın, Ticaret gibi 18 ayrı kategoriye ait. Araştırma sonunda kategorik olarak bu sitelerin güvenlik farkındalığı puanlanlarına erişebilmek mümkün.

Aktif Güvenlik Headerları²

Güvenlik headerlarını iki ayrı kategoride incelemek mümkün. Bunlardan ilki Aktif Güvenlik headerları, diğeri ise Pasif güvenlik headerlarıdır.

Aktif güvenlik headerları, İstemci tarafında (browser) doğrudan güvenlik mekanizmalarını devreye alan headerlardır.

X-Frame-Options

2009 yılında Clickjacking başta olmak üzere UI Redressing saldırılarına karşı önerilen ve bugün tüm major browserlar tarafından desteklenen bir güvenlik headerıdır.

UI Redressing saldırıları basit olarak, hedef sitenin bir iframe içerisinde yüklenmesi esasına dayanıyor. Saldırıda amaçlanan, hedef sitedeki bilgilerin, kullanıcı kandırılarak, saldırgan sitesindeki arayüzlere girilmesini sağlamak ya da kullanıcının, MASUM görünümlü saldırgan site üzerinde gerçekleştirdiğine inandığı/düşündüğü hareketleri, hedef siteye yönlendirmek ve kullanıcı yetkileriyle işlem gerçekleştirmektir.

Clickjacking saldırı yönteminde saldırgan hedef siteyi opacity değeri düşük bir iframe içerisinde yükleyerek, ziyaretçinin transparan hale gelen hedef sitenin altında gördüğü masum sitede işlem yapıyormuş hissine kapılmasını sağlar. Böylece saldırgan, kurbanı zararsız görünen bağlantılara tıklamaya ikna ederken, hedef sitedeki bir dizi aksiyonun tetiklenmesine yol açar.

Resim: https://www.tinfoilsecurity.com/blog/what-is-clickjacking

Clickjacking, kullanıcılarımızı, yani zincirin zayıf halkasını hedef alan bir saldırıdır. Bu saldırıdan korunmak için Frame Busting başta olmak üzere, pek çok yöntem denenmiştir. Bunlardan en geçerli olan X-Frame-Options yöntemi ise 2009 yılında Microsoft tarafından IE browserlarına eklenmiştir.

Ziyaretçilerimizi Clickjacking vb. saldırılardan korunmanın en temel yolu, sayfalarımızın iframe, frame gibi yollarla embed edilmesini engellemek ya da buna bir kısıtlama getirmektir. Bunu yapmak için güvenlik headerlarından biri olan X-Frame-Options'ı kullanabiliriz.

X-Frame-Options değerinin, alabileceği üç farklı değer vardır.

X-Frame-Options: DENY | SAMEORIGIN | ALLOW-FROM URL

DENY : Sitenin hiçbir şekilde iframe ya da benzeri bir yol ile embed edilmesine izin vermez.

SAMEORIGIN : Sitenin yalnızca şema + hostname + port olarak eşleştiği bir site tarafından embed edilmesine izin verir. Örneğin, https://www.example.com yalnızca https://www.example.com üzerinden yüklenebilir.

ALLOW-FROM URL : Yalnızca belirtilen URL tarafından sitenin embed edilmesine izin verir.

X-Frame-Options'da iki önemli noktayı hatırlatmakta fayda var. Chromium tabanlı browserlarda X-Frame-Options kısmi olarak desteklenmektedir. Örneğin ALLOW-FROM özelliği kullanılamamaktadır.

ALLOW-FROM URL Parametresi ile yalnızca bir domain'i whitelist edip, sitemizi iframe içerisinde yüklemesine izin verebiliriz.

Birkaç önemli noktanın altını çizmekte fayda var.

X-Frame-Options headerı sunuculardaki bütün sayfaların HTTP yanıtlarında yer almalıdır.

X-Frame-Options yerine, Content-Security-Policy frame-ancestors direktifi kullanılabilir.

Content-Security-Policy: frame-ancestors 'none'; // Hiçbir URL sayfayı iframe içerisinde yükleyemez.

Content-Security-Policy: frame-ancestors 'self'; // SAMEORIGIN parametresindeki işlevin aynısı.

X-Frame-Options ile birlikte yalnızca bir URL'i whitelist'e alırken, CSP frame-ancestors ile birden fazla domain'i, güvenilir URL'ler listesinde belirtip, sayfalarımızı iframe olarak yüklemelerine izin verebiliriz.

X-Frame-Options Durum Değerlendirmesi

X-Frame-Options güvenlik headerı, incelenen 370 sitenin yalnızca 40'ında, yani yüzde 12'sinde kullanılmıştır.

Finans, gibi kritik bir sektörde, Alexa Top 500 Turkey listesinde yer alan 14 site varken, bunların yalnızca 4'ünde X-Frame-Options'ın kullanılmış olması, bir hayli dikkat çekici.

Sektörlere göre X-Frame-Options kullanımını şöyle özetleyebiliriz:

Sektör Adı	Alexa 500 Turkey'deki Site Sayısı	X-Frame-Options Kullanımı
Internet	71	17
Basın	114	1
Ticaret	29	4
Video, Film	37	1
Oyun, Bahis	19	8
Hükümet	22	3
Finans	14	2
Telekomünikasyon	9	1
Oyun & Eğlence	12	0
Kaynaklar	13	0
Forum	6	1
Lojistik	4	1
İş / İlan	5	1
Perakende	4	1
Hizmet	3	1
Emlak	2	0
Havacılık	2	0
Diğer	3	0

X-XSS-PROTECTION

Tarayıcıda Reflected XSS güvenlik filtresini etkinleştirir. Reflected XSS, kullanıcıdan alınan girdinin sayfa context'inde bir script kodu olarak yorumlanması ile ortaya çıkan zafiyet türüdür.Bir script kodu gibi yorumlanan bu zararlı girdi vasıtası ile, kullanıcının oturumunun ele geçirilmesinden, klavye ve fare hareketlerinin izlenmesi başta olmak üzere, bir dizi zararlı işlem yapılabilir.

Örneğin;

<p>Hosgeldin <?php echo $_GET["isim"];?></p>

http://www.example.com?isim=<script>alert(1);</script>

X-XSS-Protection Çeşitli parametre varyasyonları ile davranış değiştirebilmek mümkündür.

X-XSS-Protection: 1;

Tarayıcıda XSS güvenlik filtresini devreye alarak, olası bir XSS payloadunun sayfada çalışmasını engeller.

X-XSS-Protection: 1; mode=block

Tarayıcıda XSS güvenlik filtresini devreye alır. Olası bir XSS payloadunun sayfada çalışmasını tüm sayfanın gösterilmesini engelleyerek bloke eder. XSS payloadu gönderildiğinde, ziyaretçi browserda beyaz bir ekran ile karşılaşır.

X-XSS-Protection: 1; mode=block; report=https://domain.tld/folder/file.ext

Tarayıcıda XSS güvenlik filtresini devreye alır. Olası bir XSS payloadunun sayfada çalışmasını tüm sayfanın gösterilmesini engelleyerek bloke eder. XSS payloadu gönderildiğinde, ziyaretçi browserda beyaz bir ekran ile karşılaşır.

Chromium tabanlı browserlarda, CSP violation report özelliğinin implementasyonu kullanılarak, report parametresi ile belirtilen URL'e XSS injeksiyon girişimi raporlanır.

X-XSS-Protection Durum Değerlendirmesi

Modern tarayıcılarda XSS filtrelerinin varsayılan olarak etkin halde gelmesi, sadece 21 sitenin yani yüzde 6'lık gibi küçük bir dilimin, hususen X-XSS-Protection kullanmasının sebeplerini açıklar nitelikte.

Bu headerı kullanan sitelerin yüzde 90'ında, 1;mode=block; parametresi ile kullanılan header; yalnızca bir sitede, mode=0; olarak yani XSS filtresi hususen devre dışı bırakılmak suretiyle kullanılmıştır.

X-Content-Type-Options

Mime Type Sniffing, sunulan içeriğin tipi belirtilmediği durumlarda, browserların sayfa görüntülenmesinde en doğru yolu bulabilmek için, içeriği değerlendirmesi işlemidir.

Kısaca sunulan belgede Content-Type headerı ile içeriğin tipi belirtilmediği takdirde, browser içeriği "koklayarak", kaynağı en doğru biçimde görüntülemeye çalışır.

Özellikle de upload fonksiyonlarıyla beraber, sniffing işlemi bir takım tehlikeler arz edebilir.

Örneğin, kullanıcının zararsız addedilen bir text dosyası upload ettiğini varsayalım. Eğer bu text dosyası HTML ve script tagları, Javascript kodları içeriyorsa ve biz bu yüklenen dosyayı tekrar kullanıcıya sunarken bir Content-Type belirtmiyorsak, browser bu sayfanın içeriğini koklayarak bunun pek tabii bir text/html tipinde bir dosya olduğuna karar verecektir ve bu sayfadaki kodlar da çalışacaktır.

Yine sitemize upload edilen resim dosyaları dahi, kullanıcıya geri sunulurken, Content-Type headerı içermelidir. Yoksa EXIF data olarak tabir edilen, imajın meta datalarını içeren kısma script kodları enjekte edilerek, zararlı kodlar çalıştırılabilir.

İşte bu gibi durumlarda, browserın sayfa içeriğini koklayarak, inceleyerek servis edeceği tipe karar vermesinin önüne geçmek için X-Content-Type-Options headerı kullanılmaktadır.

X-Content-Type-Options: nosniff

X-Content-Type-Options Durum Değerlendirmesi

X-Content-Type-Options headerı, incelenen sitelerin sadece yüzde 7'sinde yani 24'ünde kullanılmış durumda.

Araştırmada Video-Film, İnsan Kaynakları gibi kullanıcı kaynaklı dataların servis edildiği sitelerde maalesef X-Content-Type-Options kullanımını göremiyoruz.

Forum gibi yine kullanıcı kaynaklı dataların paylaşıldığı sitelerde ise, kullanım oranı oldukça düşük. Alexa Top 500 Turkey siteleri içerisindeki 6 forum sitesinden yalnızca 1'i X-Content-Type-Options 'ı kullanıyor.

X-Download-Options

Internet Explorer 8 ve üzeri sürümlerde geçerli olan bu özellik sayesinde, talep edilen içeriğin browserda görüntülenmek yerine download edilmesi sağlanabilir.³

Özellikle de kullanıcıların içerik yüklediği sistemler için bir ekstra güvenlik (defence-in-depth) mekanizması olarak düşünülebilir.

Örnek bir senaryo olarak, sayfamızda stealcookie.php adında kullanıcı tarafından yüklenmiş bir dosya bulunduğunu varsayalım. Bu dosyanın download edilmesini zorlamak için, aşağıdaki headerı da kullandık:

Content-Disposition: attachment; filename=stealcookie.php

Güvenilir olmayan içerikler için bir parça çözüm olduğu düşünebilir. Ama download'ı zorlasak dahi, kullanıcı karşısına Open ve Save, Aç / Çalıştır ve Kaydet gibi seçenekler gelecektir.

Kullanıcı direkt Open 'ı tıkladığında ise bu dosya sitemizin kontekstinde çalışacak ve bu dosyanın içerisindeki zararlı kod DOM'a ve sayfamıza ait kaynaklara erişebilecektir.

Bunu engellemenin yolu, Open seçeneğinin, seçenekler arasından kaldırılması ile mümkündür.

X-Download-Options: noopen

Aklınıza şöyle bir soru gelebilir: Kaydedip, tekrar dosyayı açabilir. Evet açabilir, fakat bu takdirde zararlı kod bizim sitemizin kontekstinde değil, kullanıcının dosya sistemi üzerinden çalışacaktır:

X-Download-Options Durum Değerlendirmesi

X-Download-Options headerı 370 siteden sadece 4'ünde kullanılmıştır. Internet sektöründe 3 site bu headerı kullanırken, Telekomünikasyon sektöründen yalnızca 1 site tarafından bu güvenlik headerı entegre edilmiştir.

Araştırmada Video-Film, İnsan Kaynakları, Forum gibi kullanıcı kaynaklı dataların servis edildiği sitelerde maalesef X-Download-Options kullanımını göremiyoruz.

Content-Security-Policy (CSP)

2012 Kasım ayında ilk versiyonu hayatımıza giren CSP, başta XSS olmak üzere, Clickjacking, Protocol Downgrading, Frame Injection vb bir dizi zafiyete karşı istemci tarafında ekstra güvenli katmanı sunmaktadır.

X-Frame-Options, X-XSS-Protection, gibi standartta olmayan pek çok güvenlik headerının muadilini bünyesinde barındıran CSP, yakın gelecekte, istemci taraflı güvenliğin en önemli araçlarından biri olacağa benziyor.

Content-Security-Policy (CSP) konusunda yazdığımız ayrıntılı yazıya Netsparker Türkiye Blogu üzerinden ulaşabilirsiniz.

Content-Security-Policy (CSP) Kullanımı

Araştırmaya konu olan 370 sitenin yalnızca 6'sında CSP'nin kullanılıyor oluşu, istemci taraflı güvenliğin en önemli araçlarından biri olan CSP'nin yeterince anlaşılamadığının önemli bir göstergesi olarak değerlendirilebilir.

httpOnly

Browser belleğine kaydedilen Cookie eğer bir httpOnly belirteci içeriyor ise, bu Cookie yalnızca HTTP isteklerine eklenir ve Javascript tarafından okunup, manipüle edilemez. Sayfadaki olası bir XSS zafiyeti vasıtası ile Cookie'nin ele geçirilmesine engel olmak için kullanılır. Oturum Cookie'leri için zorunlu olsa da, diğer Cookie'ler için set edilmesi zorunlu değildir.

Cookie'ler hakkında geniş bir değerlendirme için, HTTP İşleyişi ve Güvenliği Açısından Cookie ve Session Yönetimi başlıklı yazımızı okuyabilirsiniz.

httpOnly Cookie Durum Değerlendirmesi

İncelenen 370 web sitesinden yalnızca 216 tanesi anasayfalarında Cookie set etmektedir. Bu set edilen Cookie'lerin (216 adet üzerinden) yüzde 60'ı yani 129 adedi, set ettikleri Cookie'lerde httpOnly headerını kullanmaktadır.

Secure Cookie

Cookie'ler için kullanılan secure flag'ı bizatihi bir güvenlik headerı değildir, fakat Set-Cookie headerı ile kullanılan bir güvenlik parametresidir. Yalnızca güvenli bir bağlantı üzerinden set edilir.

Herhangi bir Cookie için secure headerını set ederek, bu Cookie'nin yalnızca güvenli isteklerle birlikte sunucuya gönderilmesini belirtmiş oluyoruz. Böylelikle, eğer bağlantı aradaki biri tarafından dinleniyorsa, güvenli olarak işaretlediğimiz Cookie'ler sadece güvenli bağlantılar ile birlikte gönderileceği için ele geçirilemeyecekler.

Ekseriyetle yaklaşım oturum Cookie'lerini secure olarak işaretlemek yönünde olsa da, bunun yol açabileceği riskler Defcon 24 konsefransındaki HTTP Cookie Hijacking'in Güvenlik ve Gizliliğe Etkileri sunumu ile açıkça ortaya konulmuştur. Bu sunum ile ilgili bir değerlendirme yazısına Netsparker Türkiye Blogu'ndan ulaşabilirisiniz.

HSTS (HTTP Strict Transport Security)

HSTS yani HTTP Strict Transport Security, adından da anlaşılacağı üzere, güvenli web iletişimini zorlayan bir mekanizmadır. Hatta HSTS için, güvenli web iletişim zincirinin eksik halkası da diyebiliriz.

Peki neden?

SSL, uçtan uca bir şifreleme sunarak, bütünlük, gizlilik ve yetkilendirme için elverişli bir yol sunar. İdeal bir SSL implementasyonunda, trafik boyunca transfer edilen verilerin, aktarım esnasında değişmediğinden, bir üçüncü kişi tarafından izlenemediğinden ve gerçekten de iletişim kurduğumuz kişinin bizim arzu ettiğimiz kişi olup olmadığından emin olabiliriz.

İdeal bir SSL implementasyonu tabirini bilerek kullandık. Çünkü web uygulamalarındaki kısmi implementasyonlar örneğin sadece ödeme ve login sayfalarının güvenli bağlantılar üzerinden çağrılmasını zorlamak, eksik bir implementasyon olarak hala pek çok saldırıya kapı aralamaktadır.

Bunun yol açabileceği riskler Defcon 24 konsefransındaki HTTP Cookie Hijacking'in Güvenlik ve Gizliliğe Etkileri sunumu ile açıkça ortaya konulmuştur. Bu sunum ile ilgili bir değerlendirme yazısına Netsparker Türkiye Blogu'ndan ulaşabilirisiniz.

Sayfalarımızın tamamını güvenli bağlantıya zorlamadığımız takdirde, saldırganlar kolaylıkla hedeflerindeki kişilerin güvensiz bağlantı üzerinden web gezinimi yapmasını sağlayabilir ya da MITM saldırıları ile HTTPS olarak bağlantılanan bir trafiğin HTTP olarak devam ettirilmesini (sslstrip) sağlayabilirler.

Yalnız bu kadar değil, süresi dolmuş sertifikalar ve geçersiz sertifikalar da güvenliik vadettiğiniz bağlantılarınız için bir risk arz etmektedir. Kullanıcıların kolayca, bir tıkla aştıkları bu tarz browser engelleri, sizin uygulamalarınız açısından büyük bir itibar kaybına yol açabilir.

Tüm bunları engellemenin bir yolu yok mu?

Web uygulamalarınız için SSL'i layığıyla implemente etmek istediğinizde, siteye yönelen tüm HTTP isteklerini HTTPS olarak değiştirmeniz, bunun dışında web sayfalarınız içerisine yüklenen, imaj, script, stil dosyaları gibi pek çok dosyaların da yine güvenli bir protokol üzerinden yüklenmesini sağlamanız gerekiyor. Ayrıca, sertifika hatalarında da, güvenlik daha önemlidir diyerek, bu tarz durumlarda gerekirse kullanıcının site gezinimini dahi engellemeniz gerekmektedir.

Bütün bunları manual olarak yapabilmek çok zor. Özellikle de olası bir sertifika hatası durumunda kullanıcının sitenizdeki gezinimini engellemek.

Bu noktada imdadımıza HSTS yetişiyor. Kasım 2012 yılında geliştirilen HSTS özelliği sayesinde, web sayfamızın yanıtında bir güvenlik headerı (Strict-Transport-Security) set etmemiz yeterli.

Bu yanıtla birlikte browserımıza şu talimatı vermiş oluyoruz: Sayfalarımıza yönelen tüm istekleri HTTPS bağlantıya çevir. Ayrıca, olası bir sertifika hatasında (güvensiz sertifika, süresi dolmuş sertifika vb..) kullanıcının web gezinimine devam etmesine izin verme.

Örnek kullanım:

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

max -age değeri ile birlikte, bu direktifin browser hafızasında tutulacağı süreyi saniye cinsinden belirtiyoruz.

HSTS implementasyonunda dikkat çeken iki özellik daha var. Bunlardan biri includeSubdomains parametresi, diğeri ise preload parametreleri.

includeSubdomains parametresi ile HSTS'in yani katı aktarım güvenliği talimatının sitenin bütün subdomainleri için uygulanmasını belirtiyoruz.

İlk İstek Sorunu ve preload özelliği

HSTS headerını ancak güvenli bir bağlantı üzerinden set edebiliyoruz. Güvenli iletişim ile ilgili diğer bir header olan Public Key Pinning gibi HSTS de Trust On First Use (TOFU) yöntemine dayanıyor. Yani ilk HTTP isteği sayfamıza yapıldığında, biz bunu hardcoded olarak güvenli bağlantıya yönlendireceğiz. Bu güvenli bağlantının yanıtında da HSTS headerı olacak ve browserlar artık bu talimatı belleklerinde saklayıp, bir dahaki güvensiz (HTTP) isteği doğrudan kendileri güvenli bağlantıya yönlendirecekler.

Peki bu ilk yapılan HTTP isteğinin MITM saldırıları ile engellenmesi söz konusu değil mi? Maalesef evet.

İşte bununla ilgili olarak da karşımıza preload özelliği çıkıyor.

preload özelliği sayesinde browserlarla birlikte deploy edilen HSTS listesine⁴ sitemizin de dahil edilip, bu ilk HTTP isteğine gerek kalmadan HSTS'in uygulanmasını sağlayabiliriz.

Bunun belirli şartları var:

1. Öncelikle geçerli bir SSL sertifikasına sahip olmalıyız.

2. HTTP'den HTTPS'e redirect ederken aynı host'u kullanmalıyız. (Yani HTTPS trafiği example.com için secure.example.com üzerinden değil, yine example.com üzerinden devam etmeli.).

3. www subdomain'i başta olmak üzere, tüm altdomainlerin güvenli bağlantı üzerinden sunuluyor olması,

4. Base domain (ana) domainden güvenli bağlantı üzerinden sağlanan HSTS headerımızdaki max-age değerinin en az 18 hafta yani 10886400 saniye olarak set edilmesi, includeSubdomains ve preload seçeneklerinin HSTS headerında bulunması gerekmektedir:⁵

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

PKP - Public Key Pinning

Public Key Pinning 'i anlamak için aslında güvenli bağlantı ne vaad ediyor ve bu nasıl gerçekleşiyor tekrar gözden geçirelim.

Kullanıcılarımız bizim sitemize güvenle erişmek istediklerinde, biz kendimizi tanıtan ve şifrelemede kullanılacak ortak anahtarın bize ulaştırılmadan önce şifreleneceği public anahtarımızı istemciye gönderiyoruz. Buna sertifika diyoruz. Bu sertifikada, sitemizin adı, sertifikanın ne zamana kadar geçerli olacağı, kaç bitlik bir kriptografik anahtar kullanıldığı gibi bilgiler var.

Bu sertifikada bir bilgi daha var. Onu da şöyle izah edelim. Biz istemciye, browser'a, bu benim sertifikam, diye açık anahtar bilgilerimizi gönderdiğimizde, istemci haliyle "Nereden bileceğim, gerçekten senin example.com olduğunu?" diye soruyor. Biz de inanmazsan ,büyüklerine sor, diyerek browserların güvenilir sertifikalar listesinde yer alan ve sertifika otoriteleri (CA) denen zincire müracaat etmesini sağlıyoruz. İşte bizim sertifikamızda bulunan bilgilerden biri de bu: Browserın ispat kabilinden sertifikamızın doğruluğunu danışacağı issuer'ın yani sertifikayı imzalayan firmanın adı. Browser buradan hareketle sertifikanın geçerli bir sertifika olup olmadığını kontrol ediyor ve şayet bir problem yoksa güvenli iletişime devam ediyor.

Dünya maalesef bu kadar masum bir yer değil. Aralıklarla yaşanan (en son 2013'de, hem de Türkiye'de) gördük ki, herhangi bir saikle, bu sertifika otoritelerinden biri bir başka web sitesi adına sertifika imzalayabiliyor.

İlk örneğimiz 2011 yılından. Hollandalı yetkili sertifika dağıtıcısı DigiNotar hack ediliyor. Ve bu hack eylemi sonrasında, 500 'e yakın sertifika imzalanıyor. Bu sertifikalarla 300 bin İran'lının Gmail de dahil olmak üzere pek çok Google servisi kullanımları izleniyor.

Yine benzer bir olay 2008 ve 2011 yıllarında yine bir sertifika otoritesi olan StartCom'un da başına geliyor. Bu saldırılarla birlikte, paypal.com ve verisign.com domainleri için sertifikalar üretiliyor. 2011'deki saldırıda StartCom'un rootkey'ine ulaşılıyor. Böylece sadece istedikleri site için sertifika üretebilmek değil, aynı zamanda üretilen sertifikaları geçersiz kılabilmek ya da tekrar imzalayabilmek şansına sahip oluyorlar.⁶

Bu sertifika otoriteleri, sertifika geçerliliğini teyid etmelerinin yanında bir de kendi yetkilerini devretmek kabilinden ara yetki sertifikaları imzalayabiliyor ve bu sertifika imzalama hakkını paylaşmış oluyor.

Son örneğimiz maalesef Türkiye'den ve yukarıda bahsettiğimiz ara sertifika sağlayıcılığı türünden bir sorun. Özetle Ağustos 2011'de Türk Trust şirketi, biri e-islem.kktcmerkezbankasi.org diğeri ise ego.gov.tr olmak üzere iki adet SSL sertifikası oluşturuyor. Fakat sistemde oluşan bir hatadan ötürü bunlar SSL sertifikaları olarak değil, ara sağlayıcı sertifikaları olarak üretiliyor.

Kktcmerkezbankasi.org için üretilen sertifikanın kullanılamadığı ama ego.gov.tr için üretilen sertifikanın aynı tarihlerde kullanımının devam ettiği belirtiliyor.

Checkpoint cihazı kendisine yüklenen sertifikalar sayesinde, şifreli trafiği izlemek için sertifikalar üretmeye başlıyor. Ürettiği sertifikalardan biri de Google'a ait.^{7 8}

Google için üretilen sertifikalardan biri, 26 Aralık 2012 tarihinde, Chrome tarayıcı üzerinden Google’a bildiriliyor.

Peki ama nasıl? Public Key Pinning yani PKP ile.

Chrome'un 13 versiyonundan itibaren desteklenen bu özellik sayesinde siteler kendi sertifikalarının fingerprint yani hash değerlerini Public-Key-Pinning response headerı ile tarayıcılara bildirebiliyor.

Tarayıcılar bu sertifikaları hafızalarına alıp, bundan sonra bu sitelere herhangi bir istekte bu belirtilen sertifikalar dışında bir sertifika iddia edilirse, güvenli bağlantı kurmayı reddediyor, hatta bu örnekte olduğu gibi belirtilen URL'e rapor ediyor.

İşte Public-Key-Pinning özelliği, güvenli iletişim için mecbur olunan otoritelerin, bir şekilde sahte sertifika imzalamaya zorlandığı durumlarda, kullanıcı ve sitelerimizi korumamızı sağlıyor.

PKP Headerımızı Nasıl Set Edebiliriz?

Public-Key-Pinning'in de bir güvenlik headerı olduğundan söz ettik. Yine güvenli bir bağlantı üzerinden (HTTPS) gönderdiğimiz Public-Key-Pinning headerı ile PKP özelliğini etkinleştirebiliriz:

Public-Key-Pins: pin-sha256="d6qzRu9zOECb90Uez27xWltNsj0e1Md7GkYYkVoZWmM="; pin-sha256="E9CZ9INDbd+2eRQozYqqbQ2yXLVKB9+xcprMF+44U1g="; report-uri="http://example.com/pkp-report"; max-age=10000; includeSubDomains

Alanları inceleyecek olursak,

pin-sha256="<sha256>" : Sertifikamıza ait açık anahtar parmakizinin (fingerprint) base64 encoded hali. Burada birden fazla genel anahtar bilgisi, yedek sertifika bilgileri de tanımlayarak, sertifikalarımızdan birinin expire olması durumundaki aksaklıkları yönetebiliriz.

max-age : Saniye cinsinden, sertifika bilgilerinin browser belleğinde tutulacağı süreyi belirtir.

includeSubdomains: Domaine ait altdomainler için de bu sertifika pinning işleminin uygulanıp uygulanmayacağını belirtir.

report-uri : Google örneğinde olduğu gibi, olası bir ihlal durumunun bildirileceği adresi tanımlar. İhlal bilgileri, burada belirtilen adrese POST metodu ile gönderilecektir.

Public-Key-Pinning mekanizmasını Report-Only modunda tanımlayarak, browserın sertifika zorlaması yapmasını engelleyebilir, yalnızca olası bir ihlal durumunda report-uri'de belirtilen adrese bildirimde bulunmasını sağlayabilirsiniz:

Public-Key-Pins-Report-Only: pin-sha256="d6qzRu9zOECb90Uez27xWltNsj0e1Md7GkYYkVoZWmM="; pin-sha256="E9CZ9INDbd+2eRQozYqqbQ2yXLVKB9+xcprMF+44U1g="; report-uri="http://example.com/pkp-report"; max-age=10000; includeSubDomains

Türkiye'de HSTS, PKP ve secure Cookie Kullanımı

Öncelikle şunu belirtmekte yarar var, incelemeye tabi olan 370 sitenin yalnızca 56 'sının anasayfa erişimi güvenli bağlantı yani HTTPS üzerinden sağlanıyor.

Araştırmaya göre bu 56 sitenin yalnızca 15 tanesi, yani yüzde 28'i HSTS 'i kullanırken; Public-Key-Pinning kullanan hiçbir site olmaması oldukça dikkat çekici.

370 sitenin yalnızca 34'ü anasayfa erişimlerinde güvenli bağlantı kullanıp, Cookie set ediyor. Bu 34 sitenin ise sadece 11'i set ettikleri Cookie'lerde secure flagını kullanmış durumda.

Aşağıdaki tabloda, Sektör, HSTS, PKP ve Secure Cookie bilgilerini bulabilirsiniz:

Sektör	Toplam Site	HSTS	PKP	Secure Cookie
Internet	70	9	0	2
Basın	114	0	0	0
Ticaret	29	0	0	4
Video, Film	37	0	0	0
Oyun, Bahis	19	1	0	1
Hükümet	22	0	0	2
Finans	14	0	0	3
Kaynaklar	13	3	0	1
Telekomünikasyon	9	1	0	2
Eğlence, Yaşam	12	0	0	0
Forum	6	0	0	0
Lojistik	4	1	0	0
İş Arama	5	0	0	0
Perakende	4	0	0	0
Hizmet	3	0	0	0
Emlak	2	0	0	0
Uçuş / Havacılık	2	0	0	0
Diğer	3	0	0	0

Sonuç

Dr. Emin İslam Tatlı ve Koray Emre Kısa tarafından yapılan bu araştırma, Türkiye'deki web güvenliğinin hal-i pür mealini gözler önüne seriyor.

Aralarında resmi sitelerin de bulunduğu 370 sitede yapılan incelemeye göre, maalesef güvenlik headerlarının kullanımı olması gereken seviyenin çok altında.

Yalnızca headerların kullanımı değil, güvenli bağlantılar konusunda da, özellikle de aralarında hükümet ve finans sitelerinin bulunduğu bir toplamda PKP'nin kullanılmıyor oluşu, bu alandaki risk faktörlerinin yeterince bilinemiyor oluşundan olsa gerek.

Araştırmaya konu olan sitelere login olunmamış ve subdomainlerin bu araştırmaya konu edilmemiş olması Pandora'nın Kutusu'nun tam anlamıyla açılmadığının göstergesi. Öyleyse göz önüne serilmeyen noktalardaki güvenlik sorunlarına dair kaygı duymamız haksızlık olmayacaktır.

Daha fazla farkındalık yaratabilmek için, güvenliği sadece güvenlikçilerin meselesi olmaktan bir an önce kurtarmalı ve geliştiricileri, yöneticileri bu işin bir parçası haline getirmeliyiz.