wordpress, index.php and hiding malware

SOLUTION: it really would make more sense to switch to index.html or atleast use an empty index.php..

That really is a work around for a misconfigured installation. index.html is not the correct file, index.php is.

But (2) makes a lot easier for malware to hide unnoticed – forcing to check contents / multiple hashes when cleaning/doing maintenance.

If an attacker can arbitrarily modify or create files and directories then the problem is not index.php. Your site is insecure and that’s what you need to focus on.

Give this a read, it has some good advice for hardening your site.

https://codex.www.ads-software.com/Hardening_WordPress

If your site is compromised and needs to be deloused then please start with this article.

https://codex.www.ads-software.com/FAQ_My_site_was_hacked

@jan – this isn’t about any specific site or malware.
Just pointing out what in my opinion would make it both secure and easier to maintain for admins…

WP 3.7+ has checksum API that verifies core file MD5 hash (but it by default ignores anything in /wp-content/*).
Hence – malware can use index.php to persist across updates.

And as i pointed out – 28 bytes is enough for universal backdoor.
If it kept same size = not immediately noticeable via FTP (unless you are viewing file contents / comparing hashes).

~ I understand the reasoning with using index.php, but i really think it would make sense to use empty index.php, instead of how it is now…

Also – i see that you moved this entry to “How-to” section.

As noted – this wasn’t a Question / “how to” / support request,
but feedback about WP index.php usage…

I’ve moved it back but this is still a suggestion to work around a bigger problem.

Using index.php or index.html isn’t a problem. The problem you are describing is that changes to that file should be easier to catch.

If your site is permitting those files to be updated by a third party then you don’t have to worry about those files. You’ve a much bigger problem to tackle: your site is insecure.

Common approach to prevent directory listing is using index document in a folder.

This is an incorrect approach. A correct approach would be to disable Directory Listing at the source in the first place. Adding Options -Indexes to the top of your .htaccess file would be one possible way. Turning off directory indexing in the main config for the whole server would be even better.

Server default configurations are often insecure. You should secure your server configs itself before trying to tackle the problem at the web-application layer. Sticking a blank index.html in every directory is silly when you can just turn the setting off to begin with.

@samuel – i feel you both are side-tracking from what this feedback was really about..
– This isn’t support question about any specific server, website, malware / nor about directory listing or DirectoryIndex, etc.

I gave a feedback about WP – specifically about it using non-empty index.php in multiple persistent places…

= My suggestion was to use empty index.php (instead of one that has a php comment inside it)..
Might seem like a minor thing, but makes life easier..

I understand that you gave feedback. I was disagreeing with your feedback.

– The index.html file is no better supported than index.php is.
– Whether it is blank or has comment text in it doesn’t matter, except that it does because zero-byte files can sometimes have platform-dependent issues, and WordPress tries very hard to be platform-agnostic.
– WordPress does not include these in every directory, only in one place for one-specific reason, and you should not rely on this for security but should disable directory indexing everywhere instead.

– Yes, I allready noted the problem with index.php vs. index.html..

– As noted – WP includes this file in 3+ places (and some themes/plugins sometimes follow this suite) = but not relevant..

– Also i’m not relaying on this for any security / to prevent directory listing = whole point feedback is about index.php being non-empty..

Now that we finally got those assumptions out of the way:
~ well, some SVN indeed used to have problems with 0B files;
~ but not aware of any webserver that has problems with 0B index document (not that it matters, since not using for redirect / or outputting anything).

Anyway – then a compromise suggestion:
– Use index.php with only opening tag: <?php.
(only 5 bytes – too small for anything, then content become irrelevant)