[wp-trac] [WordPress Trac] #18546: Add index.php to wp-includes and wp-admin/includes

[WordPress Trac]

#18546: Add index.php to wp-includes and wp-admin/includes
------------------------------------+------------------------------
 Reporter:  SergeyBiryukov          |       Owner:
     Type:  enhancement             |      Status:  reopened
 Priority:  low                     |   Milestone:  Awaiting Review
Component:  General                 |     Version:  3.2
 Severity:  minor                   |  Resolution:
 Keywords:  dev-feedback has-patch  |
------------------------------------+------------------------------

Comment (by bpetty):

 Replying to [comment:9 SergeyBiryukov]:
 > Replying to [comment:6 bpetty]:
 > > Silencing wp-includes or wp-admin is really completely pointless, and
 doesn't help secure anything or hide any sensitive content.
 >
 > This isn't for security, the idea was to prevent unnecessary crawling
 and irrelevant errors in server logs.

 In my experience, the only reason to explicitly override server
 configuration settings like this is for increased security measures.
 WordPress (and any web application software in general) should not be
 doing anything in regards to overriding server configuration behavior
 otherwise, and I guess that's not what others here think. Allow me to
 explain why I re-classified this as security then.

 If a PHP script is returning errors because it was requested directly,
 there's always another 100% effective way of handling those errors
 regardless of what httpd is in use. Web applications like phpBB deal with
 this using a simple check in every include, which is very helpful for
 security in general too:

 {{{
 if (!defined('IN_PHPBB')) { exit; }
 }}}

 I've known this approach to be pretty standard across numerous web
 applications when it is impossible to leave include files outside of the
 document root.

 That said though, I know that it's possible that plugins have directly
 included WP core include files without going through wp-load.php (using
 custom ajax functionality, image thumbnailing, or who knows what else). In
 that case, just actually handling the error appropriately (depending on
 what it is) *is* still the ideal solution that works everywhere. If
 there's an error being generated, who knows what else the script is doing
 inappropriately because it was requested directly, trying to cut back on
 crawlers from hitting those files isn't going to fix it. The file should
 be making the appropriate checks that classes/methods defined elsewhere
 exist, or that it was included from another file if it's only meant to be
 used from those files (when it depends on something defined or handled in
 those files) whenever it does anything beyond just defining new classes,
 methods, constants, or variables for use by other scripts.

 And in regards to non-error-related requests, if someone is really
 concerned about their server logs and these kinds of requests/crawlers,
 they should be tuning their httpd configuration directly, especially in
 regards to automated directory indexing since it is in fact the httpd
 generating those pages, not WordPress.

 > Another way to address this might be trying to create `.htaccess` file
 on install (which was previously suggested for #6481) if it doesn't exist
 yet and the permissions allow to do that. This would have an additional
 bonus of displaying 404 pages in theme layout even with default
 permalinks.

 Not that I like a solution like this because it really doesn't solve the
 root problem (regardless of what rules are being used), but #6481 doesn't
 mention indexing at all. What kind of .htaccess configuration options or
 rewrite rules are you talking about that address this?

 Anyway, this is the first time I've read "it was decided that path
 disclosure was not a classified as a security vulnerability for WordPress"
 ([comment:ticket:17601:15]). If that's the case, this entire ticket is
 invalid, and technically speaking, index.php should be removed from the
 three locations that it's already been added for.

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/18546#comment:10>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software