Security Alert
Certain uploaded files can impose a security issue. For example, any file with a
.php
extension is executed on a webserver where PHP is enabled by simply viewing the file! PHP programs can do any file access, so so a malicious person could attach a
.php
file to a TWiki page and do some damage. Also, if a
.htaccess
is attached you get an error when accessing the attached file.
This security hole is fixed in the latest
TWikiAlphaRelease and in this TWiki installation. TWiki appends now a
.txt
extension to any suspicious file name that is attached to a topic.
This is what you need to do to your installation in case you want to fix it manually but do not want to upgrade yet:
1. File lib/TWiki.cfg
(was bin/wikicfg.pm
)
Add this after the
securityFilter
:
# Regex security filter for uploaded files :
# (Matching files will have a ".txt" appended)
$uploadFilter = "^(\.htaccess|.*\.php[0-9s]?|.*\.phtm[l]?)\$";
2. File lib/TWiki.pm
(was bin/wiki.pm
)
Add
red part to the variable list in the beginning:
$wikiToolName $securityFilter $uploadFilter
3. File bin/upload
Add
red part to sub main:
# cut path from filepath name (Windows "\" and Unix "/" format)
my @pathz = ( split( /\\/, $filePath ) );
my $filetemp = $pathz[$#pathz];
my @pathza = ( split( '/', $filetemp ) );
$fileName = $pathza[$#pathza];
$fileName =~ s/[^A-Za-z0-9_\.\-]//go; # delete special characters
$fileName =~ s/$TWiki::uploadFilter/$1\.txt/goi; # apply security filter
--
PeterThoeny - 25 Mar 2001
If attachments were not held in the public directory area then this wouldn't be a problem. Another reason this might be good to move to in due course.
--
JohnTalintyre - 25 Mar 2001
Images and such still need to be accessable from the htdocs/ root. Then you have a create a some code to determine whether something should be in the pub directory or not. For things like images to work properly there is always going to have to be a checkout copy in the htdoc root.
--
NicholasLee - 25 Mar 2001
I'm not sure there's a very clean way of doing this. We could perhaps automatically keep copies of files with certain extension in pub, all attachments being available via
viewfile script.
--
JohnTalintyre - 26 Mar 2001
For now I think Peter's solution is the most generic. A viewfile mechanism doesn't work very nicely with attachment you want to be included inline.
--
NicholasLee - 26 Mar 2001
I can't speak for other webservers then Apache, and I could easily be wrong on this given my knowledge/understanding of configuring Apache, but I was under the impression that one had to actually configure a directory as having executable content (using scriptalias etc.)before the webserver would try to execute any file it thinks
is executable. I see many mentions of seeing a script's source instead of it's output on the comp.infosystems.webserver.* newsgroup(s) and it all seems to be about making the webserver know that it's to evaluate and not just show a file in some particular directories.
WRT, isn't the only directory that actually needs "webserver execute permissions" the twiki/bin/* directory and children?
From the Apache httpd.conf file:
# ScriptAlias: This controls which directories contain server scripts.
# ScriptAliases are essentially the same as Aliases, except that
# documents in the realname directory are treated as applications and
# run by the server when requested rather than as documents sent to the client.
If i'm incorrect about all this and Peter's patch is needed, then the list of possible exectutlable extensions to "escape" with a .txt extension needs to include *.exe, *.php3, *.tcl, *.py, *.pyc, *.sh (and who knows what else?)...
--
DavidLeBlanc - 27 Mar 2001
David, all you say is correct for executables, e.g. a directory must be enabled by the
ScriptAlias
directive. PHP is a different animal. The web server apparently passes files with a certain extension through the PHP interpreter, this happens also in normal directories under the htdocs tree. I.e., before this fix it was possible to attach a PHP file and it got interpreted by looking at it. Oops!
--
PeterThoeny - 27 Mar 2001
I think its something to do with the mime.type handling.
ie.
AddType application/x-httpd-php3 .php3
The php processor registers its as the mime.type handler for this and sides steps any directory style security process.
CGI perl (and probably php3) doesn't have this issue as "Set-Handler cgi-script" is a directory level apache option. Futhermore mod_perl is probably likely to have this probably as well because proper use of that requires entries in the apache conf files.
--
NicholasLee - 28 Mar 2001
To disable php it seems enough to add this to an .htaccess file. It will propagate to subdirectories.
RemoveType .php .php3 .phtml
--
JohnBelmonte - 05 Sep 2001
Some hosts treat
everything as a script, so you don't need to futz around specifying a particular cgi-bin dir.
FIX: add the following to your .htaccess files:
~/public_html/.htaccess
SetHandler default-handler
Options -ExecCGI
RemoveHandler .pl .cgi .py .php .php3 .php4 .phtml .shtml
~/public_html/bin/.htaccess
SetHandler cgi-script
Options +ExecCGI -Index
--
MattWilkie - 20 Feb 2005