Contrib.social

Anonymous render cache varied on session is now shared

Open on Drupal.org →
Created on 12 April 2024, 9 months ago
Updated 19 April 2024, 8 months ago

Problem/Motivation

This was originally reported to the security team who decided it could be public
If you have a piece of content which differs among anonymous users for some reason then in Drupal 8 and 9 you could just add the "session" cache context and it would be enough. Anonymous users had random session id, the cache context resolved to a random string and so the render cache ID derived from that differed too and so the render cache never actually hit.

But in Drupal 10, the session id is the empty string, the return value of the cache context is the encoded empty string which is a constant, the render cache ID is constant and so the render cache hits. This leads to information disclosure where the data of the first anonymous user to hit the site after a render cache clear will be served to everyone.

And yes, it can be argued it would've better to be explicit about what makes the content different between anonymous users but there was no need. Now there is. And the depreciation notice or error message does not make this self evident by far -- there's no mention of the session cache context in the first place.

Steps to reproduce

Proposed resolution

Disable caching when the session cache context is present but the session is not started. This matches the old behavior because in D8/D9 every page load got a new session id and so there was never a cache hit.

Remaining tasks

Write a test.

User interface changes

API changes

Data model changes

Release notes snippet

🐛 Bug report
Status

Active

Version

11.0 🔥

Component
Render  →

Last updated about 9 hours ago

Created by

🇦🇺Australia larowlan 🇦🇺🏝.au GMT+10

Live updates comments and jobs are added and updated live.
  • Security improvements

    It makes Drupal less vulnerable to abuse or misuse. Note, this is the preferred tag, though the Security tag has a large body of issues tagged to it. Do NOT publicly disclose security vulnerabilities; contact the security team instead. Anyone (whether security team or not) can apply this tag to security improvements that do not directly present a vulnerability e.g. hardening an API to add filtering to reduce a common mistake in contributed modules.

Sign in to follow issues

Comments & Activities

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024