Cookies Hacking
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)
कुकीज़ कई विशेषताओं के साथ आती हैं जो उपयोगकर्ता के ब्राउज़र में उनके व्यवहार को नियंत्रित करती हैं। यहाँ इन विशेषताओं का एक संक्षिप्त विवरण है:
कुकी की समाप्ति तिथि Expires विशेषता द्वारा निर्धारित की जाती है। इसके विपरीत, Max-age विशेषता उस समय को परिभाषित करती है जो कुकी को हटाने से पहले सेकंड में है। Max-age का चयन करें क्योंकि यह अधिक आधुनिक प्रथाओं को दर्शाता है।
कुकी प्राप्त करने वाले होस्ट Domain विशेषता द्वारा निर्दिष्ट किए जाते हैं। डिफ़ॉल्ट रूप से, इसे उस होस्ट पर सेट किया जाता है जिसने कुकी जारी की, इसके उपडोमेन को शामिल नहीं किया जाता है। हालाँकि, जब Domain विशेषता स्पष्ट रूप से सेट की जाती है, तो यह उपडोमेन को भी शामिल करती है। यह Domain विशेषता के निर्दिष्ट करने को एक कम प्रतिबंधात्मक विकल्प बनाता है, जो उन परिदृश्यों के लिए उपयोगी है जहाँ उपडोमेन के बीच कुकी साझा करना आवश्यक है। उदाहरण के लिए, Domain=mozilla.org सेट करने से इसके उपडोमेन जैसे developer.mozilla.org पर कुकीज़ सुलभ हो जाती हैं।
Path विशेषता द्वारा संकेतित एक विशिष्ट URL पथ होना चाहिए जो अनुरोधित URL में मौजूद होना चाहिए ताकि Cookie हेडर भेजा जा सके। यह विशेषता / वर्ण को एक निर्देशिका विभाजक के रूप में मानती है, जिससे उपनिर्देशिकाओं में मेल खाने की अनुमति मिलती है।
जब दो कुकीज़ का नाम समान होता है, तो भेजने के लिए चुनी गई कुकी इस पर आधारित होती है:
अनुरोधित URL में सबसे लंबे पथ से मेल खाने वाली कुकी।
यदि पथ समान हैं तो सबसे हाल में सेट की गई कुकी।
SameSite विशेषता यह निर्धारित करती है कि क्या कुकीज़ तीसरे पक्ष के डोमेन से उत्पन्न अनुरोधों पर भेजी जाती हैं। यह तीन सेटिंग्स प्रदान करती है:
Strict: तीसरे पक्ष के अनुरोधों पर कुकी भेजने से रोकता है।
Lax: तीसरे पक्ष की वेबसाइटों द्वारा शुरू किए गए GET अनुरोधों के साथ कुकी भेजने की अनुमति देता है।
None: किसी भी तीसरे पक्ष के डोमेन से कुकी भेजने की अनुमति देता है।
याद रखें, कुकीज़ को कॉन्फ़िगर करते समय, इन विशेषताओं को समझना यह सुनिश्चित करने में मदद कर सकता है कि वे विभिन्न परिदृश्यों में अपेक्षित रूप से व्यवहार करें।
Request Type | Example Code | Cookies Sent When |
Link | <a href="..."></a> | NotSet*, Lax, None |
Prerender | <link rel="prerender" href=".."/> | NotSet*, Lax, None |
Form GET | <form method="GET" action="..."> | NotSet*, Lax, None |
Form POST | <form method="POST" action="..."> | NotSet*, None |
iframe | <iframe src="..."></iframe> | NotSet*, None |
AJAX | $.get("...") | NotSet*, None |
Image | <img src="..."> | NetSet*, None |
Table from Invicti and slightly modified. एक कुकी जिसमें SameSite विशेषता होगी वह CSRF हमलों को कम करेगी जहाँ एक लॉग इन सत्र की आवश्यकता होती है।
*ध्यान दें कि Chrome80 (फरवरी/2019) से बिना कुकी सैमसाइट विशेषता वाली कुकी का डिफ़ॉल्ट व्यवहार लक्स होगा (https://www.troyhunt.com/promiscuous-cookies-and-their-impending-death-via-the-samesite-policy/). ध्यान दें कि अस्थायी रूप से, इस परिवर्तन को लागू करने के बाद, Chrome में बिना SameSite **नीति वाली कुकीज़ को पहले 2 मिनट के लिए None के रूप में व्यवहार किया जाएगा और फिर शीर्ष स्तर के क्रॉस-साइट POST अनुरोध के लिए Lax के रूप में।
यह क्लाइंट को कुकी तक पहुँचने से रोकता है (उदाहरण के लिए Javascript के माध्यम से: document.cookie)
यदि पृष्ठ अनुरोधों के उत्तर के रूप में कुकीज़ भेज रहा है (उदाहरण के लिए एक PHPinfo पृष्ठ में), तो XSS का दुरुपयोग करके इस पृष्ठ पर अनुरोध भेजना और उत्तर से कुकीज़ चुराना संभव है (एक उदाहरण देखें https://hackcommander.github.io/posts/2022/11/12/bypass-httponly-via-php-info-page/).
इसे TRACE HTTP अनुरोधों के साथ बायपास किया जा सकता है क्योंकि सर्वर से उत्तर कुकीज़ को दर्शाएगा। इस तकनीक को Cross-Site Tracking कहा जाता है।
आधुनिक ब्राउज़रों द्वारा JS से TRACE अनुरोध भेजने की अनुमति न देकर इस तकनीक को टाला जाता है। हालाँकि, IE6.0 SP2 के लिए \r\nTRACE भेजने जैसे कुछ बायपास विशेष सॉफ़्टवेयर में पाए गए हैं।
एक और तरीका ब्राउज़रों की शून्य/दिन की कमजोरियों का शोषण करना है।
यह कुकी जार ओवरफ्लो हमले द्वारा HttpOnly कुकीज़ को ओवरराइट करना संभव है:
इन कुकीज़ को निकालने के लिए Cookie Smuggling हमले का उपयोग करना संभव है।
अनुरोध केवल तभी HTTP अनुरोध में कुकी भेजेगा जब अनुरोध एक सुरक्षित चैनल (आमतौर पर HTTPS) के माध्यम से प्रसारित किया गया हो।
__Secure- से प्रारंभ होने वाली कुकीज़ को HTTPS द्वारा सुरक्षित पृष्ठों के साथ secure ध्वज के साथ सेट किया जाना आवश्यक है।
__Host- से प्रारंभ होने वाली कुकीज़ के लिए, कई शर्तें पूरी की जानी चाहिए:
इन्हें secure ध्वज के साथ सेट किया जाना चाहिए।
इन्हें HTTPS द्वारा सुरक्षित पृष्ठ से उत्पन्न होना चाहिए।
इन्हें एक डोमेन निर्दिष्ट करने की अनुमति नहीं है, जिससे उपडोमेन में उनके संचरण को रोका जा सके।
इन कुकीज़ के लिए पथ को / पर सेट किया जाना चाहिए।
यह ध्यान रखना महत्वपूर्ण है कि __Host- से प्रारंभ होने वाली कुकीज़ को सुपरडोमेन या उपडोमेन में भेजने की अनुमति नहीं है। यह प्रतिबंध एप्लिकेशन कुकीज़ को अलग करने में मदद करता है। इसलिए, सभी एप्लिकेशन कुकीज़ के लिए __Host- उपसर्ग का उपयोग करना सुरक्षा और अलगाव को बढ़ाने के लिए एक अच्छी प्रथा मानी जा सकती है।
तो, __Host- उपसर्ग वाली कुकीज़ की एक सुरक्षा यह है कि उन्हें उपडोमेन से ओवरराइट होने से रोका जा सके। उदाहरण के लिए Cookie Tossing attacks को रोकना। वार्ता Cookie Crumbles: Unveiling Web Session Integrity Vulnerabilities (paper) में प्रस्तुत किया गया है कि उपडोमेन से __HOST- उपसर्ग वाली कुकीज़ सेट करना संभव था, पार्सर को धोखा देकर, उदाहरण के लिए, "=" को शुरुआत या अंत में जोड़कर...:
या PHP में कुकी नाम की शुरुआत में अन्य वर्ण जोड़ना संभव था जो अंडरस्कोर वर्णों द्वारा बदले जाएंगे, जिससे __HOST- कुकीज़ को ओवरराइट करना संभव हो गया:
यदि एक कस्टम कुकी में संवेदनशील डेटा है तो इसे जांचें (विशेष रूप से यदि आप एक CTF खेल रहे हैं), क्योंकि यह कमजोर हो सकता है।
कुकीज़ में एम्बेडेड संवेदनशील डेटा को हमेशा ध्यान से देखना चाहिए। Base64 या समान प्रारूपों में एन्कोडेड कुकीज़ को अक्सर डिकोड किया जा सकता है। यह कमजोरी हमलावरों को कुकी की सामग्री को बदलने और अन्य उपयोगकर्ताओं का अनुकरण करने की अनुमति देती है, उनके संशोधित डेटा को फिर से कुकी में एन्कोड करके।
यह हमला एक उपयोगकर्ता की कुकी चुराने से संबंधित है ताकि उनके खाते में अनधिकृत पहुँच प्राप्त की जा सके। चुराई गई कुकी का उपयोग करके, एक हमलावर वैध उपयोगकर्ता का अनुकरण कर सकता है।
इस परिदृश्य में, एक हमलावर एक पीड़ित को एक विशिष्ट कुकी का उपयोग करके लॉग इन करने के लिए धोखा देता है। यदि एप्लिकेशन लॉगिन पर एक नई कुकी असाइन नहीं करता है, तो हमलावर, जिसके पास मूल कुकी है, पीड़ित का अनुकरण कर सकता है। यह तकनीक इस पर निर्भर करती है कि पीड़ित हमलावर द्वारा प्रदान की गई कुकी के साथ लॉग इन करता है।
यदि आपने एक XSS एक उपडोमेन में पाया है या आप एक उपडोमेन को नियंत्रित करते हैं, तो पढ़ें:
Cookie Tossingयहाँ, हमलावर पीड़ित को हमलावर की सत्र कुकी का उपयोग करने के लिए मनाता है। पीड़ित, यह मानते हुए कि वे अपने खाते में लॉग इन हैं, अनजाने में हमलावर के खाते के संदर्भ में क्रियाएँ करेगा।
यदि आपने एक XSS एक उपडोमेन में पाया है या आप एक उपडोमेन को नियंत्रित करते हैं, तो पढ़ें:
Cookie Tossingसंभावित दोषों को समझाने वाले पृष्ठ तक पहुँचने के लिए पिछले लिंक पर क्लिक करें।
कुकीज़ में उपयोग किए जाने वाले JSON वेब टोकन (JWT) भी कमजोरियाँ प्रस्तुत कर सकते हैं। संभावित दोषों और उन्हें शोषित करने के तरीकों के बारे में गहन जानकारी के लिए, JWT हैकिंग पर लिंक किए गए दस्तावेज़ तक पहुँचने की सिफारिश की जाती है।
यह हमला एक लॉग इन उपयोगकर्ता को एक वेब एप्लिकेशन पर अवांछित क्रियाएँ करने के लिए मजबूर करता है जिसमें वे वर्तमान में प्रमाणित हैं। हमलावर उन कुकीज़ का लाभ उठा सकते हैं जो स्वचालित रूप से कमजोर साइट के साथ हर अनुरोध के साथ भेजी जाती हैं।
(अधिक विवरण के लिए मूल शोध देखें) ब्राउज़रों को बिना नाम वाली कुकीज़ बनाने की अनुमति है, जिसे JavaScript के माध्यम से इस प्रकार प्रदर्शित किया जा सकता है:
संदेश में भेजे गए कुकी हेडर का परिणाम a=v1; test value; b=v2; है। दिलचस्प बात यह है कि यदि एक खाली नाम की कुकी सेट की जाती है, तो यह कुकीज़ में हेरफेर की अनुमति देती है, संभावित रूप से अन्य कुकीज़ को एक विशिष्ट मान पर सेट करके नियंत्रित करना:
यह ब्राउज़र को एक कुकी हेडर भेजने की ओर ले जाता है जिसे हर वेब सर्वर द्वारा a नामक कुकी के रूप में और b मान के साथ व्याख्यायित किया जाता है।
Chrome में, यदि एक यूनिकोड सरोगेट कोडपॉइंट सेट कुकी का हिस्सा है, तो document.cookie भ्रष्ट हो जाता है, जिसके परिणामस्वरूप एक खाली स्ट्रिंग लौटती है:
यह document.cookie को एक खाली स्ट्रिंग आउटपुट करने का परिणाम है, जो स्थायी भ्रष्टाचार को इंगित करता है।
(अधिक विवरण के लिए मूल शोध देखें) कई वेब सर्वर, जिनमें Java (Jetty, TomCat, Undertow) और Python (Zope, cherrypy, web.py, aiohttp, bottle, webob) शामिल हैं, पुराने RFC2965 समर्थन के कारण कुकी स्ट्रिंग्स को गलत तरीके से संभालते हैं। वे एक डबल-क्वोटेड कुकी मान को एकल मान के रूप में पढ़ते हैं, भले ही इसमें सेमीकोलन शामिल हों, जो सामान्यतः कुंजी-मूल्य जोड़ों को अलग करना चाहिए:
(अधिक जानकारी के लिए मूल शोध देखें) सर्वरों द्वारा कुकीज़ का गलत पार्सिंग, विशेष रूप से Undertow, Zope, और जो Python के http.cookie.SimpleCookie और http.cookie.BaseCookie का उपयोग करते हैं, कुकी इंजेक्शन हमलों के लिए अवसर पैदा करता है। ये सर्वर नए कुकीज़ की शुरुआत को सही ढंग से सीमित नहीं करते, जिससे हमलावरों को कुकीज़ को स्पूफ करने की अनुमति मिलती है:
Undertow एक उद्धृत मान के तुरंत बाद एक नए कुकी की अपेक्षा करता है बिना सेमीकोलन के।
Zope अगली कुकी को पार्स करने के लिए एक अल्पविराम की तलाश करता है।
Python की कुकी कक्षाएँ एक स्पेस कैरेक्टर पर पार्सिंग शुरू करती हैं।
यह कमजोरी विशेष रूप से उन वेब अनुप्रयोगों में खतरनाक है जो कुकी-आधारित CSRF सुरक्षा पर निर्भर करते हैं, क्योंकि यह हमलावरों को स्पूफ किए गए CSRF-टोकन कुकीज़ इंजेक्ट करने की अनुमति देती है, जो सुरक्षा उपायों को बायपास कर सकती है। समस्या Python के डुप्लिकेट कुकी नामों के प्रबंधन से बढ़ जाती है, जहां अंतिम घटना पहले वाले को ओवरराइड करती है। यह असुरक्षित संदर्भों में __Secure- और __Host- कुकीज़ के लिए चिंताएँ भी उठाती है और जब कुकीज़ को बैक-एंड सर्वरों पर भेजा जाता है जो स्पूफिंग के प्रति संवेदनशील होते हैं, तो यह प्राधिकरण बायपास का कारण बन सकती है।
कुकी हर बार जब आप लॉगिन करते हैं, तो एक जैसी होती है।
लॉग आउट करें और उसी कुकी का उपयोग करने की कोशिश करें।
एक ही खाते में 2 उपकरणों (या ब्राउज़रों) के साथ उसी कुकी का उपयोग करके लॉग इन करने की कोशिश करें।
जांचें कि क्या कुकी में कोई जानकारी है और इसे संशोधित करने की कोशिश करें।
लगभग समान उपयोगकर्ता नाम के साथ कई खाते बनाने की कोशिश करें और देखें कि क्या आप समानताएँ देख सकते हैं।
यदि "मुझे याद रखें" विकल्प मौजूद है, तो देखें कि यह कैसे काम करता है। यदि यह मौजूद है और कमजोर हो सकता है, तो हमेशा मुझे याद रखें की कुकी का उपयोग करें बिना किसी अन्य कुकी के।
जांचें कि क्या पिछले कुकी का काम करता है, भले ही आप पासवर्ड बदल दें।
यदि कुकी लॉग इन करते समय समान (या लगभग समान) रहती है, तो इसका मतलब शायद यह है कि कुकी आपके खाते के किसी क्षेत्र से संबंधित है (संभवतः उपयोगकर्ता नाम)। फिर आप कर सकते हैं:
बहुत सारे खाते बनाने की कोशिश करें जिनके उपयोगकर्ता नाम बहुत समान हैं और यह अनुमान लगाने की कोशिश करें कि एल्गोरिदम कैसे काम कर रहा है।
उपयोगकर्ता नाम को ब्रूटफोर्स करने की कोशिश करें। यदि कुकी केवल आपके उपयोगकर्ता नाम के लिए प्रमाणीकरण विधि के रूप में सहेजी जाती है, तो आप उपयोगकर्ता नाम "Bmin" के साथ एक खाता बना सकते हैं और अपनी कुकी के हर एक बिट को ब्रूटफोर्स कर सकते हैं क्योंकि आप जो कुकी आज़माएँगे उनमें से एक "admin" की होगी।
पैडिंग ओरकल की कोशिश करें (आप कुकी की सामग्री को डिक्रिप्ट कर सकते हैं)। पैडबस्टर का उपयोग करें।
पैडिंग ओरकल - पैडबस्टर उदाहरण
Padbuster कई प्रयास करेगा और आपसे पूछेगा कि कौन सी स्थिति त्रुटि स्थिति है (जो मान्य नहीं है)।
फिर यह कुकी को डिक्रिप्ट करना शुरू करेगा (इसमें कई मिनट लग सकते हैं)
यदि हमला सफलतापूर्वक किया गया है, तो आप अपनी पसंद की एक स्ट्रिंग को एन्क्रिप्ट करने की कोशिश कर सकते हैं। उदाहरण के लिए, यदि आप encrypt user=administrator करना चाहते हैं।
यह निष्पादन आपको कुकी सही ढंग से एन्क्रिप्ट और एन्कोडेड देगा जिसमें स्ट्रिंग user=administrator होगी।
CBC-MAC
शायद एक कुकी में कुछ मान हो सकता है और इसे CBC का उपयोग करके साइन किया जा सकता है। फिर, मान की अखंडता वही हस्ताक्षर है जो उसी मान के साथ CBC का उपयोग करके बनाया गया है। चूंकि IV के रूप में शून्य वेक्टर का उपयोग करने की सिफारिश की जाती है, यह प्रकार की अखंडता जांच कमजोर हो सकती है।
हमला
उपयोगकर्ता नाम administ का हस्ताक्षर प्राप्त करें = t
उपयोगकर्ता नाम rator\x00\x00\x00 XOR t का हस्ताक्षर प्राप्त करें = t'
कुकी में मान सेट करें administrator+t' (t' एक मान्य हस्ताक्षर होगा (rator\x00\x00\x00 XOR t) XOR t = rator\x00\x00\x00
ECB
यदि कुकी को ECB का उपयोग करके एन्क्रिप्ट किया गया है तो यह कमजोर हो सकता है। जब आप लॉग इन करते हैं, तो आपको जो कुकी मिलती है वह हमेशा एक समान होनी चाहिए।
कैसे पता करें और हमला करें:
लगभग समान डेटा (उपयोगकर्ता नाम, पासवर्ड, ईमेल, आदि) के साथ 2 उपयोगकर्ता बनाएं और दिए गए कुकी के अंदर कुछ पैटर्न खोजने की कोशिश करें।
उदाहरण के लिए "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" नाम का एक उपयोगकर्ता बनाएं और देखें कि क्या कुकी में कोई पैटर्न है (चूंकि ECB हर ब्लॉक को एक ही कुंजी के साथ एन्क्रिप्ट करता है, यदि उपयोगकर्ता नाम एन्क्रिप्ट किया गया है तो समान एन्क्रिप्टेड बाइट्स दिखाई दे सकते हैं)।
एक पैटर्न होना चाहिए (एक उपयोग किए गए ब्लॉक के आकार के साथ)। इसलिए, यह जानकर कि "a" का एक समूह कैसे एन्क्रिप्ट किया गया है, आप एक उपयोगकर्ता नाम बना सकते हैं: "a"*(ब्लॉक का आकार)+"admin"। फिर, आप कुकी से "a" के एक ब्लॉक के एन्क्रिप्टेड पैटर्न को हटा सकते हैं। और आपके पास उपयोगकर्ता नाम "admin" की कुकी होगी।
AWS हैकिंग सीखें और अभ्यास करें:HackTricks Training AWS Red Team Expert (ARTE) GCP हैकिंग सीखें और अभ्यास करें: HackTricks Training GCP Red Team Expert (GRTE)
