httpd-wiki-changes mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Httpd Wiki] Update of "FileSystemSecurity" by thumbs
Date Fri, 30 Jul 2010 14:11:47 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Httpd Wiki" for change notification.

The "FileSystemSecurity" page has been changed by thumbs.
http://wiki.apache.org/httpd/FileSystemSecurity

--------------------------------------------------

New page:
The Apache HTTP Server needs read access to its configuration files and the files it serves.
 In and of itself, the server does not need write access anywhere on the system: even its
log files are opened for write when the server is still root, and the open file descriptors
passed to the child processes which change their user id to the lesser privileged user.  

Read access only.  The web server user should not own, or be able to write to, its configuration
files or content.  

Content, other than CGI scripts, generally does not need Execute permissions.  Even PHP files
that are interpreted by the server do not need to be Executable.  

Certain applications, especially publishing platforms and Content Management Systems that
you manage and populate through the web server itself using a browser, require that certain
directories on the system be made writable by the web server user.  You can do this by changing
the owner of the directory to that user (usually www but ymmv), or by making the directory
group-writable and changing the group to the group as which Apache runs. 

Making directories writable by the web server should be done only with care and consideration.
 The usual threat model is that someone manages to upload (for instance) a PHP script of their
own making into the document root, and simply executes that by accessing it through a browser.
 Now someone is executing code on your machine.

If a web app needs writable directories, it's often better to have those outside the DocumentRoot:
that way the uploads can't be accessed from the outside through a direct URL.  Some applications
(Wordpress for instance) support this, others do not.  

In many cases, writable directories are not strictly necessary even though the web app might
like them: rather than upload plugins (which contain code that gets executed or interpreted,
yech!) through the web browser, upload them through ssh and manually unpack them on the server.
 The CMS Joomla! likes to write its configuration file to the Document Root on initial install
(which promptly becomes a popular attack target) but if it can't write to the Document Root,
it will output the config to the browser to the user can manually upload it.

Mime
View raw message