Cookie Tossing
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
यदि एक हमलावर एक उपडोमेन या किसी कंपनी के डोमेन को नियंत्रित कर सकता है या एक उपडोमेन में XSS खोजता है तो वह इस हमले को करने में सक्षम होगा।
जैसा कि कुकीज़ हैकिंग अनुभाग में बताया गया था, जब एक कुकी को एक डोमेन पर सेट किया जाता है (इसे निर्दिष्ट करते हुए) तो इसका उपयोग डोमेन और उपडोमेन में किया जाएगा।
इसलिए, एक हमलावर एक विशेष कुकी को डोमेन और उपडोमेन पर सेट करने में सक्षम होगा ऐसा कुछ करते हुए document.cookie="session=1234; Path=/app/login; domain=.example.com"
यह खतरनाक हो सकता है क्योंकि हमलावर सक्षम हो सकता है:
शिकार की कुकी को हमलावर के खाते में स्थिर करना ताकि यदि उपयोगकर्ता ध्यान न दे, वह हमलावर के खाते में क्रियाएँ करेगा और हमलावर कुछ दिलचस्प जानकारी प्राप्त कर सकता है (प्लेटफ़ॉर्म में उपयोगकर्ता के खोज इतिहास की जांच करना, शिकार अपने खाते में अपना क्रेडिट कार्ड सेट कर सकता है...)
यदि कुकी लॉगिन के बाद नहीं बदलती है, तो हमलावर बस एक कुकी को स्थिर कर सकता है (सत्र-स्थिरता), शिकार के लॉगिन करने की प्रतीक्षा कर सकता है और फिर उस कुकी का उपयोग करके शिकार के रूप में लॉगिन कर सकता है।
कभी-कभी, भले ही सत्र कुकीज़ बदलती हैं, हमलावर पिछले को उपयोग कर सकता है और उसे नया भी प्राप्त होगा।
यदि कुकी कुछ प्रारंभिक मान सेट कर रही है (जैसे कि फ्लास्क में जहां कुकी सत्र का CSRF टोकन सेट कर सकती है और यह मान शिकार के लॉगिन करने के बाद बनाए रखा जाएगा), तो हमलावर इस ज्ञात मान को सेट कर सकता है और फिर इसका दुरुपयोग कर सकता है (उस परिदृश्य में, हमलावर फिर उपयोगकर्ता को CSRF अनुरोध करने के लिए मजबूर कर सकता है क्योंकि वह CSRF टोकन जानता है)।
मान सेट करने के समान, हमलावर एक अनधिकृत कुकी भी प्राप्त कर सकता है जो सर्वर द्वारा उत्पन्न होती है, उससे CSRF टोकन प्राप्त कर सकता है और इसका उपयोग कर सकता है।
जब एक ब्राउज़र एक ही नाम की दो कुकीज़ प्राप्त करता है जो आंशिक रूप से समान दायरे को प्रभावित करती हैं (डोमेन, उपडोमेन और पथ), तो ब्राउज़र दोनों कुकी के मान भेजेगा जब दोनों अनुरोध के लिए मान्य हों।
इस पर निर्भर करते हुए कि किसके पास सबसे विशिष्ट पथ है या कौन सा पुराना है, ब्राउज़र पहले कुकी का मान सेट करेगा और फिर दूसरे का मान जैसे: Cookie: iduser=MoreSpecificAndOldestCookie; iduser=LessSpecific;
अधिकतर वेबसाइटें केवल पहले मान का उपयोग करेंगी। फिर, यदि एक हमलावर कुकी सेट करना चाहता है, तो इसे किसी अन्य के सेट होने से पहले सेट करना बेहतर है या इसे अधिक विशिष्ट पथ के साथ सेट करना बेहतर है।
इसके अलावा, एक अधिक विशिष्ट पथ में कुकी सेट करने की क्षमता बहुत दिलचस्प है क्योंकि आप शिकार को उसकी कुकी के साथ काम करने के लिए मजबूर कर सकते हैं सिवाय उस विशिष्ट पथ के जहां दुर्भावनापूर्ण कुकी सेट की गई होगी।
इस हमले के खिलाफ संभावित सुरक्षा यह हो सकती है कि वेब सर्वर एक ही नाम की दो कुकीज़ को दो अलग-अलग मानों के साथ स्वीकार नहीं करेगा।
उस परिदृश्य को बायपास करने के लिए जहां हमलावर एक कुकी सेट कर रहा है जब शिकार को पहले ही कुकी दी जा चुकी है, हमलावर एक कुकी ओवरफ्लो का कारण बन सकता है और फिर, एक बार जब वैध कुकी हटा दी जाती है, तो दुर्भावनापूर्ण कुकी सेट कर सकता है।
Cookie Jar Overflowएक और उपयोगी बायपास यह हो सकता है कि कुकी के नाम को URL एन्कोड करें क्योंकि कुछ सुरक्षा अनुरोध में एक ही नाम की 2 कुकीज़ की जांच करती हैं और फिर सर्वर कुकीज़ के नामों को डिकोड करेगा।
एक Cookie Tossing हमला एक Cookie Bomb हमले को करने के लिए भी उपयोग किया जा सकता है:
Cookie Bomb__Host उपसर्ग का उपयोग करेंयदि एक कुकी नाम में यह उपसर्ग है, तो यह केवल स्वीकार किया जाएगा यदि इसे सुरक्षित के रूप में चिह्नित किया गया है, इसे एक सुरक्षित मूल से भेजा गया है, इसमें एक डोमेन विशेषता शामिल नहीं है, और इसका पथ विशेषता / पर सेट है।
यह उपडोमेनों को शीर्ष डोमेन पर कुकी को मजबूर करने से रोकता है क्योंकि इन कुकीज़ को "डोमेन-लॉक्ड" के रूप में देखा जा सकता है।
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
