Her Yönüyle CSRF Açığı

[Ozan]

Herkese merhabalar. Bu yazımda CSRF olayını ele alacam. Konuyu her yönüyle baya uzun bir şekilde anlatacam. İyi okumalar…
Bu yazıda; Siteler Arası İstek Sahteciliği’nin (CSRF) ne olduğu hakkında konuşacak, birisinin başarılı bir CSRF saldırısı yapmasını ve CSRF saldırısını nasıl güçlendireceğini açıklamaya çalışacaz (örneğin, CSRF’yi diğer güvenlik açıklarıyla birleştirme). CSRF, bir son kullanıcıyı, halihazırda kimliği doğrulanmış olduğu bir web uygulamasında istenmeyen eylemler gerçekleştirmeye zorlayan bir saldırıdır (bu herkesin dilinde anlatılan basit hali). Saldırgan, sosyal mühendislikten biraz yardım alarak (e-posta / sohbet yoluyla bağlantı gönderme gibi), bir web uygulamasının kullanıcılarını saldırganın seçtiği eylemleri yürütmeye zorlayabilir.

Başarılı bir CSRF istismarı, normal bir kullanıcı olması durumunda son kullanıcı verilerini ve işlemlerini tehlikeye atabilir. Hedeflenen son kullanıcı yönetici hesabıysa, web uygulamasının tamamını tehlikeye atabilir. Daha spesifik olarak, CSRF, başarılı olabilmek için birden fazla tasarım kusurundan yararlanmak zorunda olan bir Web Uygulaması güvenlik açığıdır. CSRF saldırısının yararlanabileceği tasarım kusurları:

1. Giriş Doğrulama (örneğin POST’u GET’e dönüştürme)
2. Erişim Kontrolü (örneğin, Oturum Tespiti)
3. Ayrıcalık Atama (örneğin, Ayrıcalık Yükselmesi)

Not: Elbette, duruma bağlı olarak, diğer güvenlik açıklarıyla da kullanılabilir. SQL Injection gibi bir istismar sonrası işlemin parçası olarak bir CSRF ile birleştirilebilir (örneğin, SQL cookie’yi enjekte etme ve veritabanındaki geçerli çerez deposuna erişim sağlama gibi).

Peki Ama tam olarak bir CSRF nedir?

Bir web sitesine giriş yaptıktan sonra, web sitesi tarayıcınıza bir çerez içinde bir kimlik doğrulama kodu (her zaman değil) verir. Takip eden her http POST veya GET isteğinin gönderildiği çerez içinde, isteklere bağlanan çerez, siteye gerçekleştirdiğiniz her türlü işlemi yapma yetkiniz olduğunu bildirir. Burada, çoğu Web Uygulamasının kullandığı tipik bir kimlik doğrulama ve yetkilendirme şemasına atıfta bulunuyorum.
Banka web sitenizi ziyaret ettikten hemen sonra kötü amaçlı bir web sitesini ziyaret ettiğinizi veya banka web hesabınıza giriş yaparken başka bir web sitesini ziyaret ettiğinizi varsayalım. Önceki sitedeki oturumunuz hala geçerli olabilir. Bu nedenle, dikkatli bir şekilde hazırlanmış kötü amaçlı bir web sitesini ziyaret etmek (bir spam bağlantısını tıklamış olabilirsiniz), bir Html formunun bir önceki web sitesine gönderilmesine neden olabilir. Tarayıcınız, kimlik doğrulama çerezini bu siteye geri gönderir ve siz istemediğiniz halde, sizin adınıza bir istek yapıyor gibi görünür.

Evet ama hala nedir Bu CSRF ?

Bir CSRF, belirli koşullar altında güvenlik açığı bulunan Web Uygulamasına gönderildiğinde, Web Uygulaması’nın kullanıcı adına bir eylem gerçekleştirmesine neden olabileceği bir POST veya GET http isteğidir. Artık anlamlı CSRF saldırıları, Mağdur kullanıcı verilerinin Doğruluk veya Gizlilik kaybına veya Kullanılabilirliğine neden olabilecek saldırılardır. Örneğin, bir e-Bankacılık Web sitesi CSRF’ye karşı savunmasızsa ve savunmasız olan Web Sitesinin işlevi para transferinden sorumluysa, bu durum yüksek önem taşıyan bir CSRF’dir ve düzeltilmelidir.

Basit bir CSRF Örneği;

http://www.hedefbanka.com/?transferEuros=3000?maliciousUserAccount=9832487

Tıklandığında yukarıda gösterilen bağlantı, kurban kullanıcı hesabından kötü niyetli kullanıcı hesabına, 9832487 kimliğiyle 3000 Euro’yu transfer etme yetkisi verebilir;

Aşağıdaki diyagram bunun daha analitik olarak nasıl olabileceğini göstermektedir:

Not: Yukarıdaki şemada, saldırganın güvenlik açığından yararlanabileceği adımlar gösterilmektedir (4. adım, kötü amaçlı eylemi gerçekleştiren CSRF yükünün yürütülmesini belirtir). Siteler Arası Komut Dosyası saldırı senaryosuna oldukça benzer. Saldırgan, CSRF işlevini gerçekleştiren kötü amaçlı URL (veya kötü amaçlı bir html formu) ile birlikte, zararlı bir sunucuya (saldırgan tarafından kontrol edilen) kasıtlı olarak yüklenen bazı örnek görüntüleri içeren bir Html etkin e-posta istemcisine bir e-posta gönderir. , kullanıcı e-postayı açıp görüntüleri indirene veya e-postasını kurban kullanıcı e-postasını okuduğunda bir bildirim alacak şekilde ayarlamasını bekler. Kötü niyetli görüntü sunucusunun kayıtlarını tutarken veya posta kutusundan okunan bir e-posta makbuzu almayı bekler. Görüntü indirildikten veya okundu bilgisi alındıktan sonra, kötü amaçlı işlevin yürütüldüğünü doğrulamaya çalışır. Başka bir senaryo, kullanıcının web sitesi ile ne zaman etkileşime girdiğini hesaplamak ve kötü amaçlı URL / Html formunu göndermeden önce saldırı zamanlarını hesaplamak olacaktır.

Yukarıdaki şemada, CSRF’nin (daha önce açıklanan savunmasız bağlantı anlamına gelir) HTML etkin bir e-postaya enjekte edilebileceği ve meşru bir kullanıcı tarafından yürütülebileceği açıklanmaktadır. Şimdi, eğer bağlantı (veya CSRF tarafından korunmasız bağlantı) Web Uygulaması oturumuna (olması gereken) bağlanırsa, mağdur kullanıcının saldırının başarılı olması için savunmasız Web Uygulamasına giriş yapmış olması gerekir . Bağlantı, Web Uygulaması oturumuna bağlanmazsa, bu bir CSRF güvenlik açığı değildir, Güvenli Olmayan Bir Doğrudan Nesne Başvuruları güvenlik açığı veya OWASP’nin ilk 10 çizelgesi tarafından açıklanan URL Erişimini Kısıtlama Başarısızlığıdır. Her iki güvenlik açığının uygunsuz erişim kontrolü ile ilgisi var.

Artık bir CSRF saldırısının ne olduğunu daha iyi anladınız ve daha teknik olabilir ve bir CSRF saldırısının http isteklerini kullanarak nasıl göründüğünü açıklayabilirim. Bu yüzden yine yukarıda açıklanan bağlantı şöyle bir Http isteği gibi görünüyor:

Tıklatıldığında güvenlik açığı bulunan bağlantı yukarıda gösterilen GET isteğini oluşturur ve başarılı olursa işlemin başarıyla tamamlandığını bildiren bir 200 Http yanıt mesajı oluşturur.

Siz CSRF olayını anladınız ama biz Az biraz daha inceleyelim;

Aşağıdaki şemada bir CSRF’nin nasıl kullanılabileceği ayrıntılı bir şekilde gösterilmektedir:

Şimdi adım adım olanları açıklayalım.

İlk adım: Hacker abimiz ilk olarak zararlı e-posta’yı yolluyor. Yada şöyle senaryo kuralım. Şimdi bu hacker abimiz bir banka sitesinde CSRF bulsun. Sonra bu bankanın müşterilerinden gariban Victim amcamıza ödül kazandınız diye CSRF zafiyetini kullanabilceği bir e-posta yollasın. Gariban Victim amcamızda gelen e-posta da ödül kazandınız mesajını görünce linke tıklasın. Gariban Victim amcamızın tarayıcısı zararlı websiteye gitsin. Ve bu sahte istek alt tarafta CSRF zafiyeti olan site ile kullanılsın. Neyse şimdi senaryo dan gerçeğe uyarlayalım

Gerçek dünyadaki bir benzetme şöyle olurdu: Hacker abimiz Victim amcamıza bir banka çeki sundu ve Victim amca ismini ve imzasını attı, ancak çek’e ne kadar para yazıldığını incelemedi gibi…

Durun daha bitmedi olayı biraz daha genişletelim…

Bir CSRF sorunu şu durumlarda ortaya çıkar:

1. Bir Web Uygulaması, GET Http isteklerini kullanarak kritik işlevleri yerine getirir (örneğin, para aktarmak, yalnızca bir bağlantıyı tıklatarak kullanıcı eklemek vb.).
2. POST ve GET isteklerini birbirinden ayırmaz (örneğin, bir Html formu kolayca bir GET isteğine dönüştürülebilir, yani bir Html POST isteğinin bir bağlantıya dönüştürülebileceği anlamına gelir).
3. Siteler Arası Komut Dosyası Oluşturma (örneğin birisi XMLHTTP nesnesini bir otomatik gönderme komut dosyasıyla birlikte kullanarak bir geçerli Html POST formu oluşturmak için JavaScript kullanabilir) için açıktır.
4. Uygulama, oturumu AntiCSRF belirteci ile birlikte URL’ye aktarıyor.
5. Oturum sabitlenebilir ve AntiCSRF belirteci öngörülebilir veya statiktir.

CSRF’de POST isteği GET’e çevirme ya da Tam Tersi;

Web Uygulaması POST ve GET istekleri arasında ayrım yapmadığında bir saldırganın bir POST Http isteğini bir GET Http isteğine dönüştürebildiği ve daha önce tarif edilene eşdeğer bir bağlantı oluşturabildiği yaygın bir bilgidir. Burp Suite bunu otomatik olarak proxy sekmesinden isteği sağ tıklatarak ve bir değişiklik yöntemi yaparak yapar (içerik boyutu alanındaki Http isteği boyutunu da yeniden hesaplar). Az önce açıklanan saldırı, bunun gibi bir otomatik gönderme komut dosyası kullanılarak geliştirilebilir:

“JavaScript”> setTimeout (‘document.CSRFHtmlForm.submit ()’, 5000);

Çok kullanışlı bir araç, Burp Suite’de de bulunan CSRF PoC aracıdır. Burp Suit CSRF PoC sizin için hızlı bir CSRF PoC üretecektir (çoğu zaman bunu gerçekçi olması için değiştirmeniz gerekecektir).

CSRF ve Cross Site Scripting (XSS)(Şu meşhur olanı )

Siteler Arası Komut Dosyası Yazma (XSS) saldırıları, kötü niyetli komut dosyalarının aksi takdirde iyi huylu ve güvenilir web sitelerine enjekte edildiği bir tür enjeksiyon sorunudur. Siteler arası komut dosyası çalıştırma (XSS) saldırıları, bir saldırgan, genellikle bir tarayıcı tarafı komut dosyası biçimindeki kötü amaçlı kodları farklı bir son kullanıcıya göndermek için bir web uygulaması kullandığında ortaya çıkar. Bu saldırıların başarılı olmasına izin veren kusurlar oldukça yaygındır ve bir web uygulamasının bir kullanıcıdan gelen ve çıktıyı doğrulamadan veya kodlamadan ürettiği girdiyi kullandığı her yerde ortaya çıkar.
Saldırgan, şüphesiz bir kullanıcıya kötü amaçlı bir komut dosyası göndermek için XSS kullanabilir. Son kullanıcının tarayıcısının, betiğin güvenilir olmaması gerektiğini bilmesi için bir yolu yoktur ve komut dosyasını yürütecektir. Komut dosyasının güvenilir bir kaynaktan geldiğini düşündüğünden, kötü amaçlı komut dosyası tarayıcınız tarafından tutulan ve bu siteyle birlikte kullanılan çerezlere, oturum simgelerine veya diğer hassas bilgilere erişebilir. Bu komut dosyaları bile HTML sayfasının içeriğini yeniden yazabilir. Ancak kötü amaçlı CSRF’yi yürütmek için otomatik gönderme komut dosyasıyla bir Html formu da enjekte edebilir. Bu olay anlaşılır olduğu için örnek vermeyecem.

Bir XSS güvenlik açığının CSRF aracı bölümündeki bir CSRF saldırısıyla nasıl birleştirilebileceğini görebilirsiniz (örneğin, CSRF ile birlikte otomatik gönderme javascript kodunu da enjekte ederek). Elbette, bir XSS, XMLHTTP ve otomatik gönderme javascript özelliklerini kullanarak bir CSRF saldırısı ile birleştirilebilir. Çok iyi bir XSS (XMLHTTP) / CSRF örneği burada bulunabilir . Belirli bir gönderi, gmail’de bulunan bir XSS / CSRF hatasını açıklıyor.

CSRF Session Fixation(Oturum Tespit Etme)

Oturum Tespiti, bir saldırganın geçerli bir kullanıcı oturumunu ele geçirmesine izin veren bir saldırıdır. Saldırı, web uygulamasının oturum kimliğini, özellikle de savunmasız web uygulamasını yönetme biçiminde bir sınırlama araştırıyor. Bir kullanıcının kimliğini doğrularken, yeni bir oturum kimliği atamaz, bu da mevcut bir oturum kimliğinin kullanılmasını mümkün kılar. Saldırı, bir kullanıcının bilinen bir oturum kimliği ile kimliğini doğrulaması için uyarılmasından ve daha sonra kullanılan oturum kimliği bilgisiyle kullanıcı tarafından onaylanan oturumun ele geçirilmesinden ibarettir. Saldırganın meşru bir Web uygulaması oturum kimliği sağlaması ve mağdurun tarayıcısını kullanmasını sağlaması gerekir.

Oturum sabitleme saldırısı, kullanıcı oturum açtıktan sonra müşteri ile Web Sunucusu arasında kurulan oturumu çalan bir Oturum Hijacking sınıfıdır. Bunun yerine, Oturum Düzeltme saldırısı kurbanın tarayıcısında kurulan oturumu düzeltir, böylece saldırı kurbandan önce başlar. kullanıcı oturum açar. Saldırıyı yürütmek için birkaç teknik vardır; Web uygulamasının oturum belirteçleriyle nasıl ilgilendiğine bağlıdır. Aşağıda en yaygın tekniklerden bazıları şunlardır:

• URL argümanında Oturum simgesi: Oturum Kimliği, mağdurlara köprüde gönderilir ve mağdur siteye kötü amaçlı URL üzerinden erişir.
• Gizli form alanındaki oturum simgesi: Bu yöntemde, saldırgan için geliştirilen bir oturum açma formu kullanılarak, mağdurun hedef Web Sunucusunda kimlik doğrulaması yapması için kandırılması gerekir. Form kötü web sunucusunda veya doğrudan html formatlı e-postada barındırılabilir.
• Bir çerezde oturum kimliği:
  • Müşteri tarafı komut dosyası:
    • Çoğu tarayıcı, istemci tarafı komut dosyasının yürütülmesini destekler. Bu durumda, saldırgan, mağdurlara gönderilen köprüye kötü niyetli bir kod eklemek ve çerezinde bir Oturum Kimliği düzeltmek için XSS (Siteler arası komut dosyası) saldırısı olarak kod enjeksiyon saldırılarını kullanabilir. Document.cookie işlevini kullanarak, komutu çalıştıran tarayıcı, istemci ile Web Uygulaması arasında bir oturumu sürdürmek için kullanacağı çerezin içindeki değerleri sabitleme yeteneğine sahip olur
  ** etiketi:**
  • etiketi aynı zamanda bir kod enjeksiyon saldırısı olarak da kabul edilir, ancak istenmeyen komut dosyalarının devre dışı bırakılabileceği veya yürütmenin reddedilebileceği XSS saldırısından farklı olarak kabul edilir. Bu yöntemi kullanan saldırı çok daha etkili olur çünkü bu etiketlerin tarayıcılarda işlenmesini devre dışı bırakmak imkansızdır.

CSRF ve Clickjacking

Şimdi bu olayı uzun uzun anlatmayacam. Zaten bir çoğunuz Clickjacking olayını biliyorsunuz. Ama örnek vereyim.

Örneğin, üzerinde “ücretsiz bir iPod için buraya tıkla” yazan bir düğme içeren bir web sitesi oluşturan bir saldırgan olduğunu hayal edin. Ancak, bu web sayfasının en üstünde, saldırgan savunmasız e-bankacılık hesabınıza bir iframe yerleştirmiş ve doğrudan “ücretsiz iPod” düğmesinin üstüne “para transferi” düğmesini yerleştirmiştir. Kurban “ücretsiz iPod” düğmesini tıklamaya çalışıyor ama bunun yerine görünmez “para transferi” düğmesini tıklıyor. Sonuç olarak CSRF+Clickjacking olayı gerçekleşiyor.

CSRF olayında anlatacaklarım bu kadar. Biraz sizi sıkmış olabilirim. Ya da anlatırken eksik kaldığım yerler olmuş olabilir. Kusurumuz da olmuşsa hepsi için AFFOLA… Başka bir yazıda görüşmek üzere…

 

[ozanpy]

Merhabalar dün bir sitede csrf ararken. Csrf HTML formunu aldım.başka bir tarayıcıda başka bir hesapta çalışıyordım. Yeni.bilgiler kurban olan hesaptaki inputlara geldi. Ama aşağıda bir adet daha save butonu var. Ona basmadan kayıt edilmeyecek. Kurbanı o butona basmaya itersem csrf başarılı olacak. Bunun bir yolu var mı? Veya açıktan sayılır mı? Save butonuna bassa kusursuz bis csrf açığı Mevcut.

 

[payitaht]

<script>
var http = new XMLHttpRequest();
var url = 'https://example.com/';
var params = 'params=value';
http.open('POST', url, true);
http.withCredentials = true;
http.setRequestHeader('Content-type', 'application/x-www-form-urlencoded');

http.send(params);
</script>

bu sekilde de halledebilirsin. butonsuz hali

 

[ozanpy]

Tam olarak ne işe yaradığını açıklayabilir misin ne yapar bu? Bir de değiştirmem gereken alanlar nedir?

 

[payitaht]

aslında yukarı tam olarak ne dedigini anlayamadım ama;

bu kodlar butona basmadan hedef siteye otomatik istek göndermeni sağlıyor.

var url = 'https://example.com/';
bu kısma csrf zafiyetine sahip urlyi gireceksin
var params = 'params=value';
buraya da parametreleri ve degerlerini gireceksin