Public site visitors served active sessions of internal users

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.

  1. Request URL: https://www.xxxxxxxxxxxx .com/web/webclient/locale/en_US

  2. Request Method: GET

  3. Status Code: 200 (from disk cache)

  4. Remote Address:

  5. Referrer Policy: no-referrer-when-downgrade

  6. cache-control: max-age=36000

  7. cf-cache-status: DYNAMIC

  8. cf-ray: 532xxxxxxxxxxxd17-PHL

  9. content-length: 0

  10. content-type: application/javascript

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

Thank you!

1 Like

@ryan34 Any word on this?

Hey @JohnS20

We’ve ruled out xss / cookie theft / session hijacking. No anomalies server side. The likelihood that it is a custom development is pretty much null given the amount of code review over the past few days. I am not able to reproduce it and have no idea how to debug CF since there are no logs to refer to.

Thank you for the update. We are looking into CF as well right now. We have turned off all possible caching coming from CF that we are aware of. Hopefully, we get some more help from them. Will keep you posted.

From the overview tab, lower right corner, you can select pause Cloudflare to see if the issue still occurs while cf is paused.

In similar instances I’ve seen, the situation you describe resulted from caching a login page. Can you reproduce the issue with cf paused? Can you share the name of the actual domain? And, do you have a ticket with Support that you can share the number of here?

Yes, we have a support ticket. Can you DM me and I’ll share.

Hi @ryan34, let us know if you’re still having issues. And, can you confirm if Always online is active? If so, disable and purge cache. Can you try and let us know?

Sorry the delayed reply guys and thank you for the input. I’m thinking you are right @cloonan. Always Online was enabled at the time the issue was reported. I haven’t been able to reproduce it since nor have I received any new reports, so I think we are good to go. I still plan to verify that it was a function of ‘Always On’ with a dummy database. If I can replicate I’ll let you guys know for sure and post a few screengrabs.


This topic was automatically closed after 30 days. New replies are no longer allowed.