5 ms·
WordPress security is complex. The core code is OK, security wise. Comparible to similar projects, I guess. The two major issues are that typically PHP runs
by deckiedan 10y ago
WordPress security is complex.
The core code is OK, security wise. Comparible to similar projects, I guess.
The two major issues are that typically PHP runs with permission to modify the WordPress directory, which is useful for automatic upgrades, but means any exploit in any plugin, theme, etc. instantly becomes, "can replace WordPress".
The other is that all themes and plugins are completely unsandboxed, and the quality is extremely variable.
The permissions thing can be fixed, by running a very stripped down wp-php user with only read access to the code, and only write access to wp-contents/uploads (and a logging dir). Then you do automatic upgrades with wp-cli and (real) cron from a user with write access.
The quality of plugins and themes is not easily fixed.
The API for writing plugins and themes doesn't help. It's archaic, spaghetti, and doesn't have any kind of coherenc. Global functions like wp_is_home(), the_loop(), get_sitename(), etc.
I've come across themes which bundle joomla inside them as they're really joomla themes with a shim.
- stephenr 10y ago> OK, security wise Since when is implementing your own home-grown shitty replacement for parameterised queries "OK"?
- debacle 10y agoSince you need to support versions of PHP that don't support the extensions that have parameterized queries.
- floatboth 10y agoExcept… you don't? > WordPress also works with PHP 5.2.4+ and MySQL 5.0+, but these versions have reached official End Of Life and as such may expose your site to security vulnerabilities > PDO ships with PHP 5.1, and is available as a PECL extension for PHP 5.0 Unless you mean "hosts that disabled PDO"… I think they can safely be ignored.
- debacle 10y agoPDO is disabled by default, and was even on default installs of 5.6 last I checked.
- floatboth 10y agoWhat "default"? Compiled from source? Debian package? Just checked, seems enabled by default on FreeBSD. (Commented out in php.ini doesn't mean disabled — here it's enabled in separate files like /usr/local/etc/php/ext-30-pdo_mysql.ini) MODX Revolution uses PDO exclusively, never had problems with it on any hosting service.
- debacle 10y agoI don't really understand your point. WordPress is ubiquitous. Until today I've never heard of MODX Revolution. Commented out in php.ini does mean disabled - as in not enabled. PDO isn't enabled by default in FreeBSD you still need to install a separate package for PDO.
- stephenr 10y agoHis/Her point was that if someone is still using shared hosting (where they can't change the extensions available) it would be very rare to find one that doesn't have PDO enabled. > Commented out in php.ini does mean disabled - as in not enabled. Not necessarily, as I explained here: https://news.ycombinator.com/item?id=13761550 https://news.ycombinator.com/item?id=13761550
- stephenr 10y agoMost Linux/BSD distributions seem to separate out "core" PHP extensions (those that are distributed with php source, not via peel) into individual packages. So while PDO may not be installed by a plain `apt-get install php5` or similar, I doubt the now deprecated `mysql` extension is installed by "default" in those scenarios either. Edit: this approach also means that the PDO extension in php.ini will be commented, because its loaded by a package specific ini file e.g. /etc/php/7.0/fpm/conf.d/* which are generally symlinks to /etc/php/7.0/mods-available/
- stephenr 10y agoWhich version of PHP does WordPress support that doesn't support parameterised queries? Here's a hint: Wordpress since v3.3 needs PHP 5.2+. MySQLi was added in PHP 5.0, PDO in 5.1 WordPress v3.3 was released in 2011.
- pawadu 10y ago> WordPress security is complex. This must be an oxymoron since complexity is the enemy of security. I think what you meant to say was > WordPress security is at best ad-hoc, and mostly non-existing
- deckiedan 10y agoI was replying to > show me if security is improved! > (which for Wordpress can't be that hard) that is, to say that the concept of 'WordPress Security' isn't a single simple thing to 'improve'. Unfortunately. If you wrote a set of 10 jillion tests and proved that wordpress core has no possible security vulnerabilities (humour me), that still would not fix 'WordPress Security'. From a theoretical point of view, you're absolutely right, and I agree with you. From a practical point of view, WordPress is often 'good enough', and 'works well enough', and has 'few enough security issues', for many people. Improving security is great, but it's a complex, perhaps impossible problem.