Hello @b1tch3s

Thank you for your report.

You have missed a step: reload the page using F5 key when logged in, then only, logout.

This is because of the ETag cache.

It can be disabled in the config.inc.php:

$ETagCache = false;

Hello @François

Thank you for adding the missing steps (reload the page before you logout). It seems that you able to successfully replicate the issue.

Let me know if you need more information from me.

I have no fix for this right now. Fortunately, users usually do not fully (re)load pages but use the built-in AJAX system when clicking on links. So the scope of this vulnerability is thus limited. I will let you know.

Note: I have done further testing. When the Back button is pressed, NO actual request is sent to the server (nothing in Apache access logs). The page is loaded from the cache.

Here are the relevant (original) response headers:

Cache-Control: private, must-revalidate
Content-Encoding: gzip
Content-Length: 5699
Content-Type: text/html
Date: Thu, 06 Apr 2023 19:13:45 GMT
ETag: W/b4413df9fe7db6ed0fd63cc80f2c2c6a

I have tried to change Cache-Control: private, must-revalidate to Cache-Control: private, no-cache https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control#no-cache no-cache does not mean "do not cache" but requires the cache to revalidate it before reuse.

Still, I am able to go back (and still no hit on the server). Reading https://stackoverflow.com/questions/866822/why-both-no-cache-and-no-store-should-be-used-in-http-response#answer-866866 Browser both have a cache, and a history buffer which may not implement no-cache...

So, a solution might be to both use no-cache, and clear the browser history on logout.

Note 2: the issue does not seem to exist with Firefox, only with Chrome. To test in IE and Safari.

Good Day!

Your are right that when the back button is pressed, no http request is sent to the server, making the malicious activity undetected via application logs.

The scope of the vulnerability is limited which reduces the residual risk to medium. I believed that it's something that needs to be risk accepted by the user's if we are unable to fix the issue. I'll try to ask for a recommend fix from our company's developer since this is a common security findings we reported. Let me know if you've already found a solution to the issue.

Note: I firstly discovered it on Firefox with kali linux OS ( F5 is required). Also, I was able to replicate the issue successfully on then following browser's:

• Firefox Windows 11 OS (F5 is required)
• Safari MacOS (F5 is not required).

Thanks.

Hello @b1tch3s

Thanks for the details.

I have a solution: use JS to go forward in the history.

https://gitlab.com/francoisjacquet/rosariosis/-/commit/3a0f7e5de731ed0f131f3689480df5e34a61e3ee

Could you please test it (please clear your browser cache) and let me know?

Hello @François,

Good day, I just want to confirm if the fix was applied to rosariosis.org/demonstration also?

Thanks !

Yes it was.

Hello @François,

It appears that the vulnerability has been addressed in Chrome and Firefox but still exist in Safari MacOS.

@b1tch3s thank you for testing.

I have tested on Safari 14.1 (MacOS Big Sur) and the fix did work.

• Safari 16.3 (MacOS Ventura), the fix did not work.

New Safari versions will not re-execute JS. But we can use the onpageshow event. See https://stackoverflow.com/questions/17432899/javascript-bfcache-pageshow-event-event-persisted-always-set-to-false And https://web.dev/bfcache/

The new fix is online (reload the page instead of going forward): https://gitlab.com/francoisjacquet/rosariosis/-/commit/4f2112f91e53bee0607c3c831b77517a08116a26

Please test it and let me know.

Hello @François,

It seems that the issue was already addressed. Now I can mark it as fixed on my end. It would be amazing if the identified vulnerability met the criteria to earn a CVE number.

Million thanks to you @François !