Cookie Tossing

Reading time: 4 minutes

Açıklama

Eğer bir saldırgan bir alt alan adını veya bir şirketin alanı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 alanlarda kullanılacaktır.

Bu tehlikeli olabilir çünkü saldırgan:

• Mağdurun ç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, mağdurun hesabında kredi kartı ayarlaması yapması...)
• Bunun bir örneği burada bulunabilir burada saldırgan, mağdurun git reposuna erişim yetkisi vermek için kullanacağı belirli bölümlerde çerezini ayarlamıştır ama saldırganın hesabından çünkü gerekli uç noktalarda çerezlerini ayarlayacaktır.
• Eğer çerez giriş yaptıktan sonra değişmezse, saldırgan sadece bir çerezi sabitleyebilir (session-fixation), mağdur giriş yapana kadar bekleyebilir ve sonra o çerezi kullanarak mağdur 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 mağdur giriş yaptıktan sonra korunur), saldırgan bu bilinen değeri ayarlayabilir ve sonra bunu kötüye kullanabilir (bu senaryoda, saldırgan daha sonra kullanıcının CSRF token'ını bildiği için bir CSRF isteği gerçekleştirmesini sağlayabilir).
• 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.

Çerez Sırası

Bir tarayıcı, aynı isimde iki çerez aldığında kısmen aynı kapsamı etkileyen (alan, alt alanlar ve yol) tarayıcı, her iki çerezin de geçerli olduğu durumlarda her iki çerezin değerini de 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.

Koruma Aşma

Bu saldırıya karşı olası bir koruma, web sunucusunun aynı isimde ama iki farklı değere sahip iki çerezi kabul etmemesi olacaktır.

Saldırganın mağdura çerez verildikten 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 Overflow

Baş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ı çözecektir.

Çerez Bombası

Bir Cookie Tossing saldırısı ayrıca bir Çerez Bombası saldırısı gerçekleştirmek için de kullanılabilir:

Cookie Bomb

Savunmalar

Çerez adında __Host ön ekini kullanın

• Eğer bir çerez adında bu ön ek varsa, 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.

Referanslar

• @blueminimal
• https://speakerdeck.com/filedescriptor/the-cookie-monster-in-your-browsers
• https://github.blog/2013-04-09-yummy-cookies-across-domains/
• Cookie Crumbles: Unveiling Web Session Integrity Vulnerabilities