[lowercased]

I can't say there's 0 problems with WP core, but often the problems aren't in core system files, but in all the various plugins/themes. Also, those files (and core files) can get auto-updated - all hashes for those would need to be scanned for, and you'd have to trust every single theme/plugin vendors, and you'd have to trust all the plugins/libs those others use. And have to get them all to participate in the first place, no?

[Vanderson]

That is a good point. A hash standard for plugins could be implemented by WP then. And a way to verify the hashes shouldn't really be hard, and it would go a long way to making WP more secure by default.

Then if a plugin maker doesn't add the hashes to their downloads (or wherever they would need to be hosted) they wouldn't get a green lock next their listing?

Also, this could at least be automated away even if no one participates. I see it like this. You install the plugin, a hash table is built on the files that are installed. Maybe this is the moment of insecurity, but even SSH has a moment like this when storing keys.

This way you could at least detect "changes" to the plugins, but maybe not verify the initial install is good. But it's 50% there.

And this technique could be added to WP core and no forcing anyone to do anything. :P

But of course, if the server can create the hashes, then the server can manipulate them. But it would be more work for the hacker at least.

I keep all hashes out of the way of the web server so even if hacked, the web server can't be used to hide their activity.

[lowercased]

the other aspect is that many compromises in WP come from writeable file systems.

/wp-content/foobar.php wouldn't have a hash because it's not a plugin file, but a file that was a file that written to the filesystem by some other exploited plugin. You'd need to be on the lookout for any files that shouldn't be there, but when you're dealing with media folders where anyone can write anything, you're left guessing as to what 'might' be wrong (although executable PHP in an /images folder is probably suspect from the start).

[Vanderson]

>the other aspect is that many compromises in WP come from writeable file systems.

Yes, which is why I am stunned WP is setup by default this way, it's baffling to me. But I guess it makes it easier to manage?

>You'd need to be on the lookout for any files that shouldn't be there...

Yes, and this is what I did with my system, it's really not hard. Maybe like 10 extra lines of code to list all the current files, compare to a known list of hashes, if it's not listed, then it's a bad file.

All files in any user uploadable areas automatically are not executable. Every web server has a way to do this I am sure. (I don't know all of them)

This seems like such a simple problem to solve with a few basic changes to WP. What am I missing?

[lowercased]

what you're missing is that this is precisely why wp is popular - click buttons and have new files installed automatically, just move any file anywhere and have it execute.

[Vanderson]

I guess I am looking at it from a systems building perspective. If you can control the rules for what files are allowed to run (ie limit them to something like "plugin.php" or a directory like /something/something/plugin) then add access rules to the server (again, by default shouldn't be hard) to limit running files to those rules.

Then you have a lot smaller surface area of potential problems. I am not suggesting it has to be required by WP, but at least "available". This wouldn't cause any sort of popularity concerns or ease of use either.

Any plugin that wants to be more secure just follows some rules outlined by WP parent-corp and add the .htaccess (or whatever) rules and presto, more secure.

I don't run WP anymore than for testing stuff, can you really put a file anywhere by default and it's executable?

[ahje]

In most cases, yes. Most shared hosting providers will execute all PHP files as a default, although it's quite doable to block access using rewrite rules or custom access controls.

Problem is that the majority of WordPress users lack the know-how to do it on their own, as well as the will to pay for someone else to do it for them.

Web hosts aren't interested because supporting it would be a nightmare due to the millions of possible plugin/theme combinations.

[bigiain]

Back when I did a lot of WP sites, the WordFence plugin pretty much did exactly this...

Looks like it's still available and recently updated: https://wordpress.org/plugins/wordfence/

[Vanderson]

At a glance this looks neat. But don't you think it's odd that WP doesn't have built in security of a similar nature?

[lowercased]

no, because it takes time/effort to keep all that up to date. if wp.com provided it for a fee for wp.com-hosted sites, i'd understand that.

[chiefalchemist]

Agreed. Unfortunately, ultimately, WP is about marketshare. Period. End of story.

Matt & Co love to brag about marketshare. But the WP Elite are the Washington DC of OSS. That is, completely disconnected from the day to day lives of the underlying community.

Sad. But true.

[Vanderson]

I would imagine enough bad press has caused some of the security enhancements of the past. Maybe more are coming?

My experience is that some businesses that use WP rely on other companies to maintain security, and maybe individuals or small businesses don't consider it to much.