1. Users are assigned a session cookie when they land on a PHP page. A CSRF token is associated with a session when users visit the login page.
2. Favicon requests were going to PHP instead of a static resource. Normally that's fine, since PHP will see the cookie.
3. But since the request looked like it was for a static resource, Varnish stripped the cookies before passing it back to Apache/PHP. That meant PHP issued a new session that replaced the old one.
All in all, a very tricky interaction between technologies (especially since Chrome didn't display the favicon request).
If Varnish strips cookies from all static resources, then simply embedding an <img> tag that points to a nonexisting image on the page should be able to destroy your session too, no? Sounds like a very dangerous setup.
Not a dangerous setup as much as a misconfigured one with dangerous side effects.
The problem is easily resolved by having Apache respond with a 404 to any requests for non-existant static resources. Which is of course what it should be doing in the first place.
1. Users are assigned a session cookie when they land on a PHP page. A CSRF token is associated with a session when users visit the login page.
2. Favicon requests were going to PHP instead of a static resource. Normally that's fine, since PHP will see the cookie.
3. But since the request looked like it was for a static resource, Varnish stripped the cookies before passing it back to Apache/PHP. That meant PHP issued a new session that replaced the old one.
All in all, a very tricky interaction between technologies (especially since Chrome didn't display the favicon request).