Sunucu güvenliği: XSS – Cross Site Scripting

Dinamik websitelerindeki güvenlik aciklarindandir. Öğrendiğim kadarıyla GET üzerinden sunucuya gönderilen verinin tamamlayici kodlarla değiştirilerek scriptin çıktılarının manipüle edilmesine dayanıyor. Bu tür açıkları olan siteleri saldırganlar arama motorları üzerinden arayarak bulabiliyor. Bunun için kullandıkları tespit edici arama kelimelerine saldırgan jargonunda dork deniyor.

Örneğin; inurl:sayfa.php?id=1 gibi. Bunun yanına gov vb. domain uzantılarını yazarak belirli türdeki siteleri hedefleyebiliyorlar. Bulunan her sitede açık var diyemeyiz. Buldukları sitelerde XSS açığı olup olmadığını XSS denemesi yaparak anlayabiliyorlar.

Örneğin deneme şekli olarak URL adresine şunun gibi bir şey yazıyorlar;

Ekrana uyarı penceresi gelirse ha evet XSS açığı varmış diyorlar ve farklı XSS scriptleri ile sitenin scriptini farklı şekilde tamamlayarak sitenin sunucu tarafındaki kod ve verilerine erisiyorlar.

XSS Saldırı Türleri

Stored XSS

Bu saldırı turu XSS ile sunucuya gönderilen kodun tüm kullanıcıları etkilemesi söz konusu. Yani kullanıcıların şifreleri dahil bilgileri çalınabilir.  Ornegin kullanıcı giriş sayfasında çalışan bir veritabanı sorgusu mevcutsa, bu sorgunun çıktısı ile kullanıcı giriş formu değiştirilip, kullanıcının giriş yapmak için yazdığı bilgiler farklı sunuculara gönderilerek depolanabilir. Kullanıcılar her sitede benzer ya da aynı şifreleri kullandığı için epostalari ve diğer sosyal medya hesapları da tehlikeye girmiş olur. Sadece veritabanına erişim sağlandığı durumlarda kullanılan saldırı şekli bu olmakta.

Reflected XSS

Bu saldırı veritabaninda duran kodlar yerine URL içerisinden gönderilen GET değişkenleri yapılabiliyor. Saldırı turu ziyaretçilere direkt olarak yansımıyor. Fakat üye olduğu bilinen bir epostaya gönderilen örneğin bir şifre hatırlatma URL adresi ile yine kullanıcının bilgileri tehlikeye atılmış olur. Bu tur saldırıda veritabanı veya kodlara saldırgan erisememis olabilir. Fakat bu acemi internet kullanıcıları için tehlikeyi bertaraf etmiş olmuyor.

DOM XSS

Bu noktada sitenin kodlarına da artık erişim sağlanmış oluyor. Sitenin içerisine javascript kodları ile normalde olmaması gereken, kullanıcıya gösterilmeyen bir takım kodlar eklenerek kullanıcı verileri calinabiliyor.

XSS ataklarından korunmak

GET ile gönderilen page veya id gibi değerlerin HTML, JS vb. kodlardan temizlenmesi gerekiyor. Bunun en ilkel yollarından biri PHP için htmlspecialchars kullanarak kodlarin htmlden dönüştürülmesi. Bu konu iyi bir framework ile aşılabilir. Örneğin kullandığım Symfony framework HTTPComponent ile bu tur şeyleri önlüyor. Ayrıca route tanımlarına değişkenlerin içerebileceği karakterler sinirlanarak sadece sayı veya metin olabilir gibi regex ifadeleri de eklenebiliyor. Fakat Symfony gibi bir framework kullanmak öğrenmesi ciddi zaman alan ve uygulama yapması da o kadar çabuk olmayan bir yapı ve büyük siteler için kullanılır. Bu yüzden apache düzeyindeki tedbirler hem sistemciler hem geliştiriciler için daha basit ve kapsam olarak da geniş diyebilirim.

Apache için XSS tedbirleri

Fakat bu oldukça ilkel şekilde yazılmış bir websitesi için alınabilecek bir tedbir. Eğer sunucunuz linux ise veya .htaccess dosyaları web alaninizda çalışacak şekilde ayarlanmissa apache sunucusu için farklı ve genel bir tedbir daha var. Bunu yapmak için sunucuda apache mod_headers aktif olmalı.

XSS ataklarını engellerken bir ayar daha var. Bu da x-frame ayarı. Bu aşağıdaki satır sitenizde açılabilecek frame ve iframelerin sadece yine sizin sitenizden olmasını gerektiriyor. Bu sayede farklı saldırgan adresleri kullanicilarinizin verilerine talip olamıyor. SAMEORIGIN degerini DENY yaparsanız kendi sitenizden bile frame açılmıyor.

Özellikle izin vermek istediniz frame URL adresleri olması durumunda ALLOW FROM uri kullanabilirsiniz.

Bir başka nokta ise XSS atağının upload edilmiş bir dosyanın içeriğinin değiştirilerek yapılabilir olması. Yani bir resim dosyası upload etmesini beklediğiniz kullanıcı resim dosyasının sadece header bilgilerini kullanıp devamında sunucunuzda çalıştırmak istediği kodları eklemiş olabiliir. Bunu için X-Content-Type koruması kullanılıyor. Buradaki mantık siteye JPG uzantılı bir dosya gönderilmesine rağmen aslında html ve js içerikli bir dosyanın gönderilmiş olması. Mime-Type kontrolü yapmayan bir upload işleminden bu geçebilir. Kullanıcı browser ise dosya açıldığında uzantısı JPG olmasına rağmen mime-type html/text olduğu için bu resim dosyasını siteymis gibi calistirabilir. Bu veritabanı yerine dosya olarak depolanmış bir XSS açığı demek oluyor. Bunu için .htaccess dosyanizda ya da virtualhost taniminizda aşağıdaki satırı kullanmanız gerekiyor. Bu sayede dosya tipine browser karar vermiyor, sunucunuzdaki dosya uzantısı geçerli oluyor.

Diğer bir XSS açığı konusu httpOnly ile cookie koruması sağlayarak PHP ile oluşturulmuş bir cookieye JS ile erisilip kullanıcının bilgilerinin başka yerlere gönderilmesinin önüne geçmektir. PHP SessionId gibi bir cookie değeri browser içine saldırgan tarafından koyularak açılmış oturum anahtarı kullanılıp oturuma ortak olunabilir. Bunu için bu satırı .htaccess veya apache virtualhost için kullanıyoruz.

Bir başka XSS tedbiri  TraceEnable değerini kapatıp off yapmaktir.

Bunun dışında CSP ile daha detaylı CSS ve JS çağrıları yaparak farklı sitelerden yapılacak css ve js dosyalarının sitenize çalışmasını önleyebilirsiniz. Bu adreste CSP hakkında cidden detaylı bir kaynak var. Kısaca ilgili satır şöyle oluyor;

Genel olarak toparlarsak .htaccess dosyamız ya da virtualhost ek satırlarımız şöyle oluyor;

Burada sadece XSS ile ilgili bir takım tedbirlerden söz ettim. Bunlar hem diğer ataklar için yeterli değil hem de XSS için yeterli olmayabilir. Daha farklı bilgilerle güvenliğinizi arttırabilirsiniz. Yeni XSS tedbirleri bulursam bu blog icinde tekrar paylaşacağım.

Yeni satirlar (12 Ekim 2017)

X-Frame-Options ayarimizi SAMEORIGIN ya da DENY olmasi, bir baska siteden frame acarak sitemizin gorunmesini engelliyor. Fakat baska bir sitede acilmis frame icindeki form bizim sitemize hala POST yapabilir. Islem sonunda bir veri ekrana cikacaksa da cikmiyor.

PHP calisma modu ve XSS (19 Ekim 2017)

PHP calışma modundan dolayı cPanel/centos sıstemlerde apache security modul için bazen .htaccess dosyasında headers satırlarını tetiklemiyor. Bunun nedeni anladığım kadarı ile php dosyalara apache üstünden değil direkt olarak php’nin cevap verecek şekilde ayarlanması. Bu durumda header tanımlarını PHP header olarak yazmanız gerekiyor. Tum dosyalarda include edilen veritabanı bağlantisi içeren bir dosya içinde bunu yaparsanız XSS vb header bilgilerini görebiliyorsunuz.

VPS ve Linux

Bir süredir Ubuntu linux kullanıyorum. Deneyimlerimi sıcak sıcak paylaşmak isterim. Bir kere linux kullanıcı dostu olmak yolunda ciddi yol almış. Sadece Ubuntu değil Mint Linux oldukça güzel sistemler. Ubuntu, başlagıç kullanıcıları için tavsiye edilse de server sürümü de mevcut. Onu da VPS üzerinde kullanıyorum. Gayet hızlı.

ubuntu

Linux’un bir güzel yanı derlenmemiş dosyaları çalıştırmak için Windows’da olduğu gibi ortam değişkeni tanımlanıza gerek yok. Dosyaya chmod izinlerinden çalıştırılabilir dosya özelliği atıyorsunuz oluyor  bitiyor.

Herşeyi elle ayarlama işini yapabilirsiniz ama bilgisayar kullanmanın genel kitle için internet kullanmaya dönüştüğü şu dönemde hiçbir şeyi  ayarlamadan internette girip rahatlıkla gezinebilirsiniz. Kurulumda çok kolay. Wubi ile Windows içinden Ubuntu kurabilirsiniz. Bir disk bölümü seçiyorsunuz o kendisi hallediyor işlemleri. Açılışta da Windows mu yoksa Ubuntu ile mi açacaksınız diye soruyor. Bunları detaylı yazmıyorum çünkü internette bir çok kaynak var bununla ilgili.

Linux ile uğraşmamın bir nedeni geliştirme ortamı olarak kullanmak. Eclipse ve Java tabanlı diğer uygulamalar inanın Windows ortamına göre çok çok hızlı ve kararlı. Pek çok plugin Eclipse kurulumlarında sorun verirken Linux içinde hızla hallettim. Eclipse için SVN ve SQL Explorer pluginlerini rahatlıkla ekleyip internetten biraz ingilizce kaynak araştırırak ayarlayabilirsiniz. PHP ve MySQL kurmak ise çok basit. Bir komut ile yapabiliyorsunuz. Hepsi bloglarda detaylı var.

Geliştirme ortamı dışında VPS kiralayıp Ubuntu Sever kurarak hosting masrafımı düşürmek istedim. Bu sırada ISPConfig ve Zpanel ile yönetim araçlarını buldum. İkisi de plesk ve cpanel gibi web control panelleri. Zpanel başlangıç için güzel. Fakat sadece Apache ile çalışıyor. Onun kütük dosyalarını işleyebiliyor. ISPConfig daha etraflıca birşey. Zira Nginx server ile de çalıştırabiliyorsunuz.

Ben açıkcası geç kalmışım. İşten güçten zaman ayırıp uğraşmıyordum. Şimdi tatilde linux ile uğraşma fırsatı bulunca keşke işi gücü bırakıp linux öğrenseymişim diyorum. Sizde mutlaka deneyin, Özellikle yazılım geliştirici iseniz windows açmak istemeyeceksiniz.