Tags:
delete_me1Add my vote for this tag create new tag
view all tags

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

Edit | Attach | Watch | Print version | History: r11 < r10 < r9 < r8 < r7 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r11 - 2005-02-20 - MattWilkie
 
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.