I am posting this here by recommendation from thread: https://security.drupal.org/node/166370 Every time I encounter any kind of serious hack for Drupal, I always find that a PHP file somehow makes its way into the files dir and then is either left there (75% of the time I bet) or moved somewhere else (usually the /tmp dir) although thats somewhat rare. I have wanted to see drupal check files being placed in the dir for the <?php text string but have never seen this happen for unknown reasons. To me it just makes sense that any file that has PHP in it simply does NOT belong in the files dir because that would make it executable when combined with a .php, php3, php5, etc type of server setup or any customization of that which can occur. I've even seen .jpg files come in with php in them so it doesnt seem to be enough to check for just files with a .php extension. It should also look for PHP tags themselves which is going to catch more than looking for just a .php extension. It's not going to be 100% but it sure is going to make it much more difficult to abuse the files dir which is often the only writable directory on a drupal system.
Another argument might be made for "caching" modules that cache PHP files. But I'd argue against even those because PHP files should not be cached in the first place. And if any module (contrib or custom) attempts to put a file there, it should be notified that doing so is NOT a good plan and is strictly prohibited in Drupal. If a module wants to do that, force it to use something OTHER than the public directory. I see no reason to put the rest of us at risk for the edge use cases.
Another argument might be that .htaccess does this. But if you look at the link above, you'll quickly see that isnt the solution either because the .htaccess file got blown away with a cp /dev/null sites/default/files/.htaccess call. So another thing that this should do is make sure that .htaccess is not OWNED as well as not WRITABLE by the user it is running as, and if it is, alert the site owner to change the ownership such that apache cannot modify it. Removing the permissions with chmod is not enough. It would have to be chown. Since this isnt really possible to do on shared hosts, this is why I believe that htaccess is NOT the answer to sanitizing the files dir. It's easily circumvented as the above link demonstrates.
So there are 2 ways to implement this.
1. Make it a core sanitation effort for any file destined for the public dir (sites/default/files)
2. Make it a part of the site audit module (less desirable/useful but could be tested there). I've never once used this module with any real success myself as it does not catch most things I am looking for anyway.
IMO, any file that contains <?php does NOT belong in the public files dir. A case for private files could even be made for that but for my purposes, its usually the public dir that is the problem, not the private dir.
I would also like to see this in Drupal 7. I have tried drupal 8 many times and am extremely dissatisfied with it's lack of stability across updates and do not post anything to help it out. I am disgusted with it, but I would not be opposed to putting the feature in drupal 8 so long as it has a backport to d7 that doesnt take 17 years.