4 ms·

The problem is that security is not a feature. It can not be simply added at some point if software was not designed with security in mind. For example, if aut

The problem is that security is not a feature. It can not be simply added at some point if software was not designed with security in mind. For example, if authorization code is spread all over the code base and mixed with business logic no patching will make this secure, at some point problems will emerge again. I'm not saying WordPress is not secure, because I don't know its architecture. But the argument that after few critical vulnerabilities had been fixed no more were discovered does not convince me. A better argument would be to actually explain the WordPress architecture and why it is a good base for a secure system. For example Ruby Rack architecture is in my opinion a wise design from a security perspective, because it allows to nicely isolate security critical pieces from business logic.

smacktoward 13y ago
The biggest problem with WordPress security isn't WordPress itself, it's with WordPress' extension APIs. You extend WordPress by writing "themes" and "plugins". Themes are supposed to change how the site looks, while plugins are supposed to change how the site works. But in practice, there's no isolation of capabilities in either case, so it's entirely possible for a plugin to do theme-like stuff and a theme to do plugin-like stuff. Users don't understand this, so they think things like "oh, it's safe to install, it's just a theme." Worse, there's no isolation between code that comes in via either of these extension mechanisms and WordPress itself. As far as the server is concerned it's all just a big bag of PHP that runs with the same privileges. So a malicious theme or plugin has a lot of scope to do Very Bad Things once it's convinced a user to install it. Users don't understand how the attack surface increases as your installed plugins/themes increase, so they install tons of stuff, sometimes just because "oh this looks fun!" I don't know how you untangle all this, unfortunately, especially in a system that needs to run well in commodity shared hosting. The only real defense is to be extremely judicious in what extensions you choose to install.
- mixedbit 13y ago
  Couldn't some kind of PHP level sandboxing be used to isolate plugins and themes? So for example a theme would not be able to spawn OS processes, access DB connection or create a new one, read and modify HTTP headers.

smacktoward 13y ago

The biggest problem with WordPress security isn't WordPress itself, it's with WordPress' extension APIs. You extend WordPress by writing "themes" and "plugins". Themes are supposed to change how the site looks, while plugins are supposed to change how the site works. But in practice, there's no isolation of capabilities in either case, so it's entirely possible for a plugin to do theme-like stuff and a theme to do plugin-like stuff. Users don't understand this, so they think things like "oh, it's safe to install, it's just a theme." Worse, there's no isolation between code that comes in via either of these extension mechanisms and WordPress itself. As far as the server is concerned it's all just a big bag of PHP that runs with the same privileges. So a malicious theme or plugin has a lot of scope to do Very Bad Things once it's convinced a user to install it. Users don't understand how the attack surface increases as your installed plugins/themes increase, so they install tons of stuff, sometimes just because "oh this looks fun!" I don't know how you untangle all this, unfortunately, especially in a system that needs to run well in commodity shared hosting. The only real defense is to be extremely judicious in what extensions you choose to install.

mixedbit 13y ago
Couldn't some kind of PHP level sandboxing be used to isolate plugins and themes? So for example a theme would not be able to spawn OS processes, access DB connection or create a new one, read and modify HTTP headers.