How Massive Cookies Can Hijack Sites: Exploiting Cookie Attributes for DoS

This article demonstrates how oversized cookies and their attributes—expires, domain, path, and protocol—can be abused to inflate HTTP headers, trigger server‑side request‑size limits, and launch stealthy denial‑of‑service attacks via XSS and man‑in‑the‑middle techniques.

Java Backend Technology
Java Backend Technology
Java Backend Technology
How Massive Cookies Can Hijack Sites: Exploiting Cookie Attributes for DoS

Overview

When a website stores an excessive number of large cookies, the HTTP request header grows dramatically, often exceeding server limits and causing the site to become inaccessible for users who retain those cookies.

Cookie Size Attack

for (i = 0; i < 20; i++)
    document.cookie = i + '=' + 'X'.repeat(2000);

The script above creates twenty cookies, each 2 KB in size, quickly inflating the request header.

Persistence via expires

Cookies remain until their expires attribute passes. By setting a far‑future expiration date, the polluted cookies persist for months, effectively blocking access to the target site for that duration.

Domain Attribute

The domain attribute allows a sub‑site to write a cookie for its parent domain (e.g., .cnblogs.com), affecting all subdomains. Consequently, any request to *.cnblogs.com carries the oversized cookie, causing a site‑wide outage.

Path Attribute

for (i = 0; i < 20; i++)
    document.cookie = i + '=' + 'X'.repeat(2000) + ";domain=cnblogs.com; path=/mvc/vote/VoteComment.aspx";

By limiting the cookie to a specific path, only targeted URLs (e.g., the voting endpoint) are disrupted, making the attack harder to detect.

Protocol Sharing

Unless the secure flag is set, cookies are shared between HTTP and HTTPS. An attacker can therefore block HTTPS resources from an HTTP context.

Man‑in‑the‑Middle (MITM) Exploitation

When traffic is intercepted, a MITM can inject scripts into any HTTP page, create hidden iframes pointing to the target site, and set malicious cookies across domains, persisting the denial‑of‑service effect even after normal network conditions resume.

Practical Uses

Block user‑profile modification pages to prevent password changes.

Disable logout endpoints, keeping sessions alive.

Temporarily disable admin panels during blind XSS attacks.

Interfere with front‑end security checks, reducing overall user safety.

Prevent updates from software or patch distribution sites.

Conclusion

Although this technique does not harm the actual server, it creates a localized denial‑of‑service that affects only the targeted users or functionalities, offering a subtle yet effective way to disrupt web services.

Original Source

Signed-in readers can open the original source through BestHub's protected redirect.

Sign in to view source
Republication Notice

This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactadmin@besthub.devand we will review it promptly.

MITMXSSweb securitycookiepathdomainDenial of Service
Java Backend Technology
Written by

Java Backend Technology

Focus on Java-related technologies: SSM, Spring ecosystem, microservices, MySQL, MyCat, clustering, distributed systems, middleware, Linux, networking, multithreading. Occasionally cover DevOps tools like Jenkins, Nexus, Docker, and ELK. Also share technical insights from time to time, committed to Java full-stack development!

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.