Cookies Hacking

Reading time: 18 minutes

Cookie Attributes

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

Expires and Max-Age

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

Domain

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

Path

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

Ordering Rules

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

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

SameSite

• SameSite विशेषता यह निर्धारित करती है कि क्या कुकीज़ तीसरे पक्ष के डोमेन से उत्पन्न अनुरोधों पर भेजी जाती हैं। यह तीन सेटिंग्स प्रदान करती है:
• Strict: तीसरे पक्ष के अनुरोधों पर कुकी को भेजने से रोकता है।
• Lax: तीसरे पक्ष की वेबसाइटों द्वारा आरंभ किए गए GET अनुरोधों के साथ कुकी को भेजने की अनुमति देता है।
• 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

अनुरोध केवल तभी कुकी भेजेगा जब अनुरोध एक सुरक्षित चैनल (आमतौर पर 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";

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

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

• Undertow एक उद्धृत मान के तुरंत बाद एक नई कुकी की अपेक्षा करता है बिना सेमीकोलन के।
• Zope अगली कुकी को पार्स करने के लिए एक अल्पविराम की तलाश करता है।
• Python की कुकी कक्षाएँ एक स्पेस कैरेक्टर पर पार्सिंग शुरू करती हैं।

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

कुकीज़ $version

WAF बायपास

इस ब्लॉगपोस्ट के अनुसार, यह संभव हो सकता है कि कुकी विशेषता $Version=1 का उपयोग करके बैकएंड को कुकी पार्स करने के लिए पुरानी लॉजिक का उपयोग करने के लिए मजबूर किया जा सके, RFC2109 के कारण। इसके अलावा, अन्य मान जैसे $Domain और $Path का उपयोग बैकएंड के व्यवहार को कुकी के साथ संशोधित करने के लिए किया जा सकता है।

कुकी सैंडविच हमला

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

• एक जगह खोजें जहाँ एक स्पष्ट रूप से बेकार कुकी प्रतिक्रिया में परिलक्षित होती है
• $Version नाम की एक कुकी बनाएं जिसका मान 1 हो (आप इसे JS से XSS हमले में कर सकते हैं) एक अधिक विशिष्ट पथ के साथ ताकि यह प्रारंभिक स्थिति प्राप्त कर सके (कुछ फ्रेमवर्क जैसे Python को इस कदम की आवश्यकता नहीं होती)
• उस कुकी को बनाएं जो परिलक्षित होती है जिसका मान खुले डबल कोट्स को छोड़ता है और एक विशिष्ट पथ के साथ ताकि यह पिछले वाले ($Version) के बाद कुकी डेटाबेस में स्थित हो
• फिर, वैध कुकी क्रम में अगली होगी
• एक डमी कुकी बनाएं जो डबल कोट्स को अपने मान के अंदर बंद करती है

इस तरह, पीड़ित कुकी नए कुकी संस्करण 1 के अंदर फंस जाती है और जब भी यह परिलक्षित होती है, यह परिलक्षित हो जाएगी। e.g. from the post:

document.cookie = `$Version=1;`;
document.cookie = `param1="start`;
// any cookies inside the sandwich will be placed into param1 value server-side
document.cookie = `param2=end";`;

WAF बायपास

कुकीज़ $version

पिछले अनुभाग की जांच करें।

उद्धृत-स्ट्रींग एन्कोडिंग के साथ मान विश्लेषण को बायपास करना

यह पार्सिंग कुकीज़ के अंदर एस्केप किए गए मानों को अनएस्केप करने का संकेत देती है, इसलिए "\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 के बराबर के चिन्ह के पहले और बाद में स्पेस हटा दिया गया है।

कुकी विभाजन के साथ मान विश्लेषण को बायपास करना

अंत में, विभिन्न बैकडोर विभिन्न कुकी हेडर में पास की गई विभिन्न कुकीज़ को एक स्ट्रिंग में जोड़ेंगे जैसे:

GET / HTTP/1.1
Host: example.com
Cookie: param1=value1;
Cookie: param2=value2;

जो एक WAF को बायपास करने की अनुमति दे सकता है जैसे कि इस उदाहरण में:

Cookie: name=eval('test//
Cookie: comment')

Resulting cookie: name=eval('test//, comment') => allowed

अतिरिक्त संवेदनशील कुकीज जांच

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

• कुकी हर बार जब आप लॉगिन करते हैं, एक जैसी होती है।
• लॉग आउट करें और उसी कुकी का उपयोग करने की कोशिश करें।
• एक ही खाते में 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" की कुकी होगी।

संदर्भ

• https://blog.ankursundara.com/cookie-bugs/
• https://www.linkedin.com/posts/rickey-martin-24533653_100daysofhacking-penetrationtester-ethicalhacking-activity-7016286424526180352-bwDd
• https://portswigger.net/research/bypassing-wafs-with-the-phantom-version-cookie