HTML Encode filenames and directory names about ifm HOT 16 CLOSED

The bug should be fixed now. I also checked if the IFM is vulnerable to a XSS attack, but it seems to be safe. Please let me know, if you see any possible attack.

from ifm.

Wasn't able to create a XSS attack, but still got funny results with filenames like:
test<script>alert("info") or <?php echo "TEST"; ?>

from ifm.

Also, deleting a file with following names failed within ifm:

new"file".txt
<?php echo "TEST"; ?>
test<script>alert("info")

rename worked fine.

from ifm.

Opening of files and showing content like
new\file.txt
new?file.txt
new:file.txt
failed.

from ifm.

Opening of files and showing content like
new\file.txtor new?file.txtfailed.

Hm, this is weird, I just tested that on my server and it worked fine. Even new\file.txt which I kind of expected to fail... On which platform do you use the IFM? Did you set a custom root_dir?

from ifm.

No custom root dir.

Tested in Apache & Linux, on a typical PHP 5.6 1and1 hosted web server, ifm.php in root dir.

from ifm.

Is UTF-8 the default locale on the server?

Please do also an ajax request, with the following data (adjust filename if necessary):

dir=
api=getContent
filename=new\file.txt

from ifm.

Well, I finally could reproduce the error, when deleting a file named <?php echo "Test"; ?>. The error also occured when trying to extract a file with special characters. I fixed this error with the newest commit to #58.

In the JS part, Mustache takes care of the encoding. This works quite well. I'm curious what your ajax request brings up.

from ifm.

result of API request:
{"status":"OK","data":{"filename":"new\file.txt","content":""}}

But the backslash will not be encoded correctly, the browser creates a forward slash:

http://ifm.jrondorf.de/ifm.php
--> http://ifm.jrondorf.de/new/file.txt

You might recognise that ifm.php is visible, thats a problem of 1und1, delivering a different result for the paths. In ifm version 2.3.1 I was able to get around that with:

if( $result == basename( $_SERVER['SCRIPT_NAME'] ) && $this->getScriptRoot() == getcwd() ) { } // we don't want to see the script itself
elseif( $result == basename( $_SERVER['SCRIPT_NAME'] ) && dirname(FILE) == getcwd() ) { } // we don't want to see the script itself - 1und1

from ifm.

Hm. Apparently the backslash is not a valid URI character according to RFC2396. However, I could fix that error by encode only the backslash. At least chrome and firefox behave correctly. I still dig around a bit and see if I can come up with a more clean solution.

Regarding the problem that the IFM shows itself: Apparently $_SERVER['SCRIPT_NAME'] is not really the best way to figure things out. I'll change that everywhere to dirname( __FILE__ ) to be consistent.

from ifm.

I pushed some updates to #58. The encoding of the href attribute should work now. I tested with a file named Foobar!"§$%&()=?\}][{¬½¼³²¹.txt which I were able to edit, rename, open by clicking the link, and delete.

I also removed getScriptRoot() in favour of dirname( __FILE__ ).

from ifm.

I also updated the IFM on your host: http://ifm.jrondorf.de/ifm.php

• ifm.php is hidden now
• the file Foobar* is now accessible by clicking the link

Please let me know, if you still encounter any errors ;)

from ifm.

Great! Only thing I was able find:

Moving a file into the test dir <test|dir> is not working. The directory name is not shown in the move dialogue (only an empty icon), and the file move will lead to an error.

from ifm.

Yes, I'm already woking on this ;)

from ifm.

So, apparently this was only a displaying error. I fixed this with the latest push to #58. I also uploaded this current build to your host, and it works there.

Thank you for all tests you're doing! I really appreciate that!

from ifm.

I tested these changes on several servers (linux+windows) and there are working.

I also tested a bit with your instance (ifm.jrondorf.de/ifm.php), and it worked fine. There is only one error with copying files which contain UTF-8 characters, for example äöüÄÖÜ.txt. When you copy this file to another location, the filename gets stripped all UTF-8 characters. I tried to debug this, but it seems that the PHP copy function absorbs them. I guess there is a problem with the locale on your server, because this worked on all other machines quite well.

I will finally merge #58 to master. Thanks again for your support!

from ifm.