hacktricks/pentesting-web/hacking-with-cookies

Cookies Hacking

जानें AWS हैकिंग को शून्य से हीरो तक htARTE (HackTricks AWS Red Team Expert) के साथ!

HackTricks का समर्थन करने के अन्य तरीके:

• अगर आप अपनी कंपनी का विज्ञापन HackTricks में देखना चाहते हैं या HackTricks को PDF में डाउनलोड करना चाहते हैं तो सदस्यता योजनाएं देखें!
• आधिकारिक PEASS और HackTricks swag प्राप्त करें
• हमारे विशेष NFTs संग्रह, The PEASS Family की खोज करें
• शामिल हों 💬 डिस्कॉर्ड समूह या टेलीग्राम समूह या हमें ट्विटर 🐦 @carlospolopm** पर फॉलो** करें।
• हैकिंग ट्रिक्स साझा करें द्वारा PRs सबमिट करके HackTricks और HackTricks Cloud github repos में।

Try Hard सुरक्षा समूह

{% embed url="https://discord.gg/tryhardsecurity" %}

---

कुकी गुण

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

समाप्त होने और अधिकतम आयु

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

डोमेन

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

पथ

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

क्रमवारी नियम

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

• उपयोगकर्ता द्वारा अनुरोधित URL में सबसे लंबा पथ मिलाने वाली कुकी।
• यदि पथ समान है, तो सबसे हाल ही में सेट की गई कुकी।

SameSite

• SameSite गुणवत्ता निर्धारित करती है कि क्या कुकी तृतीय-पक्ष डोमेन से उत्पन्न अनुरोधों पर भेजी जाएगी। यह तीन सेटिंग्स प्रदान करता है:
• सख्त: कुकी को तृतीय-पक्ष अनुरोधों पर भेजने से रोकता है।
• लैक्स: तृतीय-पक्ष वेबसाइटों द्वारा प्रारंभित GET अनुरोधों के साथ कुकी भेजने की अनुमति देता है।
• कोई नहीं: कुकी को किसी भी तृतीय-पक्ष डोमेन से भेजने की अनुमति देता है।

ध्यान रखें, कुकी को कॉन्फ़िगर करते समय, इन गुणों को समझना सुनिश्चित कर सकता है कि वे विभिन्न परिस्थितियों में उम्मीद के अनुसार व्यवहार करें।

अनुरोध प्रकार	उदाहरण कोड	कुकी भेजी जाती है जब
लिंक	<a href="..."></a>	NotSet*, Lax, None
प्रीरेंडर	<link rel="prerender" href=".."/>	NotSet*, Lax, None
फॉर्म GET	<form method="GET" action="...">	NotSet*, Lax, None
फॉर्म POST	<form method="POST" action="...">	NotSet*, None
आइफ्रेम	<iframe src="..."></iframe>	NotSet*, None
AJAX	$.get("...")	NotSet*, None
छवि	<img src="...">	NetSet*, None

टेबल Invicti से है और थोड़ा संशोधित किया गया है।
SameSite गुणवत्ता वाली कुकी CSRF हमलों को रोकेगी जहां एक लॉग इन सत्र की आवश्यकता है।

*ध्यान दें कि Chrome80 (फरवरी/2019) से एक कुकी का डिफ़ॉल्ट व्यवहार जब कोई कुकी samesite गुणवत्ता के बिना होगा तो वह lax होगा (https://www.troyhunt.com/promiscuous-cookies-and-their-impending-death-via-the-samesite-policy/)।
ध्यान दें कि अस्थायी रूप से, इस परिवर्तन को लागू करने के बाद, Chrome में SameSite गुणवत्ता के बिना कुकी पहले 2 मिनट के लिए None के रूप में और फिर शीर्ष-स्तरीय क्रॉस-साइट POST अनुरोध के लिए Lax के रूप में व्यवहार किया जाएगा।

कुकी ध्वज

HttpOnly

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

बायपास

• अगर पृष्ठ कुकी को अनुरोध के रूप में भेज रहा है (उदाहरण के लिए PHPinfo पृष्ठ में), तो XSS का दुरुपयोग करके इस पृष्ठ को अनुरोध भेजने और प्रतिक्रिया से कुकी चुरा सकते हैं (उदाहरण के लिए https://hackcommander.github.io/posts/2022/11/12/bypass-httponly-via-php-info-page/ में एक उदाहरण देखें)।
• इसे TRACE HTTP अनुरोधों के रूप में बायपास किया जा सकता है (यदि यह HTTP विधि उपलब्ध है) क्योंकि सर्वर से प्रतिक्रिया (यदि यह HTTP विधि उपलब्ध है) कुकी भेजी जाएगी। इस तकनीक को क्रॉस-साइट ट्रैकिंग कहा जाता है।
• यह तकनीक आधुनिक ब्राउज़र्स द्वारा TRACE अनुरोध भेजने की अनुमति न देने के द्वारा रोकी जाती है। हालांकि, कुछ बायपास इसके लिए विशेष सॉफ़्टवेयर में मिले हैं जैसे IE6.0 SP2 में TRACE के बजाय \r\nTRACE भेजना।
• एक और तरीका है ब्राउज़रों के जीरो/डे विकल्पों का श

कुकी को ओवरराइट करना

इसलिए, __Host- प्रिफिक्स कुकी की सुरक्षा में एक होती है कि उन्हें सबडोमेन से ओवरराइट नहीं किया जा सकता है। उदाहरण के लिए कुकी टॉसिंग हमलों को रोकना। टॉक में कुकी क्रम्बल्स: वेब सेशन अखंडता सुरक्षा की पर्दाफाश (पेपर) प्रस्तुत किया गया है कि सबडोमेन से __HOST- प्रिफिक्स कुकी को सेट करना संभव था, पार्सर को धोखा देकर, उदाहरण के लिए, "=" को शुरुआत या शुरुआत और अंत में जोड़कर...:

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

कुकी हमले

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

कुकी को डिकोड और मेनिपुलेट करना

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

सत्र हाइजैकिंग

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

सत्र निश्चित करना

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

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

{% content-ref url="cookie-tossing.md" %} cookie-tossing.md {% endcontent-ref %}

सत्र दान

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

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

{% content-ref url="cookie-tossing.md" %} cookie-tossing.md {% endcontent-ref %}

JWT कुकी

पूर्ववत लिंक पर क्लिक करें ताकि JWT में संभावित दोषों की व्याख्या करने वाले पृष्ठ तक पहुंच सकें।

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

क्रॉस-साइट अनुरोध धोखाधड़ी (CSRF)

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

खाली कुकी

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

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

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

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

document.cookie = "\ud800=meep";

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

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

(अधिक विवरण के लिए मूल शोध देखें) कई वेब सर्वर, जैसे कि जावा (Jetty, TomCat, Undertow) और पायथन (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 एक quoted value के बाद बिना semicolon के तुरंत एक नई कुकी की उम्मीद करता है।
• Zope अगली कुकी को पार्स करने के लिए एक comma की तलाश करता है।
• Python की कुकी क्लासेस एक space character पर पार्सिंग शुरू करती हैं।

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

अतिरिक्त सुरक्षित कुकी जांचें

मौलिक जांचें

• कुकी हर बार लॉगिन करने पर एक समान है।
• लॉग आउट करें और उसी कुकी का उपयोग करने का प्रयास करें।
• 2 डिवाइस (या ब्राउज़र्स) का उपयोग करके एक ही कुकी का उपयोग करके एक ही खाते में लॉगिन करने का प्रयास करें।
• देखें कि क्या कुकी में कोई जानकारी है और उसे संशोधित करने का प्रयास करें
• लगभग समान उपयोगकर्ता नाम वाले कई खाते बनाने का प्रयास करें और देखें कि क्या आप समानताएँ देख सकते हैं।
• अगर remember me विकल्प है तो उसे देखें कि यह कैसे काम करता है। अगर यह मौजूद है और यह संवेदनशील हो सकता है, तो हमेशा remember me की कुकी का उपयोग करें बिना किसी अन्य कुकी के।
• पासवर्ड बदलने के बाद भी पिछली कुकी काम करती है या नहीं, यह देखें।

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

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

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

Padding Oracle - Padbuster उदाहरण

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 कई प्रयास करेगा और आपसे पूछेगा कि त्रुटि स्थिति कौन सी है (जो मान्य नहीं है)।

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

यदि हमला सफलतापूर्वक किया गया है, तो आपको अपनी पसंद के एक स्ट्रिंग को एन्क्रिप्ट करने की कोशिश कर सकते हैं। उदाहरण के लिए, यदि आप 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" की कुकी होगी।

संदर्भ

• https://blog.ankursundara.com/cookie-bugs/
• https://www.linkedin.com/posts/rickey-martin-24533653_100daysofhacking-penetrationtester-ethicalhacking-activity-7016286424526180352-bwDd

Try Hard Security Group

{% embed url="https://discord.gg/tryhardsecurity" %}

Learn AWS hacking from zero to hero with htARTE (HackTricks AWS Red Team Expert)!

Other ways to support HackTricks:

• If you want to see your company advertised in HackTricks or download HackTricks in PDF Check the SUBSCRIPTION PLANS!
• Get the official PEASS & HackTricks swag
• Discover The PEASS Family, our collection of exclusive NFTs
• Join the 💬 Discord group or the telegram group or follow us on Twitter 🐦 @carlospolopm.
• Share your hacking tricks by submitting PRs to the HackTricks and HackTricks Cloud github repos.