Browser back attack vulnerability in francoisjacquet/rosariosis
Apr 5th 2023
rosariosis has a vulnerability that allows user to return to a page containing personally identifiable information (PII) and sensitive information even after logging out of the application by using the browser's back button. This issue poses a significant risk to the confidentiality of sensitive data and user privacy.
Steps to reproduce
- Login to rosariosis and navigate to pages that displays PII example = /Modules.php?modname=Users/User.php&category_id=1&staff_id=4
- Log yourself out from the application
- Pressed the browser's back button and it will return to the page that the user visited recently
Please check owasp reference for the fixes
This vulnerability could result in unauthorized view to confidential information including personally identifiable information (PII). If an attacker gains access to this information, they could use it for malicious activities. Moreover, this vulnerability could result in a breach of regulatory compliance requirements, leading to legal and financial consequences.
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;
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
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).
Browser both have a cache, and a history buffer which may not implement
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.
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 for the details.
I have a solution: use JS to go forward in the history.
Could you please test it (please clear your browser cache) and let me know?
Good day, I just want to confirm if the fix was applied to rosariosis.org/demonstration also?
Yes it was.
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
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.
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 !
I now have a definitive fix (I hope so). Thank you @b1tch3s