hacktricks/pentesting-web/hacking-with-cookies

कुकीज हैकिंग

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

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

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

वे सुरक्षितता खोजें जो सबसे महत्वपूर्ण हैं ताकि आप उन्हें तेजी से ठीक कर सकें। Intruder आपकी हमले की सतह का ट्रैक करता है, प्रोएक्टिव धारणा स्कैन चलाता है, आपकी पूरी तकनीकी स्टैक, API से वेब ऐप्स और क्लाउड सिस्टम तक मुद्दे खोजता है। आज ही मुफ्त में इसका प्रयास करें।

{% embed url="https://www.intruder.io/?utm_campaign=hacktricks&utm_source=referral" %}

---

कुकीज गुण

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

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

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

डोमेन

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

पथ

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

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

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

• अनुरोधित 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 विधि उपलब्ध है) कुकीज भेजेगी। इस तकनीक को क्रॉस-साइट ट्रैकिंग

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 डिवाइस (या ब्राउज़र) से एक ही खाते में लॉग इन करने का प्रयास करें।
• देखें कि क्या कुकी में कोई जानकारी है और उसे संशोधित करने का प्रयास करें
• लगभग समान उपयोगकर्ता नाम वाले कई खाते बनाने का प्रयास करें और देखें कि क्या आप समानताएँ देख सकते हैं।
• अगर यह मौजूद है, तो "मुझे याद रखें" विकल्प की जांच करें कि यह कैसे काम करता है। अगर यह मौजूद है और यह संकटग्रस्त हो सकता है, तो हमेशा याद रखें की कुकी का उपयोग करें बिना किसी अन्य कुकी के साथ।
• पासवर्ड बदलने के बाद भी पिछली कुकी काम करती है या नहीं, यह जांचें।

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

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

• बहुत सारे खाते उपयोगकर्ता नामों के साथ बनाएं और यह देखने का प्रयास करें कि एल्गोरिथ्म कैसे काम कर रहा है।
• उपयोगकर्ता नाम को ब्रूटफोर्स करने का प्रयास करें। यदि कुकी केवल आपके उपयोगकर्ता नाम के लिए प्रमाणीकरण विधि के रूप में सहेजती है, तो आप उपयोगकर्ता नाम "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 कई प्रयास करेगा और आपसे पूछेगा कि त्रुटि स्थिति कौन सी है (जो मान्य नहीं है)।

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

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

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

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

CBC-MAC

शायद किसी कुकी में कुछ मूल्य हो सकता है और यह सीबीसी का उपयोग करके हस्ताक्षरित किया जा सकता है। फिर, मूल्य की अखंडता उस हस्ताक्षर के द्वारा है जो सीबीसी का उपयोग करके एक ही मूल्य के साथ बनाया गया है। जैसा कि 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" की कुकी होगी।