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 अनुरोधों के साथ बायपास किया जा सकता है क्योंकि सर्वर से उत्तर भेजी गई कुकीज़ को दर्शाएगा (यदि यह 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 समर्थन के कारण कुकी स्ट्रिंग्स को गलत तरीके से संभालते हैं। वे एक डबल-क्वोटेड कुकी मान को एकल मान के रूप में पढ़ते हैं, भले ही इसमें सेमीकोलन शामिल हों, जो सामान्यतः कुंजी-मूल्य जोड़ों को अलग करना चाहिए:
(Check further details in theoriginal research) सर्वरों द्वारा कुकीज़ का गलत पार्सिंग, विशेष रूप से Undertow, Zope, और जो Python के http.cookie.SimpleCookie और http.cookie.BaseCookie का उपयोग करते हैं, कुकी इंजेक्शन हमलों के लिए अवसर पैदा करता है। ये सर्वर नए कुकीज़ की शुरुआत को सही तरीके से सीमित नहीं करते, जिससे हमलावरों को कुकीज़ को स्पूफ करने की अनुमति मिलती है:
Undertow एक उद्धृत मान के तुरंत बाद एक नए कुकी की अपेक्षा करता है बिना सेमीकोलन के।
Zope अगली कुकी को पार्स करने के लिए एक अल्पविराम की तलाश करता है।
Python की कुकी कक्षाएँ एक स्पेस कैरेक्टर पर पार्सिंग शुरू करती हैं।
यह कमजोरियाँ विशेष रूप से उन वेब अनुप्रयोगों में खतरनाक हैं जो कुकी-आधारित CSRF सुरक्षा पर निर्भर करते हैं, क्योंकि यह हमलावरों को स्पूफ किए गए CSRF-टोकन कुकीज़ इंजेक्ट करने की अनुमति देती है, संभावित रूप से सुरक्षा उपायों को बायपास करते हुए। समस्या Python के डुप्लिकेट कुकी नामों के प्रबंधन से बढ़ जाती है, जहां अंतिम घटना पहले वाले को ओवरराइड कर देती है। यह असुरक्षित संदर्भों में __Secure- और __Host- कुकीज़ के लिए चिंताएँ भी उठाता है और जब कुकीज़ को बैक-एंड सर्वरों पर भेजा जाता है जो स्पूफिंग के प्रति संवेदनशील होते हैं, तो यह प्राधिकरण बायपास का कारण बन सकता है।
इस ब्लॉगपोस्ट के अनुसार, यह संभव हो सकता है कि कुकी विशेषता $Version=1 का उपयोग करके बैकएंड को कुकी पार्स करने के लिए पुरानी लॉजिक का उपयोग करने के लिए मजबूर किया जा सके, RFC2109 के कारण। इसके अलावा, अन्य मान जैसे $Domain और $Path का उपयोग बैकएंड के व्यवहार को कुकी के साथ संशोधित करने के लिए किया जा सकता है।
यह पार्सिंग कुकीज़ के अंदर एस्केप किए गए मानों को अनएस्केप करने का संकेत देती है, इसलिए "\a" "a" बन जाता है। यह WAFS को बायपास करने के लिए उपयोगी हो सकता है जैसे:
eval('test') => forbidden
"\e\v\a\l\(\'\t\e\s\t\'\)" => allowed
RFC2109 में यह संकेत दिया गया है कि कुकी मानों के बीच एक अल्पविराम को विभाजक के रूप में उपयोग किया जा सकता है। और यह भी संभव है कि बराबर के चिन्ह के पहले और बाद में स्पेस और टैब जोड़े जाएं। इसलिए एक कुकी जैसे $Version=1; foo=bar, abc = qux कुकी "foo":"bar, admin = qux" उत्पन्न नहीं करता है बल्कि कुकीज़ foo":"bar" और "admin":"qux" उत्पन्न करता है। ध्यान दें कि 2 कुकीज़ उत्पन्न होती हैं और कैसे admin के बराबर के चिन्ह के पहले और बाद में स्पेस हटा दिया गया है।
अंत में, विभिन्न बैकडोर विभिन्न कुकी हेडर में पास की गई विभिन्न कुकीज़ को एक स्ट्रिंग में जोड़ेंगे जैसे:
जो एक WAF को बायपास करने की अनुमति दे सकता है जैसे कि इस उदाहरण में:
कुकी हर बार जब आप लॉगिन करते हैं, तो एक जैसी होती है।
लॉग आउट करें और उसी कुकी का उपयोग करने की कोशिश करें।
एक ही खाते में 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" की कुकी होगी।
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
