Cookie Tossing
विवरण
यदि किसी हमलावर के पास किसी कंपनी के एक सबडोमेन या डोमेन को नियंत्रित करने की क्षमता है या एक सबडोमेन में XSS मिल जाता है तो वह इस हमला कर सकता है।
कुकीज हैकिंग खंड में इसका उल्लेख किया गया था, जब कुकी एक डोमेन पर सेट की जाती है (उसे निर्दिष्ट करते हुए) तो यह डोमेन और सबडोमेन में उपयोग किया जाएगा।
इसलिए, हमलावर को डोमेन और सबडोमेन में एक विशिष्ट कुकी सेट करने की क्षमता होगी जैसे document.cookie="session=1234; Path=/app/login; domain=.example.com" कुछ ऐसा करके।
यह खतरनाक हो सकता है क्योंकि हमलावर निम्नलिखित कर सकता है:
हमलावर विक्टिम की कुकी को अपने खाते में फिक्स कर सकता है इसलिए अगर उपयोगकर्ता को पता नहीं चलता है, तो वह हमलावर के खाते में क्रियाएँ करेगा और हमलावर कुछ दिलचस्प जानकारी प्राप्त कर सकता है (उपयोगकर्ता की खोजों का इतिहास देखें, विक्टिम अपनी क्रेडिट कार्ड को खाते में सेट कर सकता है...)
यदि कुकी लॉगिन के बाद भी बदलती नहीं है, तो हमलावर बस कुकी को फिक्स कर सकता है (सेशन-फिक्सेशन), जब तक विक्टिम लॉग इन नहीं करता है और फिर उस कुकी का उपयोग करके विक्टिम के रूप में लॉग इन कर सकता है।
कभी-कभी, यदि सेशन कुकी बदल जाती है, तो हमलावर पिछली कुकी का उपयोग कर सकता है और उसे नया भी प्राप्त होगा।
यदि कुकी किसी प्रारंभिक मान सेट कर रही है (जैसे फ्लास्क में कुकी सेशन का CSRF टोकन सेट कर सकती है और इस मान को विक्टिम लॉग इन करने के बाद भी बनाए रखेगी), तो हमलावर इस जाने माने मान को सेट कर सकता है और फिर इसका दुरुपयोग कर सकता है (इस स्थिति में, हमलावर उपयोगकर्ता को CSRF अनुरोध करने के लिए बना सकता है क्योंकि उसे CSRF टोकन पता है)।
मान की तरह मान सेट करने के साथ, हमलावर सर्वर द्वारा उत्पन्न एक अप्रमाणित कुकी प्राप्त कर सकता है, उससे CSRF टोकन प्राप्त कर सकता है और इसका उपयोग कर सकता है।
कुकी क्रम
जब ब्राउज़र को दो कुकीज मिलती हैं जिनका नाम एक ही है और जो एक ही स्कोप को आंशिक रूप से प्रभावित करती हैं (डोमेन, सबडोमेन और पथ), तो ब्राउज़र जब उन दोनों कुकीज के लिए अनुरोध करने के लिए वैध होती हैं तो दोनों कुकीज के मान भेजेगा।
किसका सबसे विशिष्ट पथ है या कौन सबसे पुराना है, उसके आधार पर ब्राउज़र पहले कुकी के मान को सेट करेगा और फिर दूसरे के मान को सेट करेगा जैसे: Cookie: iduser=MoreSpecificAndOldestCookie; iduser=LessSpecific;
अधिकांश वेबसाइट्स केवल पहले मान का उपयोग करेंगी। इसलिए, यदि हमलावर किसी कुकी को सेट करना चाहता है तो उसे उससे पहले सेट करना बेहतर है या उसे एक अधिक विशिष्ट पथ के साथ सेट करना बेहतर है।
इसके अतिरिक्त, एक अधिक विशिष्ट पथ में कुकी सेट करने की क्षमता बहुत दिलचस्प है क्योंकि आप विक्टिम को उसकी कुकी के साथ काम करने की क्षमता होगी केवल उस विशिष्ट पथ में जहां दुराचारी कुकी सेट की गई होगी।
सुरक्षा उल्लंघन
इस हमले के खिलाफ संभावित सुरक्षा हो सकती है कि वेब सर्वर दो अलग-अलग मानों वाली दो कुकीज के साथ अनुरोध स्वीकार नहीं करेगा।
जहां हमलावर विक्टिम को पहले ही कुकी दी गई है और उसके बाद कुकी सेट कर रहा है, उस स्थिति को अनदेखा करने के लिए हमलावर एक कुकी ओवरफ्लो का कारण बना सकता है और फिर, एक बार वैध कुकी हटा दी जाती है, तो दुराचारी कुकी सेट कर सकता है।
pageCookie Jar Overflowएक और उपयोगी बाईपास यह हो सकता है कि कुकी के नाम को URL एन्कोड करें क्योंकि कुछ सुरक्षा उन अनुरोधों के लिए जांच करती है जिनमें दो कुकीज हैं जिनका नाम समान है और फिर सर्वर कुकीज के नामों को डिकोड करेगा।
कुकी बम
कुकी टॉसिंग हमला एक कुकी बम हमला करने के लिए भी उपयोग किया जा सकता है:
pageCookie Bombसुरक्षास
कुकी नाम में प्रीफिक्स __Host का उपयोग करें
__Host का उपयोग करेंयदि किसी कुकी का नाम इस प्रीफिक्स के साथ है, तो यह केवल उस सेट-कुकी निर्देशिका में स्वीकार किया जाएगा अगर यह सुरक्षित अवस्थान से भेजा गया है, डोमेन विशेषता शामिल नहीं करता है, और पथ विशेषता को / पर सेट किया गया है
यह उपयोगकर्ता को अपेक्षित डोमेन में कुकी को बाधित करने से रोकता है क्योंकि ये कुकीज "डोमेन-लॉक्ड" के रूप में देखी जा सकती हैं
संदर्भ
[Cookie Crumbles: Unveiling Web Session Integrity Vulnerabilities](https://www.youtube.com/watch?v=F
Last updated