.Net Core Security Headers
Herkese merhaba;
Bu kez biraz güvenlik konuşalım istedim. Security Headers konusunu Asp.Net Core ile inceleyeceğim bu yazıda.
Ben bir yazılımcının yazdığı koda defansif bir şekilde bakıp, acaba bir açığa sebep olur muyum diye düşünmesi gerektiğini düşünüyorum. Zaten tersini düşünen de yoktur diye tahmin ediyorum.
Şu anda yer aldığım takımda da zaman zaman güvenlik bulguları ile uğraşıp çözüme kavuşturma konusunda uğraş verdiğimiz için bu konuya önemle bakıyoruz. Dokunduğumuz yerler finans yazılımlarının altyapıları olduğu için de haliyle bilgi güvenliği oldukça fazla önem arzediyor. Sistemlerimizdeki bulguları kapattıkça aslında yazılımımızın kalitesini de arttırmış oluyoruz. Bu nedenle siber güvenlik ekibimizle zaman zaman beraber çalışıp onların ofansif yaklaşımını anlayıp en uygun çözümleri sunmaya çalışıyoruz. Zaman zaman kan ter gözyaşı döküp günün sonunda yine ortak bir noktada oluyoruz ve kalitemizi belki bir tık belki büyük bir tık daha arttırmış oluyoruz.
Konumuz Security Headers. Headers(başlık bilgileri), sunucunun tarayıcıya kendi domainine nasıl davranması gerektiğini anlatan, son kullanıcıdan gizli direktiflerdir. Örneğin “cache-control” isimli başlığı tarayıcıya, istek ya da cevaplar için bir caching yapılıp yapılmayacağını belirtir. Örneğin google.com’ a yaptığımız bir istek için başlık bilgilerinin Burp Suite’te görünümü aşağıdaki şekildedir:
Burada ilk satır protocol bilgisini, sonraki satırlar başlık bilgilerini, aradaki boşluk ise bundan sonra gelecek satırların html kodu olduğunu ifade eder.
Başlık bilgilerini tarayıcılarda “Network” sekmesindeki isteklere tıklayarak da görebilirsiniz:
Genellikle güvenlik açıklıkları sunucu tarafında alınan önlemlerle giderilmeye çalışılır. Ancak iyi düşünülmüş bir tasarım ile zafiyetlerin bir kısmını istemci tarafında engellemek mümkündür.
.Net Core’da başlık bilgileri key-value pair şeklinde, middleware olarak response’a eklenir.
X-Xss-Protection
Owasp Top 10 listesinin hala popülerliğini koruyan bulgu tipi “XSS” için “X-Xss_Protection” başlık bilgisi kullanılıyor. Uygulama tarafında almanız gereken önlemleri mutlaka alıp response’a da “X-Xss-Protection” başlığını ekleyebilirsiniz. Yine de alacağınız önlemler uygulamanızın senaryosuna göre değişkenlik gösterecektir.
Buradaki 1 değeri XSS’e karşı korumanın aktif olduğu manasına gelir. “mode=block” ise Reflected XSS atağı durumunda sanitize işlemi yapmadan direkt tarayıcınızın sayfayı render etmesini engellemek içindir. Dolayısı ile zararlı yazılım da çalışmayacaktır.
Content-Security-Policy
Bu başlık bilgisi sayfaya yüklenmesine izin verilecek dinamik kaynaklar özelinde kontrolü ele almamıza yarar. “XSS” gibi “Code Injection” ataklarına karşı kullanılabilir. Örneğin hem kendi domaininizden hem de belirli bir başka domainden script ve style kaynaklarını yüklemeye izin veriyorsanız şu örnekteki gibi kullanılabilir:
Burada “self” kendi domaininizi, sonrasında gelen url ise kendi domaininize ek olarak yükleme yapılabilecek kaynak url’ini ifade etmektedir. Sadece kendi domaininizdeki script, img veya style vb. dosyaları yüklensin istenirse o zaman sadece self eklemek yeterli olacaktır.
X-Content-Type-Options
Tarayıcılar “Content-Type” başlığı ile belirtilmemiş içerikleri ekranda göstermek için içeriği koklar, yani kendileri bir değerlendirme yapıp içerik türünü bulur buna da “MIME Type Sniffing” denir.
Bunun nesi zararlı derseniz bu senaryo aslında yine “XSS” zafiyetine yol açabilmektedir. Örneğin saldırgan zararsız görülecek bir uzantı ile mesela .png ile bir dosya yükleme işlemi yapıyor ancak dosya içeriğinde zararlı bir script olsun diyelim. Uzantı uygulamamızı yanıltır da saldırgan yüklemeyi tamamlayıp ardından dosyayı tarayıcı üzerinde açarsa tarayıcı bu içeriği göstermek için bir analiz yapacak ve içeriğin “text/html” olduğuna karar verecektir. Render işlemi gerçekleşecek ve zararlı yazılım da bu sayede çalışacaktır.
Tarayıcının içeriği kendisinin belirlemesini engellemek içinse bu başlığa “nosniff” değerinin geçilmesi gerekmektedir:
X-Frame-Options
“Clickjacking” ataklarını engellemek amacıyla kullanılır. Clickjacking kullanıcının işlem yaptığı sayfanın aslında işlem yapmak istediği sayfa değil de bir iframe içerisine yüklenmiş bir başka sayfa olması ve kullanıcının bunu farketmeyip işlemler yapması durumu.
Kullanıcı örneğin banka hesabında işlem yaptığını sanıyor, aslında saydamlık değeri düşük bir iframe içinde bambaşka bir sayfadaki butonlara tıklayarak yem olabilir, hiç onaylamayacağı bir transfer için “Onayla” gibi bir butona farketmeden basıyor olabilir. Bunun önüne geçmek için “X-Frame-Options” isimli başlığını şu şekilde kullanırız:
DENY: Sayfanın bir iframe içinde çağrılması engellenmiş olur.
SAMEORIGIN: Kendi domainimizde sayfanın iframe içinde çağrılmasına izin verilmiş olur.
ALLOW-FROM Uri: Sayfanın belirtilen url için bir iframe içinde yüklenmesini sağlar.
Strict-Transport-Security
“Man in the middle” ataklarından korunabilmek için tarayıcıda yapılan http isteklerinin https’e dönüştürülebilmesi için eklenen başlıktır.
Asp.Net Core bu başlık bilgisini kendisi bir “UseHsts” ile middleware olarak eklemiş ve kullanıma sunmuştur:
Referrer-Policy
Öncelikle “referer” nedir bir açıklığa kavuşturalım. Ziyaret edilen web sayfasına nereden ulaşıldığı bilgisi bu başlık bilgisi ile requeste yani isteğe eklenir, ziyaret edilen site kendisine nereden/hangi sayfadan gelindiğini bilir. Bu bilginin ziyaret edilen web sitelerinde görünmesinin sakıncalı olduğu durumlarda Referrer-Policy ekleyebilirsiniz:
no-referrer: referer başlığı tamamen kaldırılıp gönderilmesi engellenmiş olur.
no-referrer-when-downgrade: https bir kaynaktan http olan bir kaynağı ziyaret ederken referer başlığı gönderilmez. Bir policy eklenmez ise varsayılan davranış bu olur.
origin: Sadece domain bilgisi gönderilir. Örneğin https://mymedium.com/documents sadece https://mymedium.com olarak gönderilecektir.
origin-when-cross-origin: Aynı domainde olmayan bir web sayfası ziyaret edildiğinde sadece domain bilgisi gönderilir. Tersi durumda tüm url gönderilir.
same-origin: Aynı domainde olan web sayfaları için referer bilgisi gönderilir, tersi durumda gönderilmez.
strict-origin: https protokollü bir web sayfasında https protoküllü bir başka web sayfasına giderken ya da http protokollü bir web sayfasında http protokollü bir web sayfasına giderken sadece domain bilgisi gönderilir. Farklı protokoller için referer bilgisini gönderilmez.
strict-origin-when-cross-origin: Farklı domainli web sayfaları için strict-origin kurallarını işletir.
unsafe-url: Tüm url bilgisi gönderilir.
Feature-Policy
Uygulamanızın hangi özelliklere ihtiyacı olduğunu tarayıcıya bildiren başlık bilgisidir. Örneğin, mikrofon, kamera, usb gibi özelliklere ihtiyaç duyulmadığında bunlar bu Feature-Policy başlığı ile tarayıcıya söylenebilir:
Expect-CT
Bu başlık, sitelerin, o site için yanlış yayınlanan sertifikaların kullanımından kaçınmak ve bu durumun fark edilmemesini önlemek için kullanılır. owasp.org sitesinden okuduğuma göre Haziran 2021 itibari ile kullanılmayacak. owasp.org’un ilgili yazısını kaynaklara ekledim.
X-Permitted-Cross-Domain-Policies
Bu başlık, sitelerin içeriklerinin Adobe Reader gibi diğer uygulamalara gömülebilmesini engellemek amacıyla eklenebilir:
Server
Bu başlık bilgisi sunucumuz ile ilgili bilgileri varsayılan olarak gösterdiği için çoğu zaman kaldırılması faydalı olacaktır. Kaldırmak içinse hem “web.config” hem de “Kestrel” seçeneği kullanılabilir. Ben Kestrel için olanını .Net Core 3.1 için aşağıdaki gibi yazdım:
Örnek Bir .Net Core MiddleWare
Bu response header bilgilerini Asp.Net Core uygulamanızda bir middleware oluşturarak kullanabilirsiniz. Ben bir örnek oluşturdum:
Çok daha detaylı bilgiyi bulabileceğiniz ve benim de yararlandığım kaynaklar:
Yazının geliştirilmesi gereken kısımları var ise yorumlarda belirtin, mutlu olurum. Esen kalın.
Elif
