CF caching a script when it shouldn't

I have a script in the /home/example/www/includes/ directory that is included (via PHP) on every page. This script reads a cookie, and then does a MySQL query based on the value of that cookie.

Every once in awhile I’ll have a server issue (sometimes a load spike, sometimes the /tmp directory gets full and cPanel crashes), and when that happens the script shows cached information instead of reading the cookie. This is a HUGE security issue! I might be logged in with my own username, but the data is shows is for a different user that just happened to get cached by CF!

Worse, after the server crisis is over, the problem doesn’t go away :open_mouth: I even paused CF entirely, and the users are still experiencing the same issue.

My site is over 20 years old, and this problem only began when I started using Cloudflare.

Under Caching > Cache Rules, I have a rule set up to Bypass Cache when:

(starts_with(http.request.uri.path, “/cgi-bin”)) or
(starts_with(http.request.uri.path, “/includes”)) or
(starts_with(http.request.uri.path, “/chat”)) or
(http.request.uri.path contains “/cpanel/”) or
(starts_with(http.request.uri.path, “:2083”)) or
(starts_with(http.request.uri.query, “h=”)) or
(http.request.uri.query contains “&h=”)

Any other suggestions?

This is becoming a huge issue, and I have no idea how to fix it. Clearing cache and disabling CF on the account has no impact.

I tried to purge this URL, but it also didn’t help:

https://www.example.com/cgi-bin/chat.cgi

The actual link that’s being cached (when it shouldn’t be) has a bunch of params that look like this:

https://www.example.com/cgi-bin/chat.cgi?process=login&username=foo&h=20240320140735

Did purging chat.cgi purge the caching of any params?

If Cloudflare is paused, requests go direct to your origin so there can be no Cloudflare cached items returned.

What is the site?

GoIredell.com. The page is Chat Room :: GoIredell - The Community Website for Mooresville, Statesville, Harmony, Love Valley, and Troutman

When the user submits the form to log in, it originally plugged in the date and time from a PHP variable; eg,

$date = 20240317141414;
‘…&h=$date’;

I change it so that the number is created via JavaScript; eg,

‘…&h=’ + new Date().getTime();

The h parameter that’s ACTUALLY being sent by the user, though, is still the same number from 4 days ago. Meaning that /chat/ is being loaded from cache.

I’ve purged every variation I can think of (/chat, /chat/, /chat/index.php), but nothing has helped.

I also had the user add a dummy param, like so:

/chat/?z=1

but that also didn’t help.

I haven’t been able to duplicate it on my end, but several users have had the same problem. So I’m stuck troubleshooting based on what information they can give me :-/

As you said, the site isn’t proxied (due to being paused) so Cloudflare’s cache plays no part in this.
https://cf.sjr.org.uk/tools/check?02512c96153c4409b7236687e4dfcdf2#dns

Seems you are using Ezoic’s CDN.

I have turned off the proxy with Ezoic, but it didn’t help. At this point I have purged the cache for the site completely, I have paused Cloudflare, and I have it in Development Mode.

I’ve discovered another symptom of the same problem that might help to figure out the issue. I have a cookie set of:

user=GoNC

In Chrome, I’ve confirmed under Console > Application > Cookies that the only cookie that exists for “user” has the value of “GoNC”.

All of the PHP scripts have a line that looks like this:

echo $_COOKIE[‘user’];

This consistently shows another user’s username; NOT the expected value of “GoNC”.

Shift+F5 doesn’t help.

If I delete the cookie altogether, $_COOKIE[‘user’] is blank (as it should be). But then when I recreate the cookie, it goes back to the other user’s username instead of the value I’ve entered.

The site is not being proxied by Cloudflare now so if there is a caching issue it’s either local cache or something on the origin server.

curl -Ikv https://www.goiredell.com/chat/
*   Trying 50.16.223.119:443...
* Connected to www.goiredell.com (50.16.223.119) port 443
* ALPN: curl offers h2,http/1.1
* (304) (OUT), TLS handshake, Client hello (1):
* (304) (IN), TLS handshake, Server hello (2):
* (304) (IN), TLS handshake, Unknown (8):
* (304) (IN), TLS handshake, Certificate (11):
* (304) (IN), TLS handshake, CERT verify (15):
* (304) (IN), TLS handshake, Finished (20):
* (304) (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / AEAD-CHACHA20-POLY1305-SHA256
* ALPN: server accepted h2
* Server certificate:
*  subject: CN=goiredell.com
*  start date: Mar 14 21:55:39 2024 GMT
*  expire date: Jun 12 21:55:38 2024 GMT
*  issuer: C=US; O=Let's Encrypt; CN=R3
*  SSL certificate verify ok.
* using HTTP/2
* [HTTP/2] [1] OPENED stream for https://www.goiredell.com/chat/
* [HTTP/2] [1] [:method: HEAD]
* [HTTP/2] [1] [:scheme: https]
* [HTTP/2] [1] [:authority: www.goiredell.com]
* [HTTP/2] [1] [:path: /chat/]
* [HTTP/2] [1] [user-agent: curl/8.4.0]
* [HTTP/2] [1] [accept: */*]
> HEAD /chat/ HTTP/2
> Host: www.goiredell.com
> User-Agent: curl/8.4.0
> Accept: */*
> 
< HTTP/2 403 
HTTP/2 403 
< cache-control: private, max-age=0, must-revalidate, no-cache, no-store
cache-control: private, max-age=0, must-revalidate, no-cache, no-store
< content-type: text/html; charset=iso-8859-1
content-type: text/html; charset=iso-8859-1
< date: Fri, 22 Mar 2024 17:42:30 GMT
date: Fri, 22 Mar 2024 17:42:30 GMT
< display: staticcontent_sol, orig_site_sol
display: staticcontent_sol, orig_site_sol
< expires: Thu, 21 Mar 2024 17:42:30 GMT
expires: Thu, 21 Mar 2024 17:42:30 GMT
< pagespeed: off
pagespeed: off
< response: 403
response: 403
< server: Apache
server: Apache
< vary: Accept-Encoding,Origin
vary: Accept-Encoding,Origin
< x-ezoic-cdn: Miss
x-ezoic-cdn: Miss
< x-middleton-display: staticcontent_sol, orig_site_sol
x-middleton-display: staticcontent_sol, orig_site_sol
< x-middleton-response: 403
x-middleton-response: 403
< x-origin-cache-control: 
x-origin-cache-control: 
< x-sol: orig
x-sol: orig

Mainly to help future users with the same problem, this DID end up being an issue with Ezoic!

They have a feature called “Leap” that includes “Cloud Caching”. I don’t know if it has any value when I already have Cloudflare, but it’s enabled on their end by default.

Disabling it solved the problem immediately :slight_smile:

Thanks for all of the help!

1 Like

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.