CROSS SİTE REQUEST FORGERY (CSRF) NEDİR ?

Basit bir google araştırması ile elde ettiğim şekilde açıklayacağım. Türkçe açılımı “Siteler Arası İstek Sahtekârlığı” şeklinde olan CSRF zafiyeti; web uygulamasını kullanmakta olan kullanıcıların istekleri dışında işlemler yürütülmesidir. Uygulamaya giden isteklerin hangi kaynaktan ve nasıl gönderildiği kontrol edilmeyen sistemlerde ortaya çıkan bu zafiyet, aslında uygulamayı kodlayan yazılımcıların gözünden kaçan bir ayrıntıdır diyebiliriz. Genelde CSRF veya XSRF şeklinde kısaltılan bu güvenlik açığı “Session Riding” olarak da bilinmektedir. Kısaca bu şekilde değerlendirebiliriz.

Peki CSRF ile ne gibi zararlar ile karşılaşabiliriz ?

Bu güvenlik açığı ile verilebilecek zararlar uygulamayı kullanmakta olan kullanıcının yetkilerine bağlıdır. Yani bir sistem yöneticisinin hesabı ile standart kullanıcının hesapları üzerinden uygulanacak bir CSRF açığının vereceği zararın boyutları farklıdır. Basit bir örnek ile bir araba düşünün bu arabayı kullanan iki kişi olduğunu var sayalım seçilen kurban ile arabayı aynı anda fakat farklı işlemler gerçekleştirerek kullanıyoruz diyebiliriz. Bu durumda, kullanıcı uygulamayı kullanmaya devam ettiği sürece onun istekleri dışında kendi isteklerinizi sisteme gönderebilirsiniz. CSRF nedir ne tür zararlar verebilir kısmını basic olarak kavradığımıza göre artık zafiyetin keşfi ve sömürmek için işe koyulabiliriz.

Zafiyet keşfi ve sömürü aşamasına geçmeden önce docker yardımı ile DVWA' ı ayaklandırıyoruz. Ayaklandırma işlemi için daha önceden bahsettiğim XVWA gibi DVWA'a docker.hub üzerinden işlemleri gerçekleştiriyoruz linki şuraya bırakıyorum adımları uygulayarak localhostunuzun belirttiğiniz portuna browser üzerinden ziyaret ederek ulaşabilirsiniz.

DVWA kurulumunu tamamladıktan sonra http://127.0.0.1:8086/ adresine gidip create / reset database işlemini gerçekleştirip login oluyoruz.

Default Credentials;

login olduktan sonra security kısmında low seviyesine alıp CSRF dizinine tıklıyoruz ve bizi bir adet şifre değiştirme ekranı karşılamakta.

nasıl bir tepki verebileceğini görmek adına yapacağım adımları burp aracı ile intercept on yapıp trafiği keseceğim ve inceleyeceğim

yapılan istek GET metodu kullanılarak şifreyi güncellemekte tam da burada kullanılan metodun etkisi sonucu zafiyet oluşmakta. Herhangi veri okuma işlemlerini GET metodu ile yapılabilir fakat veriyi yazma, değiştirme ve silme işlemleri gibi tüm operasyonların POST metoduyla yapılması güvenlik önlemlerinden biridir. Yazımın son kısımlarında detaylıca bahsedeceğim. Okuyup araştırıp edindiğim bilgilerin karmasını buraya yazıyorum daha iyi pekiştirmek için o yüzden eksik ve ya yarım bilgiler barındırabilir. Lütfen beni uyarmaktan çekinmeyin ufak bir bilgi verdikten sonra kaldığımız yerden devam edelim.

http://127.0.0.1:8086/vulnerabilities/csrf/?password_new=test&password_conf=test&Change=Change#

urlde de şifre değiştirme işlemini başarılı bir şekilde değişim gösterdiğini gözlemlemekteyiz. Aslında zafiyetin varlığını tespit ettik demekte yanılıyor olmayız. Log out olup değişiklik yaptığımız şifreyi denediğimizde de başarılı değişimi ispatlamış durumdayız. Zafiyeti sömürebilmek için şimdi yukarıdaki urlde password_new ve password_conf kısımlarını manuel olarak değişiklik gösterip neler gözlemleyebileceğimizi görelim.

http://127.0.0.1:8086/vulnerabilities/csrf/?password_new=abc&password_conf=abc&Change=Change#

değişiklikleri yapıp requesti mi gönderdiğim de dönen response da

şifrenin değiştirildiğini gözlemlemekteyiz. Şifrenin değişikliğini ispatlayabilmek için Log out olup login işlemini tekrarlamak için sisteme giriş talebinde bulunuyoruz.

POST metodu ile /login.php dizinine

isteğini yolluyor. Ve şifrenin değiştirildiğini kanıtlamış oluyoruz. Kullanıcının bilgisi dışında şifresini değiştirmiş oluyoruz basit bir senaryo ile daha iyi oturtmak için şöyle diyebiliriz

Bahsi geçen zafiyeti barındıran bir web sitesi üzerinden bir kullanıcıyı hedef aldığımızı ve bir mail yoluyla http://zafiyetibarındıransite/vulnerabilities/csrf/?password_new=abc&password_conf=abc&Change=Change# bu linke tıkladığını var sayalım ve linke tıklaması durumunda kurbanın var olan site üzerindeki kullanıcı hesabının şifresinin değiştirilebileceğini göreceğiz tabi bu senaryoyu gerçekte bu kadar basit olmayacaktır ki etik bir bakış açısıyla gitmek her zaman en sağlıklı olacaktır. Yeterli seviye de zafiyet nedir ? nasıl zafiyeti keşfederiz ve sömürürüz kısmını anladığımıza göre zafiyetin kapatılması için gereken adımların inceleyelim.

CSRF ZAFİYETİNE KARŞI ALINABİLECEK ÖNLEMLER NELERDİR ?

Alınacak önlemler 2 ye ayrılmaktadır. Bunlar Sistem tarafından bir diğeri ise kullanıcı tarafından alınması gereken önlemler

1. Kullanıcının sisteme gönderdiği önemli talepler POST metodu ile alınmalıdır. (veriyi silme, değiştirme ve yazma işlemleri gibi).

CSRF zafiyetinin bir başka önlemi için yapılması gereken adım aynı zamanda en popüler yöntemdir, kullanıcıya rastgele üretilmiş eşsiz bir "token" bilgisi vermektedir. Bu tokene CSRF Token ya da Synchronizer Token olarak da adlandırılabiliyor. Bu token nasıl olmalıdır.

• Bu tokenin uzunluğu minimum 32 karakter olmalıdır.
• Token içinde kullanılan değer, kullanıcı adı, ID'si, Session değeri gibi bilgiler kullanılarak üretilmemelidir.
• Her token belirli bir süre için geçerli olmalıdır.
• Token oturum sonlandıktan sonra yok edilmelidir.
• Captcha kullanımıda CSRF zafiyetine çözüm olacaktır.
• Yapılan her isteğe karşın HTTP Referer başlığı kontrol edilebilir. Buda uygulama geliştirici Referer başlığını inceleyerek yapılan isteğin kendi uygulaması üzerinden gelip/gelmediğini doğrulamış olacaktır. (Yazılım Güvenliği adlı kitaptan okuyup öğrendiğim bir bilgiyi buraya not etmek istedim.).

NOT: Geçmişte Flash ve XMLHttpRequest ile bu başlığın manipüle edilebildiği gözlemlenmiş. Ayrıca Referer başlığı kardırılarak da geçerli isteklerin yapılabildiği gözlemlenebilir. Kısacası Referer kontrolünün tamamen güvenilir bir gemi olduğunun idda edemeyiz.

Token işlemi şu şekilde çalışmakta;

• Web sunucusu bir token oluşturur. (Bu token işlem yapıldıkça yeniden üretilir.).
• Token, formda gizli bir bilgi olarak depolanır.
• Kullanıcı POST işlemini gerçekleştirir.
• Token bilgisi POST verilerine dahil edilir.
• Web uygulaması, sistem tarafından oluşturulan tokeni, gönderilen token ile karşılaştırır.
• Eğer token verileri eşleşirse, isteğin gerçek kullanıcı tarafından gönderildiği anlaşılır ve istek onaylanır.
• Eşleşme yoksa, istek reddedilir. Bu sayede CSRF niyetli istekler engellenmiş olur.

Kullanıcı tarafında alınması gereken önlemler:

• Çerezleri ve site verilerini düzenli olarak temizlemek oldukça önemlidir.
• Bilmediğiniz bağlantılara tıklamamalı, kimden geldiğini anlamadığınız mailleri açarken dikkatli olmalısınız.

Umarım beğenmişsinizdir tekrar söylemek istiyorum kitaplar ve google araştırmalarım sonucu bilgileri elde ediyorum ve daha iyi pekiştirmek adına yazıya döküyorum eksiklerim olabilir lütfen eksiklerimi bana bildiriniz. İyi haftasonları geçirmenizi dilerim.