[wp-trac] Re: [WordPress Trac] #1038: Limit access to php files

[WordPress Trac]

#1038: Limit access to php files
----------------------+-----------------------------------------------------
       Id:  1038      |      Status:  assigned                
Component:  Security  |    Modified:  Thu Apr  6 06:13:19 2006
 Severity:  trivial   |   Milestone:  2.1                     
 Priority:  lowest    |     Version:  2.0.2                   
    Owner:  matt      |    Reporter:  anonymousbugger         
----------------------+-----------------------------------------------------
Changes (by thunderlove):

  * version:  1.5.2 => 2.0.2

Comment:

 With the exception of wp-config, the problem is not so much a hacker
 viewing the (open-source!) source, but rather some hacker ''executing''
 the source.  Almost certainly, there are some hitherto unknown (or yet-to-
 exist, or extant [e.g. php registered globals]) bugs/exploits the include
 files, that only manifest themselves when the file is accessed directly,
 and only under certain circumstances, or certain server configurations,
 and could result in DOS attack, spam, or worse.

 {{{ <?php defined('__WP__') || die(''); }}}

 It's easy -- easy enough for this strategy to be readily adopted by module
 and plugin writers -- and it makes things a bit safer, now and in the
 future.

 Lets be clear on smart security coding practices -- if all environment
 safety checks occur in wp-settings.php, then all executed php should be
 required to first go through wp-settings.php.  This way, all past,
 present, and future security checks (such as the $_REQUEST['GLOBALS']
 check) are ensured to be in place.  And if a file is not ''designed'' to
 be accessed directly, it should not be ''allowable'' to access it
 directly.  'What is not explicitly permitted is denied'

 So wp-config isn't the problem -- we cannot actively prevent it from being
 served raw, and when cooked it includes wp-settings.php.  The definition
 of {{{__WP__}}} could even go into wp-config.php itself.

 ''"It's improbable that something goes wrong with Apache and it stops
 parsing PHP files"''

 Unfortunately, it does happen on occasion.  Surely I'm not the only one
 here who's ever visited a website, and have the php source pop up.  Bad
 sysadmin or user error, certainly.  And yes, there is little that can be
 done about that here.

 And while I certainly agree -- we cannot prevent wp-config et al. from
 being served raw, we certainly ''can'' provide additional up-front
 information and configuration options to users to help prevent it.

 For example, regarding the <Files> directives, I would recommend adding
 them (well, at least the one protecting wp-config.php) to a security.txt,
 or a install.txt, or a link in readme.html.  True, they only apply to
 apache setups.  I do not know anything about other servers, but I should
 think they too would have some strategy for excluding files and
 directories, which should also be included.

 And there are other possible solutions, too, depending on the server
 configuration.  For example, a set of constants could be defined in wp-
 config, such as INCPATH and ADMINPATH, to define the absolute path to the
 given include directories.  (wp-settings.php defines WPINC as a relative
 path, but it seems that strategy was not applied universally). On many
 hosts, the include files could then be easily moved outside of webspace
 altogether, along with the database passwords from wp-config.  And that
 would be the best solution to the posted problem.

-- 
Ticket URL: <http://trac.wordpress.org/ticket/1038>
WordPress Trac <http://wordpress.org/>
WordPress blogging software