Scary one here.
We have an ERP platform + nginx which serves traffic to frontend, a frontend portal for public users and a backend for internal users.
I received 2 reports from public site visitors that they had seen backend features, without being required to authenticate (knowingly). While on the phone with one of them, we determined that he was logged in as an internal user. The server log shows that private link was called from our static ip at the office, not the users actual ip.
The nginx module realip_module was configured to show the real ip of users instead of CF localhost.
First thought was backend pages were getting cached. I immediately purged the cache in CF, disabled Always Online, activated dev mode and set the A records to DNS only. We did not have any page rules.
When a logged in user calls a private URL, the header looks like this.
Request URL: https://www.xxxxxxxxxxxx .com/web/webclient/locale/en_US
Request Method: GET
Status Code: 200 (from disk cache)
Remote Address: xxx.xxx.xxx.xxx:443
Referrer Policy: no-referrer-when-downgrade
We are having an insanely difficult time pinpointing this. If it were leaked credentials, it still doesn’t answer how a totally random device/ip/visitor ended up with them or how they authenticated automatically. Is Always On capable of serving an active session to > 1 person?
Any ideas how I can definitively rule out CF?
I have drafted a page rule for …/web* w/ Security Level: High, Cache Level: Bypass, and Disable Performance (True). Is this sufficient?
I am not sure if this incident is at all related to the one discussed in this thread: Caching is Caching Logged in User Across All Visitors.
cc: @sdayman @user6293