Cookie Tossing

Reading time: 5 minutes

Description

यदि एक हमलावर एक उपडोमेन या किसी कंपनी के डोमेन को नियंत्रित कर सकता है या उपडोमेन में XSS खोजता है तो वह इस हमले को अंजाम देने में सक्षम होगा।

जैसा कि कुकीज़ हैकिंग अनुभाग में संकेत दिया गया था, जब एक कुकी को एक डोमेन पर सेट किया जाता है (इसे निर्दिष्ट करते हुए) तो इसे डोमेन और उपडोमेन में उपयोग किया जाएगा।

यह खतरनाक हो सकता है क्योंकि हमलावर सक्षम हो सकता है:

• शिकार की कुकी को हमलावर के खाते में स्थिर करना ताकि यदि उपयोगकर्ता ध्यान न दे, वह हमलावर के खाते में क्रियाएँ करेगा और हमलावर कुछ दिलचस्प जानकारी प्राप्त कर सकता है (प्लेटफ़ॉर्म पर उपयोगकर्ता के खोज इतिहास की जांच करना, शिकार अपने खाते में अपना क्रेडिट कार्ड सेट कर सकता है...)
• यदि कुकी लॉगिन के बाद नहीं बदलती है, तो हमलावर बस एक कुकी को स्थिर कर सकता है (सत्र-स्थिरीकरण), शिकार के लॉगिन करने की प्रतीक्षा कर सकता है और फिर उस कुकी का उपयोग करके शिकार के रूप में लॉगिन कर सकता है।
• कभी-कभी, भले ही सत्र कुकीज़ बदलती हैं, हमलावर पिछले को उपयोग कर सकता है और उसे नया भी प्राप्त होगा।
• यदि कुकी कुछ प्रारंभिक मान सेट कर रही है (जैसे कि फ्लास्क में जहां कुकी **सत्र का CSRF टोकन सेट कर सकती है और यह मान शिकार के लॉगिन करने के बाद बनाए रखा जाएगा), तो हमलावर इस ज्ञात मान को सेट कर सकता है और फिर इसका दुरुपयोग कर सकता है (उस परिदृश्य में, हमलावर फिर उपयोगकर्ता को CSRF अनुरोध करने के लिए मजबूर कर सकता है क्योंकि वह CSRF टोकन जानता है)।
• मान सेट करने के समान, हमलावर एक अनधिकृत कुकी प्राप्त कर सकता है जो सर्वर द्वारा उत्पन्न होती है, उससे CSRF टोकन प्राप्त कर सकता है और इसका उपयोग कर सकता है।

Cookie Order

जब एक ब्राउज़र को एक ही नाम की दो कुकीज़ प्राप्त होती हैं जो आंशिक रूप से समान दायरे (डोमेन, उपडोमेन और पथ) को प्रभावित करती हैं, तो ब्राउज़र दोनों कुकी के मान भेजेगा जब दोनों अनुरोध के लिए मान्य हों।

इस पर निर्भर करते हुए कि किसके पास सबसे विशिष्ट पथ है या कौन सा पुराना है, ब्राउज़र पहले कुकी का मान सेट करेगा और फिर दूसरे का मान जैसे: Cookie: iduser=MoreSpecificAndOldestCookie; iduser=LessSpecific;

अधिकांश वेबसाइटें केवल पहले मान का उपयोग करेंगी। फिर, यदि एक हमलावर कुकी सेट करना चाहता है, तो इसे किसी अन्य के सेट होने से पहले सेट करना बेहतर है या इसे अधिक विशिष्ट पथ के साथ सेट करना चाहिए।

Protection Bypass

इस हमले के खिलाफ संभावित सुरक्षा यह हो सकती है कि वेब सर्वर एक ही नाम की दो कुकीज़ को लेकिन दो अलग-अलग मानों के साथ अनुरोध स्वीकार नहीं करेगा।

उस परिदृश्य को बायपास करने के लिए जहां हमलावर एक कुकी सेट कर रहा है जब शिकार को पहले ही कुकी दी जा चुकी है, हमलावर एक कुकी ओवरफ्लो का कारण बन सकता है और फिर, एक बार जब वैध कुकी हटा दी जाती है, तो दुर्भावनापूर्ण कुकी सेट कर सकता है।

Cookie Jar Overflow

एक और उपयोगी बायपास यह हो सकता है कि कुकी के नाम को URL एन्कोड करें क्योंकि कुछ सुरक्षा 2 कुकीज़ के लिए एक ही नाम की जांच करती हैं और फिर सर्वर कुकी के नामों को डिकोड करेगा।

Cookie Bomb

एक Cookie Tossing हमला Cookie Bomb हमले को अंजाम देने के लिए भी उपयोग किया जा सकता है:

Cookie Bomb

Defenses

कुकी नाम में __Host उपसर्ग का उपयोग करें

• यदि एक कुकी नाम में यह उपसर्ग है, तो यह केवल स्वीकार किया जाएगा यदि इसे सुरक्षित के रूप में चिह्नित किया गया है, इसे एक सुरक्षित मूल से भेजा गया है, इसमें डोमेन विशेषता शामिल नहीं है, और पथ विशेषता को / पर सेट किया गया है।
• यह उपडोमेन को शीर्ष डोमेन पर कुकी को मजबूर करने से रोकता है क्योंकि इन कुकीज़ को "डोमेन-लॉक" के रूप में देखा जा सकता है।

References

• @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