Cookie Bomb Analysis

Cookie Bomb Analysis

A cookie bomb is a Denial of Service (DoS) attack technique that involves adding a significant number of large cookies to a domain and its subdomains, causing the victim's browser to send oversized HTTP requests that get rejected by the server.

What This Skill Does

This skill helps you:

• Understand cookie bomb mechanics and attack vectors
• Analyze cookie sizes and request overhead
• Test for cookie bomb vulnerabilities in web applications
• Implement defensive measures against cookie-based DoS
• Generate reports on cookie-related security findings

When to Use This Skill

Use this skill when:

• You're conducting a security assessment and need to test for cookie-based DoS
• You're investigating HTTP request size issues or 400/413 errors
• You need to understand how cookies affect request headers
• You're reviewing third-party cookie implementations
• You're analyzing browser cookie behavior and limits
• You're documenting security findings related to HTTP headers

Cookie Bomb Mechanics

How It Works

1. Cookie Injection: An attacker sets multiple large cookies (often via XSS or compromised endpoints)
2. Request Bloat: Every HTTP request to the domain includes all cookies in the Cookie header
3. Server Rejection: When the request exceeds server limits, the server rejects it with 400/413 errors
4. Targeted DoS: The victim cannot access the site, but other users are unaffected

Key Characteristics

• Targeted: Only affects the specific user whose cookies were manipulated
• Persistent: Cookies remain until expiration or manual deletion
• Cross-subdomain: Cookies set on parent domains affect all subdomains
• Browser-dependent: Different browsers have different cookie size limits

Browser Cookie Limits

Attack Vectors

1. XSS-Based Cookie Bomb

// Attacker sets many large cookies via XSS
for (let i = 0; i < 100; i++) {
  document.cookie = `bomb${i}=${'x'.repeat(4000)}; path=/; domain=example.com`;
}

2. Reflected Cookie Injection

GET /set-cookie?name=evil&value=<large-value>

3. Third-Party Cookie Abuse

// Third-party script sets cookies on victim's domain
// Often via compromised ad networks or analytics

Detection and Analysis

Check Current Cookie Sizes

Use the analyze-cookies.sh script to measure cookie overhead:

./scripts/analyze-cookies.sh example.com

Manual Inspection

# Check cookie header size
curl -I https://example.com | grep -i cookie | wc -c

# View all cookies for a domain
# Chrome DevTools: Application > Cookies > example.com

Server-Side Detection

# Check request header sizes
if len(request.headers.get('Cookie', '')) > 8192:
    log_warning(f"Large cookie header: {len(request.headers['Cookie'])} bytes")

Defensive Measures

1. Limit Cookie Sizes

# Set maximum cookie size limits
MAX_COOKIE_SIZE = 4096  # 4KB

if len(cookie_value) > MAX_COOKIE_SIZE:
    raise ValueError("Cookie value too large")

2. Validate Cookie Sources

# Only allow cookies from trusted sources
ALLOWED_COOKIE_NAMES = ['session_id', 'user_pref', 'tracking_id']

for cookie_name in request.cookies:
    if cookie_name not in ALLOWED_COOKIE_NAMES:
        # Reject or sanitize
        pass

3. Implement Request Size Limits

# Nginx: Limit request header size
large_client_header_buffers 4 32k;
client_header_buffer_size 16k;

# Apache: Limit request body size
LimitRequestBody 1048576  # 1MB

4. Use HttpOnly and Secure Flags

# Set cookies with security flags
response.set_cookie(
    'session_id',
    value=session_token,
    httponly=True,
    secure=True,
    samesite='Strict'
)

5. Monitor for Anomalies

# Alert on unusual cookie patterns
if len(request.cookies) > 50:
    alert_security_team(f"Unusual cookie count: {len(request.cookies)}")

Testing Procedures

Step 1: Baseline Measurement

1. Clear all cookies for the target domain
2. Make a normal request and measure header size
3. Document baseline cookie count and sizes

Step 2: Cookie Injection Test

1. Attempt to set cookies via various vectors (XSS, API endpoints, etc.)
2. Measure resulting request sizes
3. Test server response to oversized requests

Step 3: Impact Assessment

1. Determine if the attack causes DoS for the affected user
2. Check if subdomains are affected
3. Verify cookie persistence and expiration behavior

Step 4: Mitigation Testing

1. Test proposed defensive measures
2. Verify they don't break legitimate functionality
3. Document any trade-offs

Reporting Findings

Severity Classification

Report Template

## Cookie Bomb Vulnerability

**Severity**: Medium
**CVSS Score**: 5.3 (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L)

### Description
The application does not validate cookie sizes or sources, allowing an attacker to inject large cookies that cause HTTP request rejection.

### Impact
- Targeted Denial of Service for affected users
- Potential for cross-subdomain impact
- User experience degradation

### Proof of Concept
[Include test results and evidence]

### Remediation
1. Implement cookie size validation
2. Add request header size limits
3. Monitor for anomalous cookie patterns
4. Use HttpOnly and Secure flags

Related Techniques

• HTTP Request Smuggling: Similar header manipulation attacks
• Header Injection: Attacking other HTTP headers
• Cache Poisoning: Exploiting header-based caching
• XSS: Often the vector for cookie injection

References

• HackerOne Report #57356 - Real-world cookie bomb example
• The Cookie Monster in Your Browsers - Technical presentation
• OWASP Cookie Best Practices
• MDN: Document.cookie

Scripts

This skill includes the following scripts:

• scripts/analyze-cookies.sh - Analyze cookie sizes and overhead
• scripts/simulate-cookie-bomb.py - Educational simulation (use responsibly)
• scripts/check-cookie-limits.py - Check browser cookie limits

Run ./scripts/analyze-cookies.sh --help for usage information.

Responsible Use

Important: Cookie bomb testing should only be performed:

• On systems you own or have explicit authorization to test
• In controlled environments
• With proper scope and rules of engagement
• For defensive purposes only

Never use these techniques against systems without permission. Unauthorized DoS testing is illegal and unethical.