Hindi - Ht

Cookies Hacking

Support HackTricks

Cookie Attributes

कुकीज़ कई विशेषताओं के साथ आती हैं जो उनके व्यवहार को उपयोगकर्ता के ब्राउज़र में नियंत्रित करती हैं। यहाँ इन विशेषताओं का एक संक्षिप्त विवरण है:

Expires and Max-Age

कुकी की समाप्ति तिथि Expires विशेषता द्वारा निर्धारित की जाती है। इसके विपरीत, Max-age विशेषता उस समय को सेकंड में परिभाषित करती है जब तक एक कुकी हटा नहीं दी जाती। Max-age का चयन करें क्योंकि यह अधिक आधुनिक प्रथाओं को दर्शाता है।

Domain

कुकी प्राप्त करने वाले होस्ट को Domain विशेषता द्वारा निर्दिष्ट किया जाता है। डिफ़ॉल्ट रूप से, इसे उस होस्ट पर सेट किया जाता है जिसने कुकी जारी की, इसके उपडोमेन को शामिल नहीं किया जाता है। हालाँकि, जब Domain विशेषता स्पष्ट रूप से सेट की जाती है, तो यह उपडोमेन को भी शामिल करती है। यह Domain विशेषता के निर्दिष्ट करने को एक कम प्रतिबंधात्मक विकल्प बनाता है, जो उन परिदृश्यों के लिए उपयोगी है जहाँ उपडोमेन के बीच कुकी साझा करना आवश्यक है। उदाहरण के लिए, Domain=mozilla.org सेट करने से इसकी उपडोमेन जैसे developer.mozilla.org पर कुकीज़ सुलभ हो जाती हैं।

Path

Path विशेषता द्वारा एक विशिष्ट URL पथ को इंगित किया जाता है जो अनुरोधित URL में होना चाहिए ताकि Cookie हेडर भेजा जा सके। यह विशेषता / वर्ण को एक निर्देशिका विभाजक के रूप में मानती है, जिससे उपनिर्देशिकाओं में मेल खाने की अनुमति मिलती है।

Ordering Rules

जब दो कुकीज़ का नाम समान होता है, तो भेजने के लिए चुनी गई कुकी इस पर आधारित होती है:

  • अनुरोधित URL में सबसे लंबे पथ से मेल खाने वाली कुकी।

  • यदि पथ समान हैं, तो सबसे हाल में सेट की गई कुकी।

SameSite

  • 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 के रूप में व्यवहार किया जाएगा।

Cookies Flags

HttpOnly

यह क्लाइंट को कुकी तक पहुँचने से रोकता है (उदाहरण के लिए Javascript के माध्यम से: document.cookie)

Bypasses

  • यदि पृष्ठ अनुरोधों के उत्तर के रूप में कुकीज़ भेज रहा है (उदाहरण के लिए एक 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 के लिए TRACE के बजाय \r\nTRACE भेजने जैसे कुछ बायपास विशेष सॉफ़्टवेयर में पाए गए हैं।

  • एक और तरीका ब्राउज़रों की शून्य/दिन की कमजोरियों का शोषण करना है।

  • कुकी जार ओवरफ्लो हमले को अंजाम देकर HttpOnly कुकीज़ को ओवरराइट करना संभव है:

Cookie Jar Overflow

  • इन कुकीज़ को निकालने के लिए Cookie Smuggling हमले का उपयोग करना संभव है।

Secure

अनुरोध केवल तभी HTTP अनुरोध में कुकी भेजेगा जब अनुरोध एक सुरक्षित चैनल (आमतौर पर HTTPS) के माध्यम से प्रसारित किया गया हो।

Cookies Prefixes

__Secure- से प्रारंभ होने वाली कुकीज़ को HTTPS द्वारा सुरक्षित पृष्ठों के साथ secure ध्वज के साथ सेट किया जाना आवश्यक है।

__Host- से प्रारंभ होने वाली कुकीज़ के लिए, कई शर्तें पूरी की जानी चाहिए:

  • इन्हें secure ध्वज के साथ सेट किया जाना चाहिए।

  • इन्हें HTTPS द्वारा सुरक्षित पृष्ठ से उत्पन्न होना चाहिए।

  • इन्हें एक डोमेन निर्दिष्ट करने की अनुमति नहीं है, जिससे उपडोमेन में उनके संचरण को रोका जा सके।

  • इन कुकीज़ के लिए पथ को / पर सेट किया जाना चाहिए।

यह ध्यान रखना महत्वपूर्ण है कि __Host- से प्रारंभ होने वाली कुकीज़ को सुपरडोमेन या उपडोमेन में भेजने की अनुमति नहीं है। यह प्रतिबंध एप्लिकेशन कुकीज़ को अलग करने में मदद करता है। इसलिए, सभी एप्लिकेशन कुकीज़ के लिए __Host- उपसर्ग का उपयोग करना सुरक्षा और अलगाव को बढ़ाने के लिए एक अच्छी प्रथा मानी जा सकती है।

Overwriting cookies

तो, __Host- उपसर्ग वाली कुकीज़ की एक सुरक्षा यह है कि उन्हें उपडोमेन से ओवरराइट होने से रोका जा सके। उदाहरण के लिए Cookie Tossing attacks को रोकना। वार्ता Cookie Crumbles: Unveiling Web Session Integrity Vulnerabilities (paper) में प्रस्तुत किया गया है कि उपडोमेन से __HOST- उपसर्ग वाली कुकीज़ सेट करना संभव था, पार्सर को धोखा देकर, उदाहरण के लिए, "=" को शुरुआत या अंत में जोड़कर...:

या PHP में कुकी नाम के प्रारंभ में अन्य वर्ण जोड़ना संभव था जो अंडरस्कोर वर्णों द्वारा बदले जाने वाले थे, जिससे __HOST- कुकीज़ को ओवरराइट करने की अनुमति मिलती थी:

Cookies Attacks

यदि एक कस्टम कुकी में संवेदनशील डेटा है तो इसे जांचें (विशेष रूप से यदि आप एक CTF खेल रहे हैं), क्योंकि यह कमजोर हो सकता है।

Decoding and Manipulating Cookies

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

Session Hijacking

यह हमला एक उपयोगकर्ता की कुकी चुराने से संबंधित है ताकि उनके खाते में अनधिकृत पहुँच प्राप्त की जा सके। चुराई गई कुकी का उपयोग करके, एक हमलावर वैध उपयोगकर्ता का अनुकरण कर सकता है।

Session Fixation

इस परिदृश्य में, एक हमलावर एक पीड़ित को एक विशिष्ट कुकी का उपयोग करके लॉग इन करने के लिए धोखा देता है। यदि एप्लिकेशन लॉगिन पर एक नई कुकी असाइन नहीं करता है, तो हमलावर, जिसके पास मूल कुकी है, पीड़ित का अनुकरण कर सकता है। यह तकनीक इस पर निर्भर करती है कि पीड़ित हमलावर द्वारा प्रदान की गई कुकी के साथ लॉग इन करता है।

यदि आपने एक XSS एक उपडोमेन में पाया है या आप एक उपडोमेन को नियंत्रित करते हैं, पढ़ें:

Cookie Tossing

Session Donation

यहाँ, हमलावर पीड़ित को हमलावर की सत्र कुकी का उपयोग करने के लिए मनाता है। पीड़ित, यह मानते हुए कि वे अपने खाते में लॉग इन हैं, अनजाने में हमलावर के खाते के संदर्भ में क्रियाएँ करेगा।

यदि आपने एक XSS एक उपडोमेन में पाया है या आप एक उपडोमेन को नियंत्रित करते हैं, पढ़ें:

Cookie Tossing

JWT Cookies

JWT में संभावित दोषों को समझाने वाले पृष्ठ तक पहुँचने के लिए पिछले लिंक पर क्लिक करें।

कुकीज़ में उपयोग किए जाने वाले JSON वेब टोकन (JWT) भी कमजोरियाँ प्रस्तुत कर सकते हैं। संभावित दोषों और उन्हें शोषित करने के तरीकों के बारे में गहन जानकारी के लिए, JWT हैकिंग पर लिंक किए गए दस्तावेज़ तक पहुँचने की सिफारिश की जाती है।

Cross-Site Request Forgery (CSRF)

यह हमला एक लॉग इन उपयोगकर्ता को एक वेब एप्लिकेशन पर अवांछित क्रियाएँ निष्पादित करने के लिए मजबूर करता है जिसमें वे वर्तमान में प्रमाणित हैं। हमलावर उन कुकीज़ का लाभ उठा सकते हैं जो स्वचालित रूप से कमजोर साइट के साथ हर अनुरोध के साथ भेजी जाती हैं।

Empty Cookies

(अधिक विवरण के लिए मूल शोध देखें) ब्राउज़र बिना नाम वाली कुकीज़ बनाने की अनुमति देते हैं, जिसे JavaScript के माध्यम से इस प्रकार प्रदर्शित किया जा सकता है:

document.cookie = "a=v1"
document.cookie = "=test value;" // Setting an empty named cookie
document.cookie = "b=v2"

संदेश में भेजे गए कुकी हेडर का परिणाम a=v1; test value; b=v2; है। दिलचस्प बात यह है कि यदि एक खाली नाम की कुकी सेट की जाती है, तो यह कुकीज़ में हेरफेर की अनुमति देती है, संभावित रूप से अन्य कुकीज़ को एक विशिष्ट मान सेट करके नियंत्रित करने की अनुमति देती है:

function setCookie(name, value) {
document.cookie = `${name}=${value}`;
}

setCookie("", "a=b"); // Setting the empty cookie modifies another cookie's value

यह ब्राउज़र को एक कुकी हेडर भेजने की ओर ले जाता है जिसे हर वेब सर्वर द्वारा a नामक कुकी के रूप में और b मान के साथ व्याख्यायित किया जाता है।

Chrome बग: यूनिकोड सरोगेट कोडपॉइंट समस्या

Chrome में, यदि एक यूनिकोड सरोगेट कोडपॉइंट सेट कुकी का हिस्सा है, तो document.cookie भ्रष्ट हो जाता है, जिसके परिणामस्वरूप एक खाली स्ट्रिंग लौटती है:

document.cookie = "\ud800=meep";

यह document.cookie को एक खाली स्ट्रिंग आउटपुट करने का परिणाम है, जो स्थायी भ्रष्टाचार को इंगित करता है।

पार्सिंग समस्याओं के कारण कुकी स्मगलिंग

(अधिक विवरण के लिए मूल शोध देखें) कई वेब सर्वर, जिनमें Java (Jetty, TomCat, Undertow) और Python (Zope, cherrypy, web.py, aiohttp, bottle, webob) शामिल हैं, पुराने RFC2965 समर्थन के कारण कुकी स्ट्रिंग्स को गलत तरीके से संभालते हैं। वे एक डबल-क्वोटेड कुकी मान को एकल मान के रूप में पढ़ते हैं, भले ही इसमें सेमीकोलन शामिल हों, जो सामान्यतः कुंजी-मूल्य जोड़ों को अलग करना चाहिए:

RENDER_TEXT="hello world; JSESSIONID=13371337; ASDF=end";

कुकी इंजेक्शन कमजोरियाँ

(अधिक विवरण के लिए मूल शोध देखें) सर्वरों द्वारा कुकीज़ का गलत पार्सिंग, विशेष रूप से Undertow, Zope, और जो Python के http.cookie.SimpleCookie और http.cookie.BaseCookie का उपयोग करते हैं, कुकी इंजेक्शन हमलों के लिए अवसर पैदा करता है। ये सर्वर नए कुकीज़ की शुरुआत को सही तरीके से सीमित नहीं करते, जिससे हमलावरों को कुकीज़ को स्पूफ करने की अनुमति मिलती है:

  • Undertow एक उद्धृत मान के तुरंत बाद एक नए कुकी की अपेक्षा करता है बिना सेमीकोलन के।

  • Zope अगली कुकी को पार्स करने के लिए एक अल्पविराम की तलाश करता है।

  • Python की कुकी कक्षाएँ एक स्पेस कैरेक्टर पर पार्सिंग शुरू करती हैं।

यह कमजोरी विशेष रूप से उन वेब अनुप्रयोगों में खतरनाक है जो कुकी-आधारित CSRF सुरक्षा पर निर्भर करते हैं, क्योंकि यह हमलावरों को स्पूफ किए गए CSRF-टोकन कुकीज़ इंजेक्ट करने की अनुमति देती है, जिससे सुरक्षा उपायों को बायपास किया जा सकता है। समस्या Python के डुप्लिकेट कुकी नामों के प्रबंधन से बढ़ जाती है, जहां अंतिम घटना पहले वाले को ओवरराइड करती है। यह असुरक्षित संदर्भों में __Secure- और __Host- कुकीज़ के लिए चिंताएँ भी उठाती है और जब कुकीज़ को बैक-एंड सर्वरों पर भेजा जाता है जो स्पूफिंग के प्रति संवेदनशील होते हैं, तो यह प्राधिकरण बायपास का कारण बन सकता है।

अतिरिक्त कमजोर कुकीज़ जांचें

बुनियादी जांचें

  • कुकी हर बार जब आप लॉगिन करते हैं तो एक जैसी होती है।

  • लॉग आउट करें और उसी कुकी का उपयोग करने की कोशिश करें।

  • एक ही खाते में 2 उपकरणों (या ब्राउज़रों) के साथ उसी कुकी का उपयोग करके लॉगिन करने का प्रयास करें।

  • जांचें कि क्या कुकी में कोई जानकारी है और इसे संशोधित करने का प्रयास करें।

  • लगभग समान उपयोगकर्ता नाम के साथ कई खाते बनाने का प्रयास करें और देखें कि क्या आप समानताएँ देख सकते हैं।

  • यदि "मुझे याद रखें" विकल्प मौजूद है, तो देखें कि यह कैसे काम करता है। यदि यह मौजूद है और कमजोर हो सकता है, तो हमेशा मुझे याद रखें की कुकी का उपयोग करें बिना किसी अन्य कुकी के।

  • जांचें कि क्या पिछले कुकी का काम करता है भले ही आप पासवर्ड बदल दें।

उन्नत कुकी हमले

यदि कुकी लॉगिन करते समय समान (या लगभग समान) रहती है, तो इसका मतलब शायद यह है कि कुकी आपके खाते के किसी क्षेत्र से संबंधित है (संभवतः उपयोगकर्ता नाम)। फिर आप कर सकते हैं:

  • बहुत सारे खाते बनाने का प्रयास करें जिनके उपयोगकर्ता नाम बहुत समान हैं और यह अनुमान लगाने की कोशिश करें कि एल्गोरिदम कैसे काम कर रहा है।

  • उपयोगकर्ता नाम को ब्रूटफोर्स करने का प्रयास करें। यदि कुकी केवल आपके उपयोगकर्ता नाम के लिए एक प्रमाणीकरण विधि के रूप में सहेजी जाती है, तो आप उपयोगकर्ता नाम "Bmin" के साथ एक खाता बना सकते हैं और अपनी कुकी के हर एक बिट को ब्रूटफोर्स कर सकते हैं क्योंकि आप जो कुकी आज़माएंगे उनमें से एक "admin" की होगी।

  • पैडिंग ओरकल का प्रयास करें (आप कुकी की सामग्री को डिक्रिप्ट कर सकते हैं)। पैडबस्टर का उपयोग करें।

पैडिंग ओरकल - पैडबस्टर उदाहरण

padbuster <URL/path/when/successfully/login/with/cookie> <COOKIE> <PAD[8-16]>
# When cookies and regular Base64
padbuster http://web.com/index.php u7bvLewln6PJPSAbMb5pFfnCHSEd6olf 8 -cookies auth=u7bvLewln6PJPSAbMb5pFfnCHSEd6olf

# If Base64 urlsafe or hex-lowercase or hex-uppercase --encoding parameter is needed, for example:
padBuster http://web.com/home.jsp?UID=7B216A634951170FF851D6CC68FC9537858795A28ED4AAC6
7B216A634951170FF851D6CC68FC9537858795A28ED4AAC6 8 -encoding 2

Padbuster कई प्रयास करेगा और आपसे पूछेगा कि कौन सी स्थिति त्रुटि स्थिति है (जो मान्य नहीं है)।

फिर यह कुकी को डिक्रिप्ट करना शुरू करेगा (इसमें कई मिनट लग सकते हैं)

यदि हमला सफलतापूर्वक किया गया है, तो आप अपनी पसंद की एक स्ट्रिंग को एन्क्रिप्ट करने की कोशिश कर सकते हैं। उदाहरण के लिए, यदि आप encrypt user=administrator करना चाहते हैं।

padbuster http://web.com/index.php 1dMjA5hfXh0jenxJQ0iW6QXKkzAGIWsiDAKV3UwJPT2lBP+zAD0D0w== 8 -cookies thecookie=1dMjA5hfXh0jenxJQ0iW6QXKkzAGIWsiDAKV3UwJPT2lBP+zAD0D0w== -plaintext user=administrator

यह निष्पादन आपको सही ढंग से एन्क्रिप्ट और एन्कोड किया गया कुकी देगा जिसमें स्ट्रिंग user=administrator शामिल है।

CBC-MAC

शायद एक कुकी में कुछ मान हो सकता है और इसे CBC का उपयोग करके साइन किया जा सकता है। फिर, मान की अखंडता वही हस्ताक्षर है जो उसी मान के साथ CBC का उपयोग करके बनाया गया है। चूंकि IV के रूप में शून्य वेक्टर का उपयोग करने की सिफारिश की जाती है, यह प्रकार की अखंडता जांच कमजोर हो सकती है।

हमला

  1. उपयोगकर्ता नाम administ का हस्ताक्षर प्राप्त करें = t

  2. उपयोगकर्ता नाम rator\x00\x00\x00 XOR t का हस्ताक्षर प्राप्त करें = t'

  3. कुकी में मान सेट करें 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" की कुकी होगी।

संदर्भ

Support HackTricks
PreviousCSP bypass: self + 'unsafe-inline' with IframesNextCookie Tossing

Last updated