Security: Sprockets sends Set-Cookie headers with asset responses, enabling Web Cache Deception attacks

[Akashkarmakar787]

As requested, moving the issue to sprockets from rails project: rails/rails#55477

Summary

Sprockets serves asset files (e.g., /assets/*.js, /assets/*.css) with Set-Cookie headers, which can be cached by CDNs. This enables Web Cache Deception attacks where attackers can steal user sessions.

Security Impact

Severity: High
Attack Vector: Web Cache Deception
Affected: Applications using Sprockets + CDN (especially CloudFront)

When a logged-in user requests an asset, Sprockets includes the session cookie in the response. If a CDN caches this response (including the Set-Cookie header), an attacker can:

1. Trick a victim to visit an asset URL (e.g., via phishing)
2. The CDN caches the victim's session cookie
3. Attacker requests the same URL and receives the cached session
4. Attacker hijacks the victim's session

Real-World Scenario

Victim (logged in) visits
GET /assets/application-abc123.js
Cookie: myapp_session=victim_session_cookie

Rails + Sprockets responds
HTTP/1.1 200 OK
Content-Type: application/javascript
Set-Cookie: myapp_session=victim_session_cookie; path=/; HttpOnly
Cache-Control: public, max-age=31536000

CloudFront caches this response INCLUDING Set-Cookie
Attacker requests same URL
GET /assets/application-abc123.js
CloudFront returns cached response with victim's session
HTTP/1.1 200 OK (from cache)
Set-Cookie: myapp_session=victim_session_cookie; path=/; HttpOnly

Root Cause
Asset requests go through the full Rails middleware stack, including ActionDispatch::Cookies and ActionDispatch::Session::CookieStore, which set session cookies even for static assets.