Giriş Yap
Kayıt Ol
Üye Listesi
Aktif Konular
Arama Yap
() INF
CSRF, genel yapı olarak sitenin açığından faydalanarak siteye sanki o kullanıcıymış gibi erişerek işlem yapmasını sağlar. CSRF zafiyeti uygulamaya giden isteklerin hangi kaynaktan ve nasıl gönderildiği kontrol edilmeyen, genellikle de GET requestleri ve SESSION işlemlerinin doğru kontrol edilememesinden dolayı ortaya çıkan zafiyet türüdür. Bu zafiyetin oluşmasının nedeni kodlayan yazılımcıların gözünden kaçan ayrıntılarda saklıdır diyebiliriz. Ayrıyeten bu zafiyet “Session Riding” olarakta bilinmektedir.
Bu kadar tanımlamadan sonra gerçek hayattan örneklerle anlatıma devam etmek istiyorum böylece zihninizde daha iyi yer edineceğine eminim. Yazımın sonunda bu konuda size videolar önereceğim.
İlk örneğimiz hakkında kısaca bilgiler; ( Kaynak — Web Hacking 101 book)
Difficulty: Low
Url: https://app.shopify.com/services/partners/api_client/XXXX/export_installed_users
Report Link: https://hackerone.com/reports/96470
Bounty Paid: $500
Öncelikle yukarıdaki report link üzerinden kaynağa ulaşıp kendiniz de ayrıyeten inceleyebilirsiniz ben elimden geldiğince durumu aktaracağım. Yukarıdaki Url’de bir shopify API endpoint’i ile karşılaşıyoruz bize yüklü kullanıcıları export ediyor. Shopify buraya bir CSRF token validation koymadığı için bu bilgileri okuyabilmemize olanak sağlayacak bir zafiyete yol açıyor.
Bir HTML formu hazırlayıp onu xxx.com sitenize eklediğinizi farz edin. Ben aşağıdaki örnek üzerinden durumu aktaracağım.
Yukarıdaki kod kurbanın sadece siteyi ziyaret etmesinin yeterli olduğu, devamında kurbanın ( eğer varsa ) tarayıcısının cookie’sini shopifyden sağlamasıyla API’a bir GET methodu göndermesiyle tamamlanıyor. Eğer bu form ile kullanıcı cookiesinin nasıl alınıp onun adına request atıldığını tam kavrayamadıysanız cookie konusunu en aşağıda bıraktığım kanallardan dinleyebilir devamında tekrardan inceleyebilirsiniz. Ayrıca methodlarla alakalı bahsettiğimiz kısım da gözünüzden kaçmasın, yazılımcının endpointe CSRF validation eklememesinin başa açtığı sorunu görüyoruz.
Burada yukarıda bahsettiğim gibi kullanıcının izni ve haberi olmadan onun cookiesi ile request atılıp onun adına işlem dahi yapılabiliyor. Bunu engellemenin yolu elbette var bir örnek daha paylaşıp devamında ona değineceğim.
2. Shopify Twitter Disconnect
Difficulty: Low
Url: https://twitter-commerce.shopifyapps.com/auth/twitter/disconnect
Report Link: https://hackerone.com/reports/111216
Date Reported: January 17, 2016
Bounty Paid: $500
Shopify, mağaza sahiplerinin ürünleri hakkında tweet atmasına izin vermek için twitter ile entegrasyon sağlıyor. Haliyle mağaza hesabına bağlı twitter hesabının mağazadan bağlantısını kesmek için de bir seçenek bulunuyor.
Yukarıdaki URL’yi incelediğimizde shopify’in burada CSRF validation yapmadığını farkediyor ve bunun da csrf zafiyetine yol açabileceğini düşünüyoruz. Çünkü shopify burada gelen cookie’ye bakıyor ancak onun saldırgandan mı yoksa kurbanımızdan mı geldiğini bilmiyor. Saldırgan burada kurban adına GET isteği yapmasına izin vermeyecek hiçbir koruma yok. Ve tahmin edebileceğiniz üzere saldırgan burada başarılı bir şekilde kurbanın twitter bağlantısını kesebildi, hadi inceleyelim.
Ayrıca lütfen aşağıda güvenlik açığı bulunan URL’ye bir de img etiketinin kullanımına dikkat edin:
GET /auth/twitter/disconnect HTTP/1.1
Host: twitter-commerce.shopifyapps.com
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:43.0) Gecko/2010010 1 Firefox/43.0
Accept: text/html, application/xhtml+xml, application/xml
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: https://twitter-commerce.shopifyapps.com/account
Cookie: _twitter-commerce-session=REDACTED
>Connection: keep-alive
Tarayıcı, verilen URL’deki görüntüyü almak için bir GET isteği gerçekleştirdiğinden ve hiçbir CSRF belirteci doğrulanmadığından, kurbanın mağazasının bağlantısı kesiliyor. Bu isteği yapan html kod içeriğini inceleyelim:
Bir şey farkettiniz mi? Bir önceki saldırıda saldırgan body onload kullanmıştı ama bu sefer karşımıza img tagı çıkıyor. Bir siteye girdiğinizde sitede bulunan image içerikleri otomatik olarak dahil edilir ve otomatik olarak çalışır.
Ayrıca burada shopify yazılımcısının hatasından bahsedelim, böyle bir isteğin GET ile gönderilmemesi gerekli! GET methodu bir sunucudaki veriyi asla değiştirmemelidir bunun için duruma özel POST, PUT, DELETE methodları özenle tercih edilmelidir.
3. Badoo Full Account Takeover
Difficulty: Medium
Url: https://badoo.com
Report Link: https://hackerone.com/reports/127703
Date Reported: Arpil 1, 2016
Bounty Paid: $852
Badoo’ya ilk göz attığımızda bizi giriş yapma ekranı karşılıyor her şey burada başlıyor. Bir kullanıcı gmail ile hesap oluşturmaya çalıştığında ve badoo’ya gmail hesabını kullanması için yetki verdikten sonra,
https://eu1.badoo.com/google/verify.phtml?rt=
adresine yönlendiriliyor. CSRF’ten koruyan tek şey her kullanıcıya unique olarak atanan “rt” parametresi. Saldırgan bunu incelerken neredeyse tüm json yanıtlarının rt parametresini döndürdüğünü farkediyor ve üzerine gidiyor. Bir süre üzerine uğraşıp denemeler yaptıktan sonra aşağıdaki gibi bir bağlantıyı keşfediyor.
https://eu1.badoo.com/worker-scope/chrome-service-worker.js
ve saldırgan bu adresin de rt parametresi taşıdığını farkediyor. Daha da iyisi bu json dosyası, kurbanın kötü amaçlı bir websitesine gitmesine gerek olmadan ( yukarıdaki örnekler gibi ) saldırgan tarafından keyfi olarak okunabilir. İşte saldırganın paylaştığı html kodu:
http://a
Esasen bir kurban bu sayfayı yüklediğinde Badoo scriptini çağırıyor, kullanıcı için rt parametresini alıyor ve ardından kurban adına arama yapıyor.Bu durumda saldırganın hesabını kurbanınkiyle ilişkilendirmek, esasen bir account take overi tamamlamaktı.
Burada saldırgan, rt parametresinin farklı adreslerde ve özellikle de json responselarında döndürüldüğünü fark etti. Bu nedenle exploit edebilmeyi amaçlayarak üzerine gitti. Bu da bize herhangi bir sorun hissettiğimizde üzerine gidip ona bağlı her şeyi dikkatle incelememiz gerektiğini hatırlatan güzel bir örnek oluyor.
Umarım örnekler durumu anlamanıza yardımcı olmuştur son olarak konuyu toparlayalım ve son defa üzerinden geçelim. CSRF, kurban bilmeden veya aktif olarak bir işlem gerçekleştirmeden de yürütülebilen bir saldırı türüdür. CSRF açıkları bulmak özellikle günümüzde kolay değildir ustalık gerektirebilir ve son örnekte olduğu gibi her şeyi test etmeniz, titizlikle incelemeniz gerekebilir. İhtiyacınıza göre en iyi request methodunu tercih etmeyi ihmal etmeyiniz, veriyle alakalı işlemlerinizi GET methodu ile yapmayınız!
CSRF, günümüzde eskisi kadar popüler değildir çünkü Google, 17 Şubat 2020 tarihinde sameSite kavramını belirli kullanıcılara açıldı. Bu durum sayesinde csrf tarihin tozlu sayfalarına doğru gitse de bu sefer özellikle e-ticaret sitelerinin göz bebeği sameSite kavramıyla sorunlar yaşamaya başladı. Örneğin;
SameSite problemi için örnek senaryo: Müşteri, üye iş yeri web sitesinde checkout sayfasına gelir. (üye iş yeri websitesi, müşterisi için bir cookie oluşturmuştur) Üye iş yeri, 3ds init isteği atar ve aldığı HTML içeriği yazdırarak müşterisini banka sayfasına yönlendirir(domain değişmiştir). Müşteri sms doğrulaması yapar. Banka müşteriyi iyzico’ya yönlendirir, iyzico ise üye iş yerinin sonuç sayfasına yönlendirme yapar. Bu sırada ödeme ile ilgili bilgileri bu adrese post metoduyla gönderir. Bu aşamada üye iş yeri sistemi, müşterisini tanımak veya sepeti kontrol etmek için cookie bilgisini sorgular. Eğer cookie sameSite=None ve secure olarak tanımlanmamışsa Chrome bu cookielerin okunmasına izin vermez. Üye iş yeri ödemenin kaydı için gerekli işlemleri yapamaz veya siparişi oluşturamaz. ( Kaynak — iyzico)
Bu konuya aşağıda bıraktığım video linklerden birinde MDISEC, konuyu detaylıca aktarıyor ayrıca cookie konusunda da çok keyifli ve bilgilendirici bir anlatım yapıyor. Yazımı okuduğunuz için teşekkür ederim.
https://www.youtube.com/watch?v=CKHai0OW6BY
https://www.youtube.com/watch?v=eWEgUcHPle0
— —
Yazımda içerisinde cümlelerden kullandığım kitap:
https://www.goodreads.com/book/show/33596532-web-hacking-101
