breakpoint
Team Member
- Katılım
- 12 Nis 2024
- Mesajlar
- 6
- Tepkime puanı
- 14
- Puanları
- 3
Herkese merhaba! Bu yazımızda SameSite kısıtlamalarından bahsedeceğiz ve bu kısıtlamaları atlatabileceğimiz birtakım yöntemleri inceleyeceğiz. Öncelikle SameSite nedir?
SameSite, 2016 yılında siteler arası isteklerde çerez gönderiminin kontrolünü sağlamak için tanımlanmıştır(RFC 6265bis).
None, Lax ve Strict olarak üç farklı değer alabilir.
None: Siteler arası herhangi bir istekte bu kuralın set edildiği çerezlerin gönderimine izin verilir. Güvenlik önlemi olarak Secure kuralının de beraberinde olması gerekir, aksi halde tarayıcı bu çerezi kabul etmeyecektir. Önemli bir veri barındırmayan çerezler genellikle bu kategoridedir.
Örnek: Reklam için kullanılan izleme çerezleri.
Lax: Siteler arasında bu kuralın set edildiği çerezlerin gönderilebilmesi için iki koşul vardır.
Strict: Siteler arası isteklerde bu kuralın set edildiği çerezlerin gönderilmesine izin verilmez.
Peki SameSite'daki Site kavramı nedir? İki sitenin aynı olduğunu belirleyen unsur URL şeması(scheme) ve Kök Alan Adıdır(Root Domain).
Gelin ilk örneğimizi inceleyelim.
1. Lax kısıtlamasını atlatmak
Bu örneğimizde metot kontrolünü geçersiz kılmaya çalışacağız. Lab'da kullanılan tarayıcının Chrome olduğunu belirtelim. Lab'a buradan erişebilirsiniz. Kullanıcı bilgilerimizle giriş yapalım ve Burp aracında takip edelim.
Giriş yaptığımızda herhangi bir SameSite çerezi tanımlanmadığını görüyoruz. Bu durumda varsayılan olarak Lax kuralı set edilmiş oluyor. Kullanıcının e-posta adresini değiştirelim.
Burp'te ilgili isteği takip ettiğimizde herhangi bir CSRF token tanımlanmadığını gözlemledik. Lax özelliğinin set edildiğini göz önünde bulundurarak e-posta adresini GET metoduyla değiştirmeyi deneyelim.
GET isteğine izin verilmiyor. Ancak bazı frameworklerde, örneğin Symfony'de istek metodunu "_method" parametresi ile güncelleyebiliyoruz.
Bu aşamada uygulama'da kullanılan frameworkleri tespit etmemiz büyük önem taşıyor. Framework'e bağlı olarak bu parametre değişiklik gösterebilir.
Metot kontrolünü atlatmak için bazı muhtemel parametreleri buradan inceleyebilirsiniz. Biz örneğimize devam edelim.
İlgili parametreyi eklediğimizde isteğin başarılı bir şekilde gerçekleştiğini görüyoruz. O halde exploit sunucumuzda da test edelim.
Aşağıdaki gibi bir script bu örneğimizde yeterli olacaktır. Kullanıcı bu sayfaya giriş yaptığında top-level navigation sağlanmış olacak,
çünkü tanımladığımız url'ye yönlendirilecek.
Exploit'i kurbana gönderdiğimizde e-posta adresi değişmiş olur ve lab da bu şekilde çözülmüş olur. Farklı bir örneğe geçelim.
2. Strict Kuralını Atlatmak
Strict kuralını hatırlayacak olursak bu özelliğe sahip çerezler yalnızca aynı sitedeyken gönderilir. Bu nedenle önceki örneğimizdeki gibi doğrudan e-posta adresini değiştirmek mümkün değildir. Öncelikle kullanıcı bilgilerimizi girelim ve Burp'te takip edelim.
Giriş yaptığımızda oturum çerezinde Strict kuralının set edildiğini görüyoruz. Bu nedenle biz önceki örnekteki gibi bir yönlendirme yaptığımızda oturum çerezi gönderilmeyecektir. E-posta adresimizi değiştirelim.
CSRF token tanımlanmadığını tespit ediyoruz. İstek metodunu değiştirmeyi deniyoruz. İsteği Repeater'a gönderiyoruz ve sağ tıklayıp Change request method ile metodu güncelleyip isteği tekrar gönderiyoruz.
GET metodunun da kabul edildiğini gözlemledik. İstek başarılı bir şekilde gerçekleşiyor. Peki biz oturum çerezi ile birlikte CSRF atağını nasıl hazırlayabiliriz? Bunun için siteyi daha ayrıntılı incelemekte fayda var.
Bir blog sitesiyle karşılaşıyoruz. Gönderileri daha ayrıntılı incelemek için View Post'a tıklıyorum.
Gönderilere yorum yapılabildiğini keşfediyoruz. İlgili alanları doldurup bir yorum yazalım ve sonrasında neler olduğunu inceleyelim. Bu istekleri Burp'te de takip etmemiz önemli.
Yorumu yaptıktan sonra bir yönlendirme yapıldığını görüyoruz. Bu yönlendirmeyi yaparken özel bir Javascript fonksiyonu kullanılmış. İlgili Javascript kodunu inceleyelim.
3 saniye bekledikten sonra ilgili fonksiyon çağırılıyor ve /post/postId adresine yönlendiriliyor. Burada postId, bir önceki isteğimizdeki parametre oluyor. O halde postId değerini manipüle ederek Path Traversal yapabilirsek site içerisinde istediğimiz sayfaya istek gönderebiliriz. Bir önceki isteğimizi Repeater'a gönderelim ve hesap sayfamıza erişmek için postId değerini "../my-account" olarak güncelleyelim. Burada bir üst dizine çıkıyoruz çünkü halihazırda /post dizini altındaydık.
postId değerimizi güncelledik ve hesap sayfamıza erişebildik. Bu aşamada Strict kuralının hiçbir anlamı kalmıyor, çünkü site içerisinde ikinci bir isteği de gerçekleştirebiliyoruz. İkinci istek aynı site içerisinde olduğundan oturum çerezi de set edilmiş oluyor. O halde exploit sunucumuza gidelim ve payload yazalım.
GET metoduyla e-posta adresimizi değiştirebiliyorduk ve bunu kullandık. Exploit'i kullanıcıya gönderiyoruz ve bu lab da çözülmüş oluyor. Burada "submit" parametresini de belirtebilmek için "&" sembolünü kullanıyoruz fakat url encoded olarak göndermekte fayda var. Bu şekilde sitedeki redirect özelliğini kullanarak ikinci isteği gerçekleştirebiliyoruz ve böylece Strict kuralını atlatabiliyoruz.
Okuduğunuz için teşekkürler, bir sonraki yazımızda görüşmek üzere!
SameSite, 2016 yılında siteler arası isteklerde çerez gönderiminin kontrolünü sağlamak için tanımlanmıştır(RFC 6265bis).
None, Lax ve Strict olarak üç farklı değer alabilir.
None: Siteler arası herhangi bir istekte bu kuralın set edildiği çerezlerin gönderimine izin verilir. Güvenlik önlemi olarak Secure kuralının de beraberinde olması gerekir, aksi halde tarayıcı bu çerezi kabul etmeyecektir. Önemli bir veri barındırmayan çerezler genellikle bu kategoridedir.
Örnek: Reklam için kullanılan izleme çerezleri.
Lax: Siteler arasında bu kuralın set edildiği çerezlerin gönderilebilmesi için iki koşul vardır.
- Güvenli istek metotları kullanılmalıdır. GET ve HEAD metotları fonksiyonları sebebiyle "güvenli" olarak kabul edilen metotlardır(RFC 2616).
- Top-level navigation sağlanmalıdır. Yani tarayıcıdaki mevcut URL'nin değişmesi gerekmektedir. Örneğin site1.com, site2.com'un içerisinde örneğin iframe'de bulunuyorsa bu çerez gönderilmeyecektir, çünkü top-level navigation sağlanmamıştır.
Strict: Siteler arası isteklerde bu kuralın set edildiği çerezlerin gönderilmesine izin verilmez.
Peki SameSite'daki Site kavramı nedir? İki sitenin aynı olduğunu belirleyen unsur URL şeması(scheme) ve Kök Alan Adıdır(Root Domain).
Gelin ilk örneğimizi inceleyelim.
1. Lax kısıtlamasını atlatmak
Bu örneğimizde metot kontrolünü geçersiz kılmaya çalışacağız. Lab'da kullanılan tarayıcının Chrome olduğunu belirtelim. Lab'a buradan erişebilirsiniz. Kullanıcı bilgilerimizle giriş yapalım ve Burp aracında takip edelim.
Giriş yaptığımızda herhangi bir SameSite çerezi tanımlanmadığını görüyoruz. Bu durumda varsayılan olarak Lax kuralı set edilmiş oluyor. Kullanıcının e-posta adresini değiştirelim.
Burp'te ilgili isteği takip ettiğimizde herhangi bir CSRF token tanımlanmadığını gözlemledik. Lax özelliğinin set edildiğini göz önünde bulundurarak e-posta adresini GET metoduyla değiştirmeyi deneyelim.
GET isteğine izin verilmiyor. Ancak bazı frameworklerde, örneğin Symfony'de istek metodunu "_method" parametresi ile güncelleyebiliyoruz.
Bu aşamada uygulama'da kullanılan frameworkleri tespit etmemiz büyük önem taşıyor. Framework'e bağlı olarak bu parametre değişiklik gösterebilir.
Metot kontrolünü atlatmak için bazı muhtemel parametreleri buradan inceleyebilirsiniz. Biz örneğimize devam edelim.
İlgili parametreyi eklediğimizde isteğin başarılı bir şekilde gerçekleştiğini görüyoruz. O halde exploit sunucumuzda da test edelim.
Aşağıdaki gibi bir script bu örneğimizde yeterli olacaktır. Kullanıcı bu sayfaya giriş yaptığında top-level navigation sağlanmış olacak,
çünkü tanımladığımız url'ye yönlendirilecek.
Kod:
<script>
document.location = 'https://{site}/my-account/change-email?email={email}%26_method=POST';
</script>Exploit'i kurbana gönderdiğimizde e-posta adresi değişmiş olur ve lab da bu şekilde çözülmüş olur. Farklı bir örneğe geçelim.
2. Strict Kuralını Atlatmak
Strict kuralını hatırlayacak olursak bu özelliğe sahip çerezler yalnızca aynı sitedeyken gönderilir. Bu nedenle önceki örneğimizdeki gibi doğrudan e-posta adresini değiştirmek mümkün değildir. Öncelikle kullanıcı bilgilerimizi girelim ve Burp'te takip edelim.
Giriş yaptığımızda oturum çerezinde Strict kuralının set edildiğini görüyoruz. Bu nedenle biz önceki örnekteki gibi bir yönlendirme yaptığımızda oturum çerezi gönderilmeyecektir. E-posta adresimizi değiştirelim.
CSRF token tanımlanmadığını tespit ediyoruz. İstek metodunu değiştirmeyi deniyoruz. İsteği Repeater'a gönderiyoruz ve sağ tıklayıp Change request method ile metodu güncelleyip isteği tekrar gönderiyoruz.
GET metodunun da kabul edildiğini gözlemledik. İstek başarılı bir şekilde gerçekleşiyor. Peki biz oturum çerezi ile birlikte CSRF atağını nasıl hazırlayabiliriz? Bunun için siteyi daha ayrıntılı incelemekte fayda var.
Bir blog sitesiyle karşılaşıyoruz. Gönderileri daha ayrıntılı incelemek için View Post'a tıklıyorum.
Gönderilere yorum yapılabildiğini keşfediyoruz. İlgili alanları doldurup bir yorum yazalım ve sonrasında neler olduğunu inceleyelim. Bu istekleri Burp'te de takip etmemiz önemli.
Yorumu yaptıktan sonra bir yönlendirme yapıldığını görüyoruz. Bu yönlendirmeyi yaparken özel bir Javascript fonksiyonu kullanılmış. İlgili Javascript kodunu inceleyelim.
3 saniye bekledikten sonra ilgili fonksiyon çağırılıyor ve /post/postId adresine yönlendiriliyor. Burada postId, bir önceki isteğimizdeki parametre oluyor. O halde postId değerini manipüle ederek Path Traversal yapabilirsek site içerisinde istediğimiz sayfaya istek gönderebiliriz. Bir önceki isteğimizi Repeater'a gönderelim ve hesap sayfamıza erişmek için postId değerini "../my-account" olarak güncelleyelim. Burada bir üst dizine çıkıyoruz çünkü halihazırda /post dizini altındaydık.
postId değerimizi güncelledik ve hesap sayfamıza erişebildik. Bu aşamada Strict kuralının hiçbir anlamı kalmıyor, çünkü site içerisinde ikinci bir isteği de gerçekleştirebiliyoruz. İkinci istek aynı site içerisinde olduğundan oturum çerezi de set edilmiş oluyor. O halde exploit sunucumuza gidelim ve payload yazalım.
Kod:
<script>
document.location = 'https://{site}/post/comment/confirmation?postId=../my-account/change-email?email={email}%26submit=1';
</script>GET metoduyla e-posta adresimizi değiştirebiliyorduk ve bunu kullandık. Exploit'i kullanıcıya gönderiyoruz ve bu lab da çözülmüş oluyor. Burada "submit" parametresini de belirtebilmek için "&" sembolünü kullanıyoruz fakat url encoded olarak göndermekte fayda var. Bu şekilde sitedeki redirect özelliğini kullanarak ikinci isteği gerçekleştirebiliyoruz ve böylece Strict kuralını atlatabiliyoruz.
Okuduğunuz için teşekkürler, bir sonraki yazımızda görüşmek üzere!
