Cookie Tossing
Last updated
Last updated
AWS Hacking'i öğrenin ve pratik yapın:HackTricks Training AWS Red Team Expert (ARTE) GCP Hacking'i öğrenin ve pratik yapın: HackTricks Training GCP Red Team Expert (GRTE)
Eğer bir saldırgan bir alt alan adını veya bir şirketin alan adını kontrol edebiliyorsa ya da bir alt alan adında bir XSS bulursa bu saldırıyı gerçekleştirebilir.
Cookies Hacking bölümünde belirtildiği gibi, bir çerez bir alana (belirterek) ayarlandığında, o alan ve alt alan adlarında kullanılacaktır.
Bu nedenle, bir saldırgan belirli bir çerezi alan ve alt alan adlarına ayarlayabilecektir, bu da şunu yaparak mümkündür: document.cookie="session=1234; Path=/app/login; domain=.example.com"
Bu tehlikeli olabilir çünkü saldırgan:
Kurbanın çerezini saldırganın hesabına sabitleyebilir, böylece kullanıcı fark etmezse, saldırganın hesabında işlemleri gerçekleştirebilir ve saldırgan bazı ilginç bilgilere ulaşabilir (kullanıcının platformdaki arama geçmişini kontrol etmek, kurbanın hesabında kredi kartı ayarlaması yapması...).
Eğer çerez giriş yaptıktan sonra değişmiyorsa, saldırgan sadece bir çerezi sabitleyebilir (oturum sabitleme), kurban giriş yapana kadar bekleyebilir ve sonra o çerezi kullanarak kurban olarak giriş yapabilir.
Bazen, oturum çerezleri değişse bile, saldırgan önceki çerezi kullanabilir ve yeni çerezi de alabilir.
Eğer çerez bazı başlangıç değerleri ayarlıyorsa (flask'ta olduğu gibi, burada çerez oturumun CSRF token'ını ayarlayabilir ve bu değer kurban giriş yaptıktan sonra korunur), saldırgan bu bilinen değeri ayarlayabilir ve sonra bunu kötüye kullanabilir (bu senaryoda, saldırgan kurbanın CSRF token'ını bildiği için kullanıcıyı bir CSRF isteği gerçekleştirmeye zorlayabilir).
Değeri ayarlamak gibi, saldırgan ayrıca sunucu tarafından üretilen kimlik doğrulaması yapılmamış bir çerezi alabilir, ondan CSRF token'ını alabilir ve bunu kullanabilir.
Bir tarayıcı, aynı isimde iki çerez aldığında ve bu çerezler aynı kapsamı (alan, alt alanlar ve yol) kısmen etkiliyorsa, tarayıcı her iki çerezin değerini de geçerli olduğu sürece istekte gönderecektir.
Kimin en spesifik yolu olduğu veya hangisinin en eski olduğu dikkate alınarak, tarayıcı önce çerezin değerini ayarlayacak ve sonra diğerinin değerini ayarlayacaktır, örneğin: Cookie: iduser=MoreSpecificAndOldestCookie; iduser=LessSpecific;
Çoğu web sitesi yalnızca ilk değeri kullanacaktır. Bu nedenle, bir saldırgan bir çerez ayarlamak istiyorsa, başka bir çerez ayarlanmadan önce ayarlamak veya daha spesifik bir yol ile ayarlamak daha iyidir.
Ayrıca, daha spesifik bir yolda çerez ayarlama yeteneği çok ilginçtir çünkü kurbanın çerezi ile çalışmasını sağlayabilirsiniz, yalnızca kötü niyetli çerezin ayarlandığı spesifik yol dışında.
Bu saldırıya karşı olası bir koruma, web sunucusunun aynı isimde ancak iki farklı değere sahip iki çerezi kabul etmemesi olacaktır.
Saldırganın kurbanın çerezini aldıktan sonra bir çerez ayarladığı senaryosunu aşmak için, saldırgan bir çerez taşması oluşturabilir ve sonra, geçerli çerez silindikten sonra, kötü niyetli olanı ayarlayabilir.
Cookie Jar OverflowBaşka bir yararlı aşma yöntemi, çerez adını URL kodlamaktır çünkü bazı korumalar bir istekte aynı isimde 2 çerez kontrol eder ve ardından sunucu çerez adlarını çözer.
Bir Cookie Tossing saldırısı ayrıca bir Çerez Bombası saldırısı gerçekleştirmek için de kullanılabilir:
Cookie Bomb__Host ön ekini kullanınEğer bir çerez adı bu ön eki taşıyorsa, yalnızca Set-Cookie direktifinde Güvenli olarak işaretlenmişse, güvenli bir kaynaktan gönderilmişse, bir Alan niteliği içermiyorsa ve Yol niteliği / olarak ayarlanmışsa kabul edilecektir.
Bu, alt alanların bir çerezi ana alana zorlamasını engeller çünkü bu çerezler "alan kilitli" olarak görülebilir.
AWS Hacking'i öğrenin ve pratik yapın:HackTricks Training AWS Red Team Expert (ARTE) GCP Hacking'i öğrenin ve pratik yapın: HackTricks Training GCP Red Team Expert (GRTE)
