transforminteractive / alt-f

Automatically exported from code.google.com/p/alt-f

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

The directory browser cannot handle folder names containing certain characters. URL escaping the folder name fixes this

GoogleCodeExporter opened this issue · comments


There are quite a few valid folder names that cause the directory browser to 
break due to the characters in them being output to the page without first 
being URL escaped. For example, if I created a folder name extolling the 
virtues of a defunct cheap clothing shop, "C&A=Good"...

cd /mnt/sda2/Public/RW
mkdir "C&A=Good"

Using Directory Browse, I can traverse to the /mnt/sda2/Public/RW folder, and 
even see the C&A=Good folder within it:

/mnt/sda2/Public/RW         Owner   Group   Permissions
    sda2                        root        root        rwxr-xr-x
        Alt-F                   root        root        rwxr-xr-x
        Public              root        root        rwxr-xr-x
            RO              root        root        rwxr-xr-x
            RW              nobody  nobody  rwxrwxrwx
                C&A=Good    root        root        rwxr-xr-x
        Users               root        root        rwxr-xr-x
        lost+found          root        root        rwx------
    sdb2                        root        root        rwxr-xr-x


However, if I try to navigate into the C&A=Good folder, I get taken to /mnt, 
and the following error message is displayed:

Warning: Directory base must be /mnt

A quick look at the URL being requested shows why:

/cgi-bin/browse_dir.cgi?wind=no?browse=/mnt/sda2/Public/RW/C&A=Good

The letter A is being treated as a URL parameter, as it has an ampersand before 
it and an equals sign after it. If the URL was escaped, it would look like this:

/cgi-bin/browse_dir.cgi?wind=no?browse=/mnt/sda2/Public/RW/C%26A%3DGood

Following that link gives me the C&A=Good folder as expected.

Even if a folder name doesn't contain any characters like & or =, they should 
probably be escaped anyway, in case there are characters anywhere in the path 
hierarchy. For example, if I had a folder inside the C&A=Good folder called 
Test, I wouldn't be able to access it for the same reason:

/cgi-bin/browse_dir.cgi?wind=no?browse=/mnt/sda2/Public/RW/C&A=Good/Test

Escaping the URL makes everything work as expected:

/cgi-bin/browse_dir.cgi?wind=no?browse=/mnt/sda2/Public/RW/C%26A%3DGood/Test



It's not just the directory browsing links that need the values escaped: the 
same is also true for any of the form POST operations like Copy, Editing 
Permissions, etc. With the Test folder selected, if I try to access its 
permissions, I see the following:

Warning: Directory "/mnt/sda2/Public/RW/C&A" does not exista.

This is also fixed by escaping the URL.



It's not just characters that are used to build URLs that cause a problem, 
however. A folder name with quotes in causes similar problems. For example:

cd /mnt/sda2/Public/RW
mkdir \"Meh\"

Using the directory browser, I can navigate to /mnt/sda2/Public/RW, and can see 
the "Meh" folder listed:

/mnt/sda2/Public/RW         Owner   Group   Permissions
    sda2                        root        root        rwxr-xr-x
        Alt-F                   root        root        rwxr-xr-x
        Public              root        root        rwxr-xr-x
            RO              root        root        rwxr-xr-x
            RW              nobody  nobody  rwxrwxrwx
                "Meh"       root        root        rwxr-xr-x
        Users               root        root        rwxr-xr-x
        lost+found          root        root        rwx------
    sdb2                        root        root        rwxr-xr-x

However, because the URL is not being escaped, the quotes are being delivered 
to the page as quotes, which has the unfortunate effect of closing the anchor's 
href attribute earlier than it should be:

<td><a style="text-decoration: none" 
href="/cgi-bin/browse_dir.cgi?wind=no?browse=/mnt/sda2/Public/RW/" 
meh""="">"Meh"</a></td>

This, incidentally, is how some script injection vulnerabilities work... and, 
of course, there's always the fun story of Little Bobby Tables 
(http://xkcd.com/327/) to illustrate this perfectly ;-)

Because the href attribute closed early, clicked the link that shows "Meh" will 
actually take you to its parent folder, RW.

If the quotes are escaped, the href attribute has its full and correct value, 
and I can browse the directory:

/cgi-bin/browse_dir.cgi?wind=no?browse=/mnt/sda2/Public/RW/%22Meh%22

It's not just the href attributes that need to be escaped, however: a URL 
should be escaped for any use in any HTML. Visiting the aforementioned 
quote-safe URL, you'll notice that text input that shows the currently selected 
folder only contains this:

/mnt/sda2/Public/RW/

This is for the same reason that the anchors broke: because the input's value 
attribute is also being closed too early:

<td><input type="text" name="newdir" value="/mnt/sda2/Public/RW/" meh""="" 
onmouseover="popUp(event,'curdir')" onmouseout="popDown('curdir')"></td>



I'm not familiar enough with CGI and shell scripts to know how best to escape 
the folder names, but I'm sure there will be an easy way. In JavaScript, I'd 
call either window.escape() or window.encodeURIComponent(). I wouldn't use 
window.encodeURI, as that leaves the ? and the = characters untouched.



What Alt-F version are you using? Have you flashed it? What is the box hardware 
revision level? What OS are you using on your computer? Using what browser?
0.1RC2, Yes, A1, OSX 10.6.8, Chrome 19.0.1049.3 dev stream



Original issue reported on code.google.com by d...@coedit.co.uk on 26 Feb 2012 at 2:41

Thanks for you detailed and pedagogic report.

Actually casuistic care was taken in some places in the code, but I have to do 
a more extensive review.

A shell-based html_escape function already exists in the code, but it is rude 
and crude:

# html_escape 'C&A=Good'
C&A=Good

Original comment by whoami.j...@gmail.com on 29 Feb 2012 at 6:28

  • Changed state: Started

I've just found that httpd will do this for you. This: 

httpd -e "<a href=\"http://blah/foo with spaces and % signs and ? and & and = 
chars\">link</a>"

Gives this:

<a href="http://blah/foo with spaces and % signs and ? and & and = 
chars">link</a>

It'll also decode URL strings. This::

httpd -d "?wibble=%20n&q=v"

Gives this:

?wibble= n&q=v


Original comment by d...@coedit.co.uk on 1 Mar 2012 at 7:15


I forgot to show what "C&A=Good" comes out as:

httpd -e "C&A=Good"

C&A=Good


Original comment by d...@coedit.co.uk on 1 Mar 2012 at 7:37

I'm aware of "httpd -e", as I use "httpd -d" often. Perhaps "httpd -d" was not 
working OK on the previous busybox version used by Alt-F? Don't remember.

Anyway the reported issue is mainly due to a bad parsing of the (already 
decoded)  QUERY_STRING; and yes, the problem is the '=' in path names. The 
parsing tries to avoid "malware" injection in the query string, but I'm afraid 
I'm inexperienced in this matter.

Solved, now fine-tuning and testing.

Original comment by whoami.j...@gmail.com on 2 Mar 2012 at 12:56

Closed by SVN commit 1566.

There are likely other cgi scripts vulnerable to special characters issues -- 
that's why most OS forbid some characters in pathnames?

"Unfortunately" unix allows them all but '/', but Alt-F shell-based cgi scripts 
are very error prone.

Being of the time where pathnames were restricted to only some 8 ASCII chars 
(I'm a dinosaur?), I have developed a self-defense strategie of not using those 
characters in my file names -- its a kind of second-nature -- so my tests are 
biased by nature.

Original comment by whoami.j...@gmail.com on 6 Mar 2012 at 7:39

  • Changed state: Fixed

Just out of interest, would SVN commit 1566 fix a similar error with single 
quotes in folder names causing JavaScript errors?

If I create a folder called "Don't" (without the double quotes) in the folder 
/mnt/sda2/Public/RW, I can navigate to it without a problem using the directory 
setup page. However, if I click the 'Permissions' button, I get a JS error due 
to the apostrophe in "Don't" terminating the parameter passed to the perms() 
method in the Permission button's onclick attribute:

onclick="perms('/mnt/sda2/Public/RW/Don't')"

If the commit won't fix this, shall I raise a new bug report or will this one 
be fine?

Thanks!

Dan


Original comment by d...@coedit.co.uk on 9 Mar 2012 at 4:10

commit 1566  doesn't fix the single quote issue, I have re-opened this one.

I'm doing a general survey on all pages that deal with pathnames, as I' afraid 
that most only handle spaces as a "special" character, not the whole ! " # $ % 
& ' ( ) * + , - . : ; < = > ? @ [ \ ] ^ _ ` { | } ~ set. Missed any?

You opened not a single issue but a can of worms :-(

Original comment by whoami.j...@gmail.com on 12 Mar 2012 at 3:45

  • Changed state: Started
Closed by commit 2133:

browse_dir/dir_proc:
-add flat folder view (faster to display)
-add rename folder button
-disable new folder operations if a folder op is currently being done
-add more confirmation questions/confirmation dialogues
-closes Issue 78: The directory browser cannot handle folder names containing
certain characters.
Succeed Processing folders named as foo-!"#$%&'()* foo-+,-.:;<=>?
foo-@[\]^_`{|}~, עכשיו, מה זה or الآن، وهذا شيء

Hope that it is now fixed, but it is not guaranteed that apps will handle such 
folders, nor that its configuration files are properly quoted (if at all 
possible), so it is safer to use the plain old US-ASCII dated circa 1960 :-?

Original comment by whoami.j...@gmail.com on 18 Feb 2013 at 6:43

  • Changed state: Fixed