Hindi - Ht

Cookies Hacking

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

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

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

LogoJoin the Try Hard Security Discord Server!Discord

कुकी गुण

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

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

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

डोमेन

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

पथ

Path गुणवत्ता द्वारा उक्त URL पथ को निर्दिष्ट किया जाता है जो Cookie हेडर भेजने के लिए अनुरोधित 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 विधि उपलब्ध है) कुकी भेजेगी। इस तकनीक को क्रॉस-साइट ट्रैकिंग कहा जाता है।

  • यह तकनीक आधुनिक ब्राउज़र्स द्वारा TRACE अनुरोध भेजने की अनुमति न देने से बचाई जाती है। हालांकि, कुछ बायपास इसके लिए मिले हैं जैसे कि IE6.0 SP2 में TRACE के बजाय \r\nTRACE भेजना।

  • दूसरा तरीका है ब्राउज़रों के जीरो/डे वलनरेबिलिटी का शोषण करना।

  • कुकी जार में ओवरराइट करना संभव है HttpOnly कुकीज को कुकी

कुकी को अधिलेखित करना

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

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

कुकी हमले

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

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

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

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

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

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

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

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

pageCookie Tossing

सत्र दान

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

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

pageCookie Tossing

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 डिवाइस (या ब्राउज़र्स) का उपयोग करके एक ही कुकी का उपयोग करके एक ही खाते में लॉग इन करने का प्रयास करें।

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

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

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

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

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

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

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

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

यदि कुकी ईसीबी का उपयोग करके एन्क्रिप्ट किया गया है तो यह कमजोर हो सकता है। जब आप लॉग इन करते हैं तो आपको मिलने वाली कुकी हमेशा एक ही होनी चाहिए।

कैसे पता लगाएं और हमला करें:

लगभग समान डेटा (उपयोगकर्ता नाम, पासवर्ड, ईमेल, आदि) के साथ 2 उपयोगकर्ता बनाएं और दी गई कुकी में कोई पैटर्न खोजने की कोशिश करें

उदाहरण के लिए "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" नाम के एक उपयोगकर्ता बनाएं और देखें कि क्या कुकी में कोई पैटर्न है (क्योंकि ECB हर ब्लॉक के साथ समान कुंजी का उपयोग करके एन्क्रिप्ट करता है, अगर उपयोगकर्ता नाम एन्क्रिप्ट होता है तो समान एन्क्रिप्टेड बाइट्स दिख सकते हैं)।

एक पैटर्न होना चाहिए (एक उपयोग किए गए ब्लॉक के आकार के साथ)। तो, जानते हुए कि कितने "a" एन्क्रिप्ट होते हैं, आप एक उपयोगकर्ता नाम बना सकते हैं: "a"*(ब्लॉक का आकार)+"admin"। फिर, आप "a" के एक ब्लॉक के एन्क्रिप्टेड पैटर्न को कुकी से हटा सकते हैं। और आपके पास उपयोगकर्ता नाम "admin" की कुकी होगी।

संदर्भ

Try Hard Security Group

LogoJoin the Try Hard Security Discord Server!Discord
htARTE (HackTricks AWS Red Team Expert) के साथ शून्य से हीरो तक AWS हैकिंग सीखें!

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

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

Last updated