Closed GoogleCodeExporter closed 9 years ago
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
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
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
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
Original issue reported on code.google.com by
d...@coedit.co.uk
on 26 Feb 2012 at 2:41