Selamlar bendeniz Rapx13 bugün sizler ile uzun zamandır okuduğum CSRF açığının sanırım 5. bölümünü yazmaktayım.
iyi okumalar dilerim efendim.
dinlediğim şarkı:
güzel şarkı biz konuya geçelim
)
Samesite Cookie Bypass
genel olarak üstünden bir bakarsak bu CSRF ve bazı diğer açıklardan korunmak için var yani size açık değil açığın hem savunmasını hem de savunulan açığı aşmayı anlatıyorum şuanda.
Nedir peki bu zımbırtı hemen anlatıyım.
Siteler arası isteklerle birlikte ne zaman gönderildiklerini kontrol etmek için tasarlanmış özel bir özelliğe sahip bu bypass Samesite tanımlama bilgisi özelliğinin uygulanması çıkış noktaları arası veri sızıntılarına, CSRF'ye ve XSS saldırılarına karşı güvenilir bir korumadır. İsteğin bağlamına bağlı olarak, tarayıcıya çerezi ne zaman ileteceğini söyler.
olası türleri nedir ?
Strict
Lax
None
bu üç arkadaşı ele alalım bunlar nedir ?
LAX: Lax SameSite çerezleri dost canlısı bir komşu gibi. Tanımlama bilgilerinin üst düzey gezinmelerde ve GET, HEAD ve OPTIONS gibi güvenli HTTP yöntemlerinde gönderilmesine izin vererek orta düzeyde koruma sağlarlar. Bu tanımlama bilgilerinin çapraz kaynaklı POST istekleriyle gönderilmeyeceği anlamına gelir ve belirli CSRF saldırı türlerinin azaltılmasına yardımcı olur. Bununla birlikte, çerezler yine de harici web siteleri tarafından başlatılan GET isteklerine dahil edilir ve bu da hassas bilgilerin çerezlerde saklanması durumunda güvenlik riski oluşturabilir.
STRICT: Strict SameSite çerezleri, uyanık korumalar olarak hareket eder. Çerezlerin yalnızca birinci taraf bağlamında gönderilmesini kısıtlayarak en yüksek düzeyde koruma sunarlar. Bu, çerezlerin yalnızca çerezi ayarlayan aynı siteden gelen isteklerle gönderildiği ve siteler arası istek sahteciliği saldırılarını etkili bir şekilde önlediği anlamına gelir. Strict samesite tanımlama bilgileri, farklı kaynaklar arasında sıkı bir yalıtım uygulayarak, özellikle hassas kullanıcı verilerinin söz konusu olduğu senaryolarda web uygulamalarının güvenliğini önemli ölçüde artırır.
NONE : Yok SameSite çerezleri, kaygısız bedeviler gibi davranır. Hem birinci taraf hem de siteler arası isteklerle gönderilirler, bu da onları tanımlama bilgilerinin farklı kaynaklardan erişilebilir olması gereken senaryolar için uygun hale getirir. Ancak, siteler arası isteklerle ilişkili olası güvenlik risklerini önlemek için, istek HTTPS üzerinden yapılırsa None SameSite tanımlama bilgileri, Secure özniteliğini gerektirir. Bu, çerezlerin yalnızca güvenli bağlantılar üzerinden iletilmesini sağlayarak, aktarım sırasında kötü niyetli aktörler tarafından ele geçirilme veya kurcalanma olasılığını azaltır.
gelin sizlerle bi LAX örneği inceleyelim.
az çok okuma yazmanız varsa anlamışsınızdır ne olduğunu anlamayanlar alınmasın anlatıyorum xd uygulama kısmında bir logout bölümü var ve yanındada kod var sansürlü onu girersek bizi oturumdan atıcak.
önceki bölümlerde joshu avlamıştık şimdi onu oturumdan atıp hesabına çökeceğiz yani
<?php $cookieNames = array_keys($_COOKIE); if($_COOKIE["logout"] == "xxxxxxx"){ // Loop through each cookie and delete it foreach ($cookieNames as $cookieName) { // If it's desired to kill the session, also delete the session cookie. session_destroy(); .. ... } |
buda oturumdan attığını gösteren sunucu tarafı kodu.
Komut dosyası bir tanımlama bilgisi değeri gerektirir, ancak bu tamamen SameSite değerinin türüne bağlıdır. Tür Lax olduğundan, üst düzey gezinti ve GET istekleri dışındaki siteler arası isteklere iletilmez.
Saldırgan, Josh'u banka hesabından çıkarmak için ona başka bir e-posta gönderebilir, banka temsilcisi kılığına girebilir ve onu bir ödül kazanmak için bir ankete katılmaya ikna edebilir.
<a href="https://mybank.thm:8080/logout.php" target="_blank">Survey Link!</a>
josh'a bunu gönderdik survey the link dediği anda onu sayfanın logout.php sayfasına atıcaktır çünkü çerez Lax olarak ayarlı eğer Strict olsaydı siteler arası çerez iletilmez ve bu saldırı önlenebilirdi artık josh hesabına erişemez çünkü şifreyi daha önce değiştirmiştik ve artık oturumdan da attık
POST Senaryosu ile Gevşek - İstismarı Zincirleme
Web sitesi tarafından ayarlanan çerezleri kontrol etmek önemlidir. Son örnekte ayarlanan çerez Lax olduğundan, herhangi bir kullanıcının oturumunu kapatmak mümkün oldu. Ancak yukarıdaki senaryo yalnızca GET istekleri ile mümkündür ve POST istekleri durumunda hiçbir şey yapılamaz.
Başlangıçta, siteler arası isteklerde çerezlerin gönderilme şeklini kısıtlayarak web güvenliğini artırmak için SameSite özniteliği kullanıma sunulduğunda, Google Chrome ve diğer tarayıcılar, belirtilen bir SameSite özniteliği olmadan çerezler için varsayılan bir davranış uygulamadı. Bu, geliştiricilerin, çerezlerin iframe'ler veya üçüncü taraf içeriği gibi siteler arası isteklerde gönderilmesine izin verecek şekilde açıkça ayarlaması gerektiği anlamına geliyordu. Ancak Chrome, güvenliği ve gizliliği daha da geliştirmek ve CSRF saldırılarına karşı daha iyi koruma sağlamak için varsayılan davranışını değiştirdi. Bir çerez için bir SameSite özelliği belirtilmezse, Chrome bunu otomatik olarak . Bu varsayılan ayar, tanımlama bilgilerinin birinci taraf bağlamında ve üst düzey gezinme GET istekleriyle gönderilmesine izin verir, ancak üçüncü taraf veya siteler arası isteklerde gönderilmez, böylece kullanılabilirliği artırılmış güvenlik önlemleriyle dengeler.
Peki ya bir POST isteğinde bulunmak istersek? Bir şey yapabilir miyiz? cevap kesinlikle evet. Chrome'un resmi belgelerine göre hemde
"Chrome, 2 dakikadandaha kısa bir süre önce SameSite özelliği olmadan ayarlanan çerezler için bir istisna yapacaktır. Bu tür çerezler, üst düzey siteler arası isteklerin güvenli (örneğin GET) bir HTTP yöntemine sahip olmasını gerektiren normal SameSite=Lax çerezlerine rağmen, bir kez etkili olmayan (ör. POST) üst düzey siteler arası isteklerle de gönderilecektir."
şimdi size bi kod vereceğim bu kodu inceleyin
Komut dosyası bir tanımlama bilgisi değeri gerektirir, ancak bu tamamen SameSite değerinin türüne bağlıdır. Tür Lax olduğundan, üst düzey gezinti ve GET istekleri dışındaki siteler arası isteklere iletilmez.
Saldırgan, Josh'u banka hesabından çıkarmak için ona başka bir e-posta gönderebilir, banka temsilcisi kılığına girebilir ve onu bir ödül kazanmak için bir ankete katılmaya ikna edebilir.
<a href="https://mybank.thm:8080/logout.php" target="_blank">Survey Link!</a>
josh'a bunu gönderdik survey the link dediği anda onu sayfanın logout.php sayfasına atıcaktır çünkü çerez Lax olarak ayarlı eğer Strict olsaydı siteler arası çerez iletilmez ve bu saldırı önlenebilirdi artık josh hesabına erişemez çünkü şifreyi daha önce değiştirmiştik ve artık oturumdan da attık
POST Senaryosu ile Gevşek - İstismarı Zincirleme
Web sitesi tarafından ayarlanan çerezleri kontrol etmek önemlidir. Son örnekte ayarlanan çerez Lax olduğundan, herhangi bir kullanıcının oturumunu kapatmak mümkün oldu. Ancak yukarıdaki senaryo yalnızca GET istekleri ile mümkündür ve POST istekleri durumunda hiçbir şey yapılamaz.
Başlangıçta, siteler arası isteklerde çerezlerin gönderilme şeklini kısıtlayarak web güvenliğini artırmak için SameSite özniteliği kullanıma sunulduğunda, Google Chrome ve diğer tarayıcılar, belirtilen bir SameSite özniteliği olmadan çerezler için varsayılan bir davranış uygulamadı. Bu, geliştiricilerin, çerezlerin iframe'ler veya üçüncü taraf içeriği gibi siteler arası isteklerde gönderilmesine izin verecek şekilde açıkça ayarlaması gerektiği anlamına geliyordu. Ancak Chrome, güvenliği ve gizliliği daha da geliştirmek ve CSRF saldırılarına karşı daha iyi koruma sağlamak için varsayılan davranışını değiştirdi. Bir çerez için bir SameSite özelliği belirtilmezse, Chrome bunu otomatik olarak . Bu varsayılan ayar, tanımlama bilgilerinin birinci taraf bağlamında ve üst düzey gezinme GET istekleriyle gönderilmesine izin verir, ancak üçüncü taraf veya siteler arası isteklerde gönderilmez, böylece kullanılabilirliği artırılmış güvenlik önlemleriyle dengeler.
Peki ya bir POST isteğinde bulunmak istersek? Bir şey yapabilir miyiz? cevap kesinlikle evet. Chrome'un resmi belgelerine göre hemde
"Chrome, 2 dakikadandaha kısa bir süre önce SameSite özelliği olmadan ayarlanan çerezler için bir istisna yapacaktır. Bu tür çerezler, üst düzey siteler arası isteklerin güvenli (örneğin GET) bir HTTP yöntemine sahip olmasını gerektiren normal SameSite=Lax çerezlerine rağmen, bir kez etkili olmayan (ör. POST) üst düzey siteler arası isteklerle de gönderilecektir."
şimdi size bi kod vereceğim bu kodu inceleyin
| if (!isset($_COOKIE['isBanned'])) { echo('<script>alert("isBanned cookie not found in request");</script>'); exit(); } if (isset($_POST['isBanned'])) { $status=$_POST['isBanned']; echo('<script>document.cookie="isBanned='.$status.'";</script>'); } |
Kodu inceledikten sonra, giriş yaptıktan sonra ayarlanan bir çerez olduğunu görebiliriz. Çerezin değeri, kullanıcının yasaklanıp yasaklanmadığını belirler ve yasaklanmışsa ona bir mesaj görüntüler. Amacımız, kullanıcı kötü amaçlı bağlantıya tıkladığında çerezin değerini değiştirmektir. isbanned yazıyor bak orda değer o işte
adamı bir nevi banlıyıcağız
Bir parametreyi kabul eden ve çerezin değerini ayarlayan bir POST API çağrısı vardır. Ancak, sunucu tarafı komut dosyası, çerezin (isBanned) herhangi bir CSRF saldırısından kaçınmasını bekler.
Sayfaya siteler arası bir istek varsa, isteğimizde bir çerez olmayacağından, çerezi doğrudan oluşturmak için komut dosyasını çalıştıramayız
Bunu deneyelim. Kullanıcı adı ve şifreyi kullanarak banka uygulamasına tekrar giriş yapın. Giriş yaptığımızda, komut dosyası çerezin değerini güncelleyecektir, bu yüzden burada 2 dakika beklememiz gerekiyor, aksi takdirde 2 dakikalık pencereye kadar iletilecektir
konu bitti ee emre 2 haftadır ne yapıyon eşşek dersiniz valla şu küçücük yazı için 2 haftadır ctf çözüyorum size doğru bilgiler vermek için.
neyse anlıyıcağınız o hacker filmlerindeki gibi değil 2 dakikanız var öyle son anda yetişme gibi bir durum olmaz valla iyi tutturun vakti
özlü sözüm : VAKİT NAKİTTİR
bu sözü unutmayın geleceğiniz için çalışın
hadi iyi günler, iyi forumlar
Rapx Out
adamı bir nevi banlıyıcağız
Bir parametreyi kabul eden ve çerezin değerini ayarlayan bir POST API çağrısı vardır. Ancak, sunucu tarafı komut dosyası, çerezin (isBanned) herhangi bir CSRF saldırısından kaçınmasını bekler.
Sayfaya siteler arası bir istek varsa, isteğimizde bir çerez olmayacağından, çerezi doğrudan oluşturmak için komut dosyasını çalıştıramayız
Bunu deneyelim. Kullanıcı adı ve şifreyi kullanarak banka uygulamasına tekrar giriş yapın. Giriş yaptığımızda, komut dosyası çerezin değerini güncelleyecektir, bu yüzden burada 2 dakika beklememiz gerekiyor, aksi takdirde 2 dakikalık pencereye kadar iletilecektir
konu bitti ee emre 2 haftadır ne yapıyon eşşek dersiniz valla şu küçücük yazı için 2 haftadır ctf çözüyorum size doğru bilgiler vermek için.
neyse anlıyıcağınız o hacker filmlerindeki gibi değil 2 dakikanız var öyle son anda yetişme gibi bir durum olmaz valla iyi tutturun vakti
özlü sözüm : VAKİT NAKİTTİR
bu sözü unutmayın geleceğiniz için çalışın
hadi iyi günler, iyi forumlar
Rapx Out
Elinize sağlık hocam
